Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Apr 2013 20:34:21 +0200

On Fri, Mar 22, 2013 at 05:53:03PM +0100, Benoit Claise wrote:
> Hi Martin, netmod participants,
> 
> - IANAifType-MIB http://www.iana.org/assignments/smi-numbers/smi-numbers.xml
> There is a new value 273, which should be added to the draft, at
> first glance.
> Note: this entry 273 is called "Reserved". This is a weird name,
> because there is RFC6825 next to it.
> Am I correct that, if a second entry is called "Reserved", the enum
> would break?

This issue has been further discussed between Benoit, Dan Romascanu
(the expert for the ifType registry), the NETMOD chairs and IANA.  We
arrived at the conclusion that reserved ifType numbers should show up
in both the YANG module and the SNMP module. (Technically, IANA
maintains a primary registry and two serializations, one in SMIv2
format and one in YANG format.) In order to ensure that we have unique
'labels' for the allocated numbers, IANA is expected to use 'labels'
of the form reserverXYZ where XYZ is replaced by the allocated number.
In other words, the entry for 273 would be something like this:

         enum "reserved272" {
           value 272;
           description
             "Reserved by IANA";
         }

Please speak up now if you believe this is not a workable solution.
Martin, if there are no objections raised within a few days, please
produce a new I-D which includes this allocation and perhaps 1-2
sentences that help IANA understand that reserved ifTypes should be
treated as described above. (Perhaps you can draft the edits and send
them to the list for review before posting a new I-D.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Apr 2013 21:33:00 +0200 (CEST)

> Please speak up now if you believe this is not a workable solution.

At first glance, this seems weird.  The point of reserving a value in
a registry is to make sure the value (or label) is not used by anyone
else.  But since it is reserved it would not be used.  So when it
actually shows up like this with a dummy label it looks quite
confusing.

>From a technical YANG point of view, this is problematic, since you
are not allowed to modify the enum label, one published (see section
10 of RFC 6020).

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Apr 2013 21:45:03 +0200

> are not allowed to modify the enum label, one published (see section

Oops, we apparently missed that part of YANG update rules which is
different from the SMIv2 update rules. So what would you propose?
Have reserved values marked only in the registry but not show up in
the SMIv2 / YANG serializations? I think someone involved in the
discussion was arguing against this solution. I need to check.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Apr 2013 22:16:20 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > > > - IANAifType-MIB
> > > > - http://www.iana.org/assignments/smi-numbers/smi-numbers.xml
> the SMIv2 / YANG serializations?

Yes.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 9 Apr 2013 10:19:28 +0200

>> the SMIv2 / YANG serializations?

+1

Lada

> 
> 
> /martin
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C