Subject: Yang and embedded IANA registries: today's episode: draft-lhotka-dnsop-iana-class-type-yang

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Jul 2019 10:14:12 -0400 (EDT)

Hi,

I would like to point out the yang discussion on dnsops about:

https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-00

archived here:

https://mailarchive.ietf.org/arch/msg/dnsop/0AjdiR8htN_vjglimt1b7z10V_E

This is another yang document that snapshots a bunch of IANA registries
into an RFC, including building references for obsolete/deprecated
items, and of course becoming obsolete pretty much immediately if these
IANA registries change. Some people are objecting and some people don't
see any problem with this approach.

We had a similar discussion during the last 2-3 IETFs at i2nsf/ipsec about
draft-ietf-i2nsf-sdn-ipsec-flow-protection that did something similar
at first, and they talked to the ipsec and yang people, and came up with
the solution of referencing the IANA registries in their latest version:

https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/

I believe I raised this question at the last plenary at the mic as well.

I believe strongly that the method of referencing the registries that the
i2nsf document does is preferable over the method of the dnsop document.

We need a IETF wide policy or guidance on how the do these things, so
that we do not end up with different policies and guidelines for
different documents or different working groups.

Have any efforts been started yet to come up with an IETF wide approach
for this recurring issue with yang?

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 11:42:35 -0400

> different documents or different working groups.

I strongly agree.

  https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-10

is a document that does nothing other than what you describe as wrong.
I haven't been able to convince the authors that this is a bad thing.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kent Watsen <[email-masked]>
Date: Tue, 16 Jul 2019 17:20:45 +0000

> i2nsf document does is preferable over the method of the dnsop document.

While this may be true, it would be helpful if you could reply to Petr's message [1] in the dnsop thread you started.  In particular, if IANA itself updates the YANG modules directly, at the same time as updating the base registry (i.e., without the initial RFC itself being updated), what issues remain?

[1] https://mailarchive.ietf.org/arch/msg/dnsop/nu8BTdaHAVrxxoqxnknkDkK-4g8 <https://mailarchive.ietf.org/arch/msg/dnsop/nu8BTdaHAVrxxoqxnknkDkK-4g8>.   

> is a document that does nothing other than what you describe as wrong.

True, and worse, that draft hasn't yet switched the YANG module to being a collection of IANA-maintained modules, as has been discussed on the list.  This change hasn't been made yet only because there is an even larger issue (i.e., lack of a universal crypto algorithm type registry) that needs to be resolved first.  This larger issue is something that the chairs have requested an early SecDir review (and, hopefully, presence during next Monday's NETCONF session) to help resolve.

> I haven't been able to convince the authors that this is a bad thing.

This is an interesting and somewhat overreaching characterization of past interactions.

Kent

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 14:33:01 -0400

Kent Watsen <[email-masked]> wrote:
    >> I believe strongly that the method of referencing the registries that
    >> the i2nsf document does is preferable over the method of the dnsop
    >> document.

    > While this may be true, it would be helpful if you could reply to
    > Petr's message [1] in the dnsop thread you started.  In particular, if
    > IANA itself updates the YANG modules directly, at the same time as
    > updating the base registry (i.e., without the initial RFC itself being
    > updated), what issues remain?

I think that I'm okay if IANA generated YANG modules from the protocol registries.
That shouldn't be in an RFC though.  I don't know how this will work with
systems that generate code from a YANG module, but I know nothing about that usage.

    > True, and worse, that draft hasn't yet switched the YANG module to
    > being a collection of IANA-maintained modules, as has been discussed on
    > the list.  This change hasn't been made yet only because there is an
    > even larger issue (i.e., lack of a universal crypto algorithm type
    > registry) that needs to be resolved first.

It just won't happen that way.

    > This is an interesting and somewhat overreaching characterization of

okay :-)
Let me say: "I haven't received communication from the authors about how they feel"

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

---

From: S Moonesamy <[email-masked]>
Date: Wed, 17 Jul 2019 22:23:06 -0700

Hi Paul,
>I would like to point out the yang discussion on dnsops about:

Ok.

>see any problem with this approach.

I'll comment below.

>I believe I raised this question at the last plenary at the mic as well.

The response from Mr Bagdonas, Area Director, was that it is an area 
which is lacking and that is his focus.

>different documents or different working groups.

There is BCP 216.

It does not make sense to turn the PTI protocol parameters registries 
into a code repository.  It defeats the purpose of having a 
registry(ies) when old references are included in the code.

Regards,
S. Moonesamy

---

From: Petr Špaček <[email-masked]>
Date: Thu, 18 Jul 2019 09:26:00 +0200

On 16. 07. 19 20:33, Michael Richardson wrote:
>>> I believe strongly that the method of referencing the
>>> registries that the i2nsf document does is preferable over the
>>> method of the dnsop document.
> 
> 
>> While this may be true, it would be helpful if you could reply
>> to Petr's message [1] in the dnsop thread you started.  In
>> particular, if IANA itself updates the YANG modules directly, at
>> the same time as updating the base registry (i.e., without the
>> initial RFC itself being updated), what issues remain?
> 
> I think that I'm okay if IANA generated YANG modules from the
> protocol registries. That shouldn't be in an RFC though.  I don't
> know how this will work with systems that generate code from a YANG
> module, but I know nothing about that usage.
> 
>> True, and worse, that draft hasn't yet switched the YANG module
>> to being a collection of IANA-maintained modules, as has been
>> discussed on the list.  This change hasn't been made yet only
>> because there is an even larger issue (i.e., lack of a universal
>> crypto algorithm type registry) that needs to be resolved first.
> 
> okay :-) Let me say: "I haven't received communication from the
> authors about how they feel"

As stated in
https://mailarchive.ietf.org/arch/msg/dnsop/nu8BTdaHAVrxxoqxnknkDkK-4g8
the primary author is not available at the moment so I suggest we wait
couple days for him to return back to the Internet. Thank you for
understanding.

-- 
Petr Špaček  @  CZ.NIC

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Jul 2019 11:03:57 -0400

Michael Richardson <[email-masked]> writes:

>     >> registries that the i2nsf document does is preferable 
>     >> over the method of the dnsop document. 
>  
>     > While this may be true, it would be helpful if you could 
>     > reply to Petr's message [1] in the dnsop thread you 
>     > started.  In particular, if IANA itself updates the YANG 
>     > modules directly, at the same time as updating the base 
>     > registry (i.e., without the initial RFC itself being 
> protocol registries.  That shouldn't be in an RFC though.  I 
> don't know how this will work with systems that generate code 
> from a YANG module, but I know nothing about that usage.

As Petr pointed out in his DNSOP mailing list message, the purpose 
of such an RFC is to provide a starting revision of the YANG 
module, plus instructions for IANA about how to reflect the 
registry changes in the module.

The experience with other similar YANG modules indicates that the 
process can actually work, see for example

https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml

For users of such modules, it is important to grab the latest 
revision from IANA rather than use the initial revision that 
appeared in the RFC. Perhaps this could be more strongly 
emphasized in the kick-off RFCs.

While we can think about other procedures and mechanisms, I'd 
suggest that we stick to the current procedure, until something 
better is available.

Lada
 
>     > True, and worse, that draft hasn't yet switched the YANG 
>     > module to being a collection of IANA-maintained modules, 
>     > as has been discussed on the list.  This change hasn't 
>     > been made yet only because there is an even larger issue 
>     > (i.e., lack of a universal crypto algorithm type registry) 
>     > that needs to be resolved first. 
> 
> --  ]               Never tell me the odds!                 | 
> ipv6 mesh networks [ ]   Michael Richardson, Sandelman Software 
> Works        |    IoT architect   [ ]     [email-masked] 
> http://www.sandelman.ca/        |   ruby on rails    [ 
> 

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Jul 2019 14:39:42 -0400

> For users of such modules, it is important to grab the latest revision
    > from IANA rather than use the initial revision that appeared in the
    > RFC. Perhaps this could be more strongly emphasized in the kick-off
    > RFCs.

    > While we can think about other procedures and mechanisms, I'd suggest
    > that we stick to the current procedure, until something better is
    > available.

To be clear... the current proceedure is:

  1) we publish an RFC with a YANG module in it, with the current IANA
     list from a registry in it.

  2) as part of the publication, IANA extracts the YANG modules and puts
     it into a repository.

  3) when IANA extends the registry, they update the YANG module.

--
]               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, 22 Jul 2019 14:56:49 -0400

>   3) when IANA extends the registry, they update the YANG module.

Yes, and for the iana-if-types it has worked satisfactorily since 2014.

It is important though that domain experts (which is the DNSOP WG in the current
case) decide about the design of the YANG module and put together the initial
revision.

Lada

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

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 23 Jul 2019 09:31:57 +0300

Please see also https://www.ietf.org/id/draft-thaler-iftype-reg-04.txt.

Dave Thaler has a slot to present and discuss this I-D in in the INTAREA WG
today (15:20-16:50)

Regards,

Dan

On Mon, Jul 22, 2019 at 9:57 PM Ladislav Lhotka <[email-masked]> wrote:

> revision
> suggest