Hello Lada! > -----Original Message----- > From: iesg <iesg-bounces@xxxxxxxx> On Behalf Of Ladislav Lhotka > Sent: Monday, November 18, 2019 2:06 AM > To: Paul Wouters <paul@xxxxxxxxx>; Roman Danyliw <rdd@xxxxxxxx> > Cc: iesg@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Yang update from IESG ? > > On Mon, 2019-11-18 at 01:10 -0500, Paul Wouters wrote: > > On Mon, 18 Nov 2019, Roman Danyliw wrote: > > > > [ cc:ing ietf@xxxxxxxx for wider discussion, see attachment for Design > > Patterns ] > > > > > Paul Wouters wrote: > > > > During a plenary at the last or second last IETF, I raised an > > > > issue about people stuffing incomplete and obsolete/deprecated > > > > partial IANA registiries in yang drafts/RFCs. The IESG confirmed > > > > this as a problem to me and one of the IESG members said they were > > > > aware and would get back on this. > > > > > > > > I have not heard anything. The issue is still a problem. > > > > Originally, this came up in i2nsf/ipsecme, and has now resurfaced > > > > for me in dnsop. > > > The IESG talked about this issue during the last IETF meeting. See > > > attached. > > > > > > The outcome of this discussion was that there is no single "right answer" > > > and individual ADs should intervene on specific instances as appropriate. > > > > Thanks for the answer. Unfortunately, it is not much of guidance and > > does not really address the issue I raised, namely that we are putting > > snapshots of IANA registries in RFC documents. One of your three > > Design Patterns still does this. > > The snapshot should represent the consensus of a corresponding working group > regarding the best way of modelling a given IANA registry in YANG. After the > publication of that RFC, IANA is expected to update the YANG module along > with the registry so as to keep both in sync. > > I do agree that careless YANG modellers that don't bother to read the RFC > could take the YANG module snapshot published therein as the most recent > revision because the RFC itself isn't updated. Perhaps the purpose and expeced > use of the module can be stated more clearly in the RFC, but it still won't help > those who don't read it. > > > > > Note also that Design Pattern #1 you quote is exactly the one I am > > trying to avoid from happening and Design Pattern #2 happened because > > I _did_ convince those people not to do Design Pattern #1. > > I strongly disagree with the statement that design pattern #1 cannot be > updated. > > First, as described in draft-lhotka-dnsop-iana-class-type-yang-02, the YANG > module is expected to be updated (by IANA) every time the corresponding > registry changes. So the enumeration can be updated with new mnemonic > names. I agree with your analysis of draft-lhotka-dnsop-iana-class-type-yang. I had intended "design pattern #1" to be a simple hard coded registry in a YANG module. I erroneously used a snippet of the YANG modules from draft-lhotka-dnsop-iana-class-type-yang-00 without considering the IANA guidance in Section 4. The design pattern used in this document was not captured in the presentation. My apologizes for this mischaracterization. Apologetically, Roman
