Hi Med,
On 11/22/2024 8:35 AM, mohamed.boucad...@orange.com wrote:
Hi Benoît, all,
I think that I can convince myself that option 2 is better here (have
both IM/DM in the same spec). The main challenge will be to find
“where” to anchor the nodes (interface, NE, routing management, etc.).
Otherwise, I expect the structures/groupings we already have in the IM
will be reused nicely. However, we will need to register the IM as
well as we need to import it.
I’m not sure to understand the last part of the following:
==
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.".
=
The tooling (pyang, etc.) still work even with the current IM in the
draft. Also, the module can be imported/augmented/etc.
Please note that even **fake** modules were registered! Think about
ietf-template for example:
==
ietf-template ietf-templ...@2010-05-18.yang N
urn:ietf:params:xml:ns:yang:ietf-template temp [RFC6087]
This is mistake IMO.
I had to create an "exclude" file in the yangcatalog.org, to exclude
those types of non-useful YANG modules.
Regards, Benoit
===
Thank you.
Cheers,
Med
*De :*Benoit Claise <benoit.cla...@huawei.com>
*Envoyé :* jeudi 21 novembre 2024 18:22
*À :* Joe Clarke (jclarke) <jcla...@cisco.com>; Evans, John
<jevan...@amazon.co.uk>; opsawg@ietf.org; opsawg-cha...@ietf.org
*Cc :* Pylypenko, Oleksandr <o...@amazon.com>; Jeff Haas
<jh...@juniper.net>; BOUCADAIR Mohamed INNOV/NET
<mohamed.boucad...@orange.com>; Aviran Kadosh (akadosh)
<akad...@cisco.com>
*Objet :* Re: draft-ietf-opsawg-discardmodel
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>
<mailto:jevan...@amazon.co.uk>
*Date: *Wednesday, November 13, 2024 at 06:53
*To: *opsawg@ietf.org <opsawg@ietf.org> <mailto:opsawg@ietf.org>,
opsawg-cha...@ietf.org <opsawg-cha...@ietf.org>
<mailto:opsawg-cha...@ietf.org>
*Cc: *Pylypenko, Oleksandr <o...@amazon.com>
<mailto:o...@amazon.com>, Jeff Haas <jh...@juniper.net>
<mailto:jh...@juniper.net>, mohamed.boucad...@orange.com
<mohamed.boucad...@orange.com>
<mailto:mohamed.boucad...@orange.com>, Aviran Kadosh (akadosh)
<akad...@cisco.com> <mailto: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.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
