Dear all,
Joe and I spoke. As we see it, there are multiple questions here.
1. Is the IETF interested into standardizing information models?
As mentioned by Mahesh (in the OPSAWG meeting minutes, to be posted
soon): "generally we don't spend too much time on info models and work
on standardise data models". However, we believe, as we accepted the
discard information as WG document already, let's not revisit this
decision.
2. How should those information models be specified?
Could be text, UML, whatever.
YANG is also a possibility (even if not common practice) as YANG is a
data modeling language. As John mentioned during the meeting, one
argument in the favor of YANG is that it's well known.
3. Should information models specified in YANG also be registered in IANA?
This is where we might have different views. As mentioned during the
meeting: "If you have it in IANA, then people will expect tooling to
work.".
What do we do from here?
1. Information model published as informational document: YANG model in
an appendix, not normative. In such a case, you don't register the YANG
module in IANA.
2. Information and data models in a single standards-track document,
with the data model registered as a YANG module with IANA.
Number 2 might be better, as you mentioned that there are existing
implementations. Plus it might ease maintainability and give other
implementations something to root to and augment. This might also be the
path of least resistance to publish. The YANG model in IANA would also
justify the fact that you moved from Informational to Standard Track in
this version
(https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/03/)
Jeff, at the microphone during the OPSAWG meeting, mentioned the issue
of evolving/maintaining information models before going to a data model.
We are not too sure how publishing an information model as RFC (as
opposed to a WIKI or something similar) is actually helping out.
Regards, Joe and Benoit
On 11/13/2024 11:19 PM, Joe Clarke (jclarke) wrote:
As a contributor, I think a data model approach would be far more
useful. That said, I haven’t seen these proprietary implementations
based on your draft info model to understand how they deviate or what
data modeling approach they take. I still think that starting with a
YANG data model wouldn’t preclude future drafts standardizing
IPFIX-based approaches to packet discard reporting (just as we’ve seen
MIBs move to YANG).
As a chair, I think it would be /easier/ from a process standpoint if
this was a data model. There just isn’t a lot (any?) info models in
the IETF developed in YANG. That said, things don’t always have to be
easy, and Med has already commented having a YANG info model is not an
insolvable problem.
I know Benoît is a bit busy, and I’m sure he’ll want to weigh in next
week.
Joe
*From: *Evans, John <jevan...@amazon.co.uk>
*Date: *Wednesday, November 13, 2024 at 06:53
*To: *opsawg@ietf.org <opsawg@ietf.org>, opsawg-cha...@ietf.org
<opsawg-cha...@ietf.org>
*Cc: *Pylypenko, Oleksandr <o...@amazon.com>, Jeff Haas
<jh...@juniper.net>, mohamed.boucad...@orange.com
<mohamed.boucad...@orange.com>, Aviran Kadosh (akadosh)
<akad...@cisco.com>
*Subject: *draft-ietf-opsawg-discardmodel
Hi All,
Following last week's discussion in Dublin regarding
draft-ietf-opsawg-discardmodel, we would appreciate feedback from the
working group and chairs on how to proceed.
To provide context, we initially defined an information model to
establish a common framework for discard reporting that could be
implemented across different data models, such as YANG and IPFIX.
We selected YANG to define the information model for three key
reasons: 1) the RFC8791 extensions enable the model to be decoupled
from specific implementations; 2) this approach allows for lossless
translation to a YANG-based data model; 3) the community has extensive
experience with YANG.
During the discussion, two main perspectives emerged: continue with
the current approach of defining an information model; redefine the
draft as a data model.
Given that the information model is already in YANG, creating data
models for interface, device, and control-plane would be
straightforward. This could also serve as a reference for a future
IPFIX-based discard reporting data model.
Hence, we would appreciate feedback on whether the best path forward
is to continue with the current information model approach or to
refocus on developing data models instead?
thanks
John
Amazon Data Services UK Limited. Registered in England and Wales with
registration number 09959151 with its registered office at 1 Principal
Place, Worship Street, London, EC2A 2FA, United Kingdom.
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
