Subject: RE: Yang update from IESG ?

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Nov 2019 01:10:48 -0500 (EST)

On Mon, 18 Nov 2019, Roman Danyliw wrote:

[ cc:ing [email-masked] 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.

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 would like to see the IESG discourage/forbid Design Pattern #1. The
"yang native" advantage of this Design Pattern seems odd to me, because
as far as I know there will be specific yang documents created elsewhere
anyway that are supposed to be updated and used by automation tools?

Paul

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Nov 2019 15:05:49 +0800

On Mon, 2019-11-18 at 01:10 -0500, Paul Wouters wrote:
> > The outcome of this discussion was that there is no single "right answer"
> > and individual ADs should intervene on specific instances as appropriate.
> 

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.  

> 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.

And second, implementors of the YANG module can in fact use the type 'dns-class' 
that is defined as follows:In effect, the 'dns-class' type combines desing
patterns #1 and #2. BTW, t

     typedef dns-class {
       type union {
         type uint16;
         type dns-class-name;
       }
       description
         "This type allows for referring to a DNS class using either the
          assigned mnemonic name or numeric value.";
     }

I apologize to those who don't speak YANG but the meaning should be clear: if
somebody wants to use a DNS class that is not defined in the 'dns-class-name'
enumeration, he or she can use the numeric value instead. This is analogical to
using CLASS42 in other contexts as per RFC 3597.

In effect, the 'dns-class' type above combines design patterns #1 and #2.

Roman's presentation also doesn't mention another design pattern that was used
in the aforemetioned RFC 7224 for the interface types registry, namely to model
interface types as YANG identities.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 18 Nov 2019 08:36:36 +0000

Hello Lada!

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Ladislav Lhotka
> Sent: Monday, November 18, 2019 2:06 AM
> To: Paul Wouters <[email-masked]>; Roman Danyliw <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: Yang update from IESG ?
> 
> > > > 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.
> > snapshots of IANA registries in RFC documents. One of your three
> > Design Patterns still does this.
> 
> 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.
> 
> >
> 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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Nov 2019 21:26:21 +0800

Paul Wouters <[email-masked]> 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 outcome of this discussion was that there is no single "right
    >> answer" and individual ADs should intervene on specific instances as
    >> appropriate.

    > Patterns still does this.

I also am unhappy with this situation.

As far as I can tell it means that IANA will be maintaining YANG modules.
I don't understand how this is going to work for real products.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Nov 2019 22:07:29 +0800

> I don't understand how this is going to work for real products.

IANA has been doing it for more than five years for a couple of YANG modules
(six by now), and I am not aware of any troubles so far.

Lada

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 18 Nov 2019 22:49:15 +0800

But that's work put onto the IANA pile, and some I* organization may want
to understand the
commitment.

On Mon, Nov 18, 2019 at 10:08 PM Ladislav Lhotka <[email-masked]> wrote:

> issue
> Originally,
> >     >> The IESG talked about this issue during the last IETF meeting.
> See
> >     >> attached.
> >     >>

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 18 Nov 2019 08:55:44 -0800

Hi -

On 11/17/2019 11:05 PM, Ladislav Lhotka wrote:
...
 > the registry so as to keep both in sync.
...

Have you considered doing what the ltru WG did in the course of 
producing BCP 47?
The I-D handed off to the RFC editor had a working copy of the registry 
content,
with instructions to remove that portion of the content upon 
publication.  It required
a little coordination with IANA, but avoided the problem of anyone ever 
mistaking
the RFC for the registry.  The same might be a possible course of action 
with modules
like these.

Randy

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Nov 2019 17:13:23 -0600

We do have a working group that is chartered to deal with general/common 
issues with YANG -- NetMod.  I suggest that this be hashed out there. -- 
Of course the ADs need to concur...

Lou

NetMod Co-chair

On 11/18/2019 8:49 AM, Tim Wicinski wrote:
> But that's work put onto the IANA pile, and some I* organization may 
> want to understand the
> commitment.
>
> On Mon, Nov 18, 2019 at 10:08 PM Ladislav Lhotka <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > Paul Wouters <[email-masked] <mailto:[email-masked]>> 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.
>     >

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Nov 2019 13:26:32 +0800

Tim Wicinski <[email-masked]> wrote:
    >> IANA has been doing it for more than five years for a couple of YANG
    >> modules (six by now), and I am not aware of any troubles so far.

    > want to understand the commitment.

And, I don't understand how the products get updated.
Are they going to pull YANG modules from IANA?  How often: hourly? daily? yearly?

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Nov 2019 15:31:39 +0800

> Are they going to pull YANG modules from IANA?  How often: hourly? daily?

Products get updated ad hoc, as soon as their implementors feel the need. This
usually has to be accompanied with changes in the underlying system - actually
implementing support for new registry entries etc.

Lada

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Nov 2019 16:50:35 +0800

Ladislav Lhotka <[email-masked]> wrote:
    >> Tim Wicinski <[email-masked]> wrote: >> IANA has been doing it for
    >> more than five years for a couple of YANG >> modules (six by now), and
    >> I am not aware of any troubles so far.
    >> 
    >> And, I don't understand how the products get updated.  Are they going
    >> to pull YANG modules from IANA?  How often: hourly? daily?  yearly?

    > Products get updated ad hoc, as soon as their implementors feel the
    > need. This usually has to be accompanied with changes in the underlying
    > system - actually implementing support for new registry entries etc.

So if software (including management software) needs explicit support for new
IANA entries (in for instance, lists of ciphers), then why is it better for
the (human) programmer to download a new YANG module than to just read the IANA web
pages (or .XML equivalent)?

(It's not like the YANG description will have executable code for SHA4 or something)

---

From: tom petch <[email-masked]>
Date: Tue, 19 Nov 2019 09:46:10 +0000

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Monday, November 18, 2019 2:07 PM

Originally,
> >     >> The IESG talked about this issue during the last IETF
meeting.  See
> IANA has been doing it for more than five years for a couple of YANG
modules
> (six by now), and I am not aware of any troubles so far.

In fact, this practice, of having IANA maintain modules, goes back to at
least RFC2677 in August 1999 so I would expect any troubles to have come
to light by now.

Tom Petch

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Nov 2019 09:48:36 +0000

Scaling could expose problems not noticed when it's onesie-twosies.

---

From: Benoit Claise <[email-masked]>
Date: Sun, 24 Nov 2019 21:43:35 +0800

Maybe this is already solved during the IETF week.
If not, read my answer below ..
> pages (or .XML equivalent)?
The point is that you download the IANA-maintained YANG modules on 
regular basis (ex: typical interface types) for the management software 
that speaks YANG. A cronjob does the job.
Since the new YANG module is backward compatible, the software works 
automatically (for the new interface type) with the new YANG module. 
Exactly like the IfType defintions for MIB modules (see 
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml).

Regards, B.