RE: Yang update from IESG ?

[Roman Danyliw <[e-mail]>]

Hello Lada!

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Ladislav Lhotka
> Sent: Monday, November 18, 2019 2:06 AM
> To: Paul Wouters <[e-mail]>; Roman Danyliw <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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 [e-mail] 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