Subject: [MIB-DOCTORS] what to do with "reserved" interface types?

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Apr 2013 17:43:53 +0200

Dear all,

This email is sent to the MIB doctors, the YANG doctors, Dan Romascanu 
(the expert for the ifType registry), and IANA.

The NETMOD WG has been discussing the draft-ietf-netmod-iana-if-type 
draft, and in particular what to do with "reserved" entries in the 
ifType definitions 
http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-5
There is right now one entry: the latest one, 273

In the YANG module, the issue stems from the fact that the interface 
name is the "key". So we can't have multiple "Reserved" entries.
We proposed not to model the "Reserved" entries in the 
draft-ietf-netmod-iana-if-type YANG module.
See http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-if-type-05 
for the new proposal

Now, what about 
http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib ?
Should we add this new 273 "reserved" entry?
The proposal is not to add it, for consistency reason with the YANG module.
What do you think? As far as I can tell, the "IANA considerations" is at 
http://tools.ietf.org/html/rfc2863#section-3.1.10
Can we simply change the notes at 
http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-5?

Please let us know if you see any issue.

Regards, Benoit

-------- Original Message --------
Subject: 	New Version Notification - draft-ietf-netmod-iana-if-type-05.txt
Date: 	Wed, 17 Apr 2013 07:47:25 -0700
From: 	[email-masked]
To: 	[email-masked], 
[email-masked], [email-masked]

A new version (-05) has been submitted for draft-ietf-netmod-iana-if-type:
http://www.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-05.txt

Sub state has been changed to AD Followup from Revised ID Needed

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-if-type-05

IETF Secretariat.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Apr 2013 18:02:11 +0200

On Wed, Apr 17, 2013 at 05:43:53PM +0200, Benoit Claise wrote:
 
> See

I think the most important argument is that reserved values are
operationally not useful since they are not used. If they get assigned
later (means they become operationally useful), we would have to
change the label associated with it (which is problematic) if the
reserved numbers would be listed in a MIB module (or YANG module).  To
avoid this complication, the idea is to not list reserved values in
the YANG and MIB modules.

/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: Benoit Claise <[email-masked]>
Date: Wed, 17 Apr 2013 18:48:53 +0200

> the YANG and MIB modules.
Yes, you're right.

Regards, Benoit

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Wed, 17 Apr 2013 19:01:58 +0000

Hi,

Quick request: for IETF-stats-tracking reasons, unless replying to a message from IANA, please use this address or [email-masked]. 

thanks,

Amanda Baber
IANA

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Apr 2013 07:20:21 +0000

Yet, from the documentation perspective in MIB module and maybe also in the YANG module maintained by IANA I believe it is useful to insert a commented line that mentions that the equivalent value of transmission was defined and by whom (what). 

Regards,

Dan
 
> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2013 7:49 PM
> To: MIB Doctors (E-mail); YANG Doctors; Amanda Baber via RT; Romascanu,
> Dan (Dan)
> Subject: Re: [yang-doctors] what to do with "reserved" interface types?
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2013 09:31:03 +0200

On Thu, Apr 18, 2013 at 07:20:21AM +0000, Romascanu, Dan (Dan) wrote:

> Yet, from the documentation perspective in MIB module and maybe also
> in the YANG module maintained by IANA I believe it is useful to
> insert a commented line that mentions that the equivalent value of
> transmission was defined and by whom (what).

I have to insist that reserved is not the same as defined. In this
particular case, a MIB module was registered under the transmission
branch (I do not really understand why but that is a mood point now)
and because of that the corresponding ifType value is reserved. This
value is not defined in any way.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Apr 2013 07:37:23 +0000

Hi Juergen,

I do not get it. I do not understand what you mean by 'reserved is not the same as defined'. 

We want to prevent people requesting the ifType value to be assigned (don't we?). I accept your point that using a 'reserved' or 'reserved_xxx' enumerated value is not a good thing. Do you believe that a commented line is wrong or harmful in any way? 

Thanks and Regards,

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, April 18, 2013 10:31 AM
> To: Romascanu, Dan (Dan)
> Cc: Benoit Claise; MIB Doctors (E-mail); YANG Doctors; Amanda Baber via
> RT
> Subject: Re: [MIB-DOCTORS] [yang-doctors] what to do with "reserved"
> interface types?
> 
> > in the YANG module maintained by IANA I believe it is useful to insert
> > a commented line that mentions that the equivalent value of
> branch (I do not really understand why but that is a mood point now) and
> because of that the corresponding ifType value is reserved. This value
> is not defined in any way.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2013 09:48:53 +0200

> I do not get it. I do not understand what you mean by 'reserved is not the same as defined'. 

Reserved for me means it won't generally be assigned and thus be
defined. In this particular case, I doubt it will ever be defined.

> We want to prevent people requesting the ifType value to be assigned
> (don't we?). I accept your point that using a 'reserved' or
> 'reserved_xxx' enumerated value is not a good thing. Do you believe
> that a commented line is wrong or harmful in any way?

To register a new ifType value, you have to contact IANA and they have
in their register already a note that this value is reserved. In fact,
my understanding is that the procedure pretty much is that you request
a new ifType to be assigned and if you pass the expert review, IANA
assigns the next non-reserved value. It is not that the requester
picks a value and then IANA assigns that value. Hence, having reserved
values marked in comments in MIB or YANG modules likely is not really
solving a problem, but yes it is also not harmful (except perhaps a bit
more work for IANA).

I will not object if you insists on having comments. But then the
comment should say 'reserved' not 'defined'.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Apr 2013 07:58:17 +0000

Hi Juergen,

See in-line. 

Thanks and Regards,

Dan

> Sent: Thursday, April 18, 2013 10:49 AM
> To: Romascanu, Dan (Dan)

[[DR]] We agree on this. 

> my understanding is that the procedure pretty much is that you request a
> new ifType to be assigned and if you pass the expert review, IANA
> assigns the next non-reserved value. It is not that the requester picks
> a value and then IANA assigns that value. Hence, having reserved values
> marked in comments in MIB or YANG modules likely is not really solving a
> problem, but yes it is also not harmful (except perhaps a bit more work
> for IANA).
> 

[[DR]] In this case for all practical purposed the registry IS the MIB module. The process ideally works as you have described it, but in practice some implementers may look up one of the next values that seems to be free and use it and then ask IANA - please allocate us THIS value. Yes, it's not a good practice, we need not encourage them, but it happens, and if we can help at low cost by documenting what is already reserved because transmission used the value - why not?  

> comment should say 'reserved' not 'defined'.

[[DR]] Sure.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2013 10:03:59 +0200

On Thu, Apr 18, 2013 at 07:58:17AM +0000, Romascanu, Dan (Dan) wrote:
> 
> [[DR]] In this case for all practical purposed the registry IS the
> MIB module.

No. The registry is IANA's record in their XML database. The XML
database is then serialized into a MIB module and an YANG module. This
is why we have the discrepancy we are currently discussing.

> The process ideally works as you have described it, but
> in practice some implementers may look up one of the next values
> that seems to be free and use it and then ask IANA - please allocate
> us THIS value. Yes, it's not a good practice, we need not encourage
> them, but it happens, and if we can help at low cost by documenting
> what is already reserved because transmission used the value - why
> not?

It is broken practice. Perhaps instead of helping broken practice, I
rather suggest to add clear warnings to the IANA MIB module that
explain that picking values without going through IANA is broken and
there won't be any guarantee that such picked values will later be
assigned.

/js (who still believes it is possible to educate people)

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Apr 2013 08:10:09 +0000

Hi Juergen,

See in-line. 

Regards,

Dan

> Sent: Thursday, April 18, 2013 11:04 AM
> To: Romascanu, Dan (Dan)
> Cc: Benoit Claise; MIB Doctors (E-mail); YANG Doctors
> > [[DR]] In this case for all practical purposed the registry IS the MIB
> > module.
> 
[[DR]] You missed the words 'for all practical purposes' in my statement. MIB designers know the IANA MIB module, YANG designers know the IANA YANG module.  

> > The process ideally works as you have described it, but in practice
> > some implementers may look up one of the next values that seems to be
> > free and use it and then ask IANA - please allocate us THIS value.
> > Yes, it's not a good practice, we need not encourage them, but it
> > happens, and if we can help at low cost by documenting what is already
> > reserved because transmission used the value - why not?
> 
> rather suggest to add clear warnings to the IANA MIB module that explain
> that picking values without going through IANA is broken and there won't
> be any guarantee that such picked values will later be assigned.
> 
[[DR]] Yes, it's broken practice but we live in the real world, our 'customers' are in many cases people who are paid to write code under time pressure, and I believe that in parallel with educating them we also need to help them by inserting proper documentation that warns against common mistakes.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Apr 2013 11:15:14 +0000

wfm

Dan

> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Thursday, April 18, 2013 2:09 PM
> To: Martin Bjorklund
> Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> On Apr 18, 2013, at 1:06 PM, Martin Bjorklund <[email-masked]> wrote:
> 
> > "Romascanu, Dan (Dan)" <[email-masked]> wrote:
> >>
> >>
> >>
> > I agree.  I am not sure how detailed we should be in the instructions
> > to IANA about what to put in the comment though.
> >
> > I would prefer this:
> >
> >   If an interface type is marked as "reserved" in the "ifType
> >   definitions" registry, no "enum" statement is added to the
> >   "iana-if-type" typedef.  Instead a comment is added, on the form:
> >
> >      // value NN is reserved by IANA
> >
> >
> > This makes it clear that a value has been reserved, and if people want
> > to know the details, they can follow the link to the authoritative
> > IANA registry.
> 
> +1
> 
> Lada
> 
> >
> >
> >
> > /martin
> > _______________________________________________
> > yang-doctors mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/yang-doctors
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Apr 2013 13:06:42 +0200 (CEST)

> transmission was defined and by whom (what).

I agree.  I am not sure how detailed we should be in the instructions to
IANA about what to put in the comment though.

I would prefer this:

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Apr 2013 13:08:56 +0200

+1

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Apr 2013 13:36:11 +0200 (CEST)

> > to know the details, they can follow the link to the authoritative

So I started to do this, and it turns out that this works fine for
ifType.  But if you look at afi/safi you will find a mix of reserved
and unassigned ranges, and ranges marked for private use.  See
e.g. http://www.iana.org/assignments/safi-namespace/safi-namespace.xml.

Should we really duplicate all this info as comments in the YANG
modules?   It is probably better to do what Juergen suggested - the
module contains the values in actually in use.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Fri, 19 Apr 2013 15:06:44 +0200

Dear all,

[copying the MIB doctors, the YANG doctors, Dan Romascanu (the expert 
for the ifType registry), and IANA, like in the initial thread]

Martin posted a new draft:

    A new version (-06) has been submitted for draft-ietf-netmod-iana-if-type:
    http://www.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-06.txt

    Diff from previous version:
    http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-if-type-06

Let us know, by Monday evening, if the resolution is fine.

In terms of 
http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib, do we 
want to add
     -- // value 273 reserved by IANA
If yes, we should change the IANA considerations.
Can we simply change the notes at 
http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-5, 
and have something similar to the IANA considerations section from 
draft-ietf-netmod-iana-if-type-06?

And similarly for AFI/SAFI?

Regards, Benoit

> What do you think? As far as I can tell, the "IANA considerations" is 
> at http://tools.ietf.org/html/rfc2863#section-3.1.10
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Fri, 19 Apr 2013 21:01:15 +0000

Hi Benoit,

A couple of notes:

This draft needs to instruct IANA to add it as a reference and add a note pointing out that concurrent registration in the YANG module is required for each of the relevant registries.

Also, it seems that reserved entries with a reference should be described as "reserved by RFCXXXX" rather than "reserved by IANA," since IANA didn't request the reservation.

It's also not clear to why registrations marked "Reserved for Private Use" with a reference of RFC4760 at http://www.iana.org/assignments/safi-namespace are listed as "For Private Use" with no reference at all in the module. Why are these listings different from the ones in the registry? If an RFC designates more values "Reserved for Private Use" in this registry in the future, how will we know to truncate the name and leave out the reference, when other entries in the registry are reproduced precisely?

Finally, about the solution for the ianaiftype-mib itself: Juergen and Dan suggested "reserved273(273) -- transmission value assigned by RFC 6825." We vastly prefer citing either the RFC that registered the transmission number or the RFC that requires the corresponding ifType reservation to citing IANA as the reference. From our point of view, marking reserved entries as "Reserved by IANA" is roughly equivalent to making the references for all registrations "Registered by IANA."

thanks,
Amanda

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 19 Apr 2013 23:25:23 +0200 (CEST)

Hi Amanda,

"Amanda Baber via RT" <[email-masked]> wrote:
> Hi Benoit,
> 
> A couple of notes:
> 
> This draft needs to instruct IANA to add it as a reference

I am sorry, but I do not understand what this means.

> and add a note
> pointing out that concurrent registration in the YANG module is required for
> each of the relevant registries.

Same here, what does this mean?

> Also, it seems that reserved entries with a reference should be described as
> "reserved by RFCXXXX" rather than "reserved by IANA," since IANA didn't request
> the reservation.

Ok.  I assume the comment would be

   // value NN is reserved by XX

since not all registrations (and I assume reservations) are done in
RFCs, right?

> It's also not clear to why registrations marked "Reserved for Private Use" with
> a reference of RFC4760 at http://www.iana.org/assignments/safi-namespace are
> listed as "For Private Use" with no reference at all in the module. Why are
> these listings different from the ones in the registry? If an RFC designates
> more values "Reserved for Private Use" in this registry in the future, how will
> we know to truncate the name and leave out the reference, when other entries in
> the registry are reproduced precisely?

You are correct; this was my fault.  It should be like this:

      enum private-241 {
        value "241";
        description
          "Private Use";
        reference
          "RFC 4760: Multiprotocol Extensions for BGP-4";
      }

> Finally, about the solution for the ianaiftype-mib itself: Juergen and Dan
> suggested "reserved273(273) -- transmission value assigned by RFC
> 6825."

This solution was discussed, but we agreed that it is not a proper
solution since the reservation means that the value must not be used -
but by creating a proper enumeration (in the MIB or YANG module) the
value *can* be used.

The idea then was to add a comment that the value has been reserved in
the registry, to help human readers.

> We
> vastly prefer citing either the RFC that registered the transmission number or
> the RFC that requires the corresponding ifType reservation to citing IANA as
> the reference. From our point of view, marking reserved entries as "Reserved by
> IANA" is roughly equivalent to making the references for all registrations
> "Registered by IANA."

I see your point.

Is this solved by the proposal above?

For the MIBs, the corresponding comment would be

  -- value NN is reserved by XX

/martin

---

From: "Martin Bjorklund via RT" <[email-masked]>
Date: Fri, 19 Apr 2013 21:43:00 +0000

Hi Amanda,

      enum private-241 {
        value "241";
        description
          "Private Use";
        reference

I see your point.

/martin

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Fri, 19 Apr 2013 22:12:19 +0000

Hi,

> I am sorry, but I do not understand what this means.

Sorry, I said this in a convoluted way. I meant that this document needs to tell us to make it an additional reference for the Address Family Numbers registry itself (for example), along with [RFC2453][RFC2858]. 

A good way to do this might be something like

OLD:
Address Family Numbers
Reference[RFC2453][RFC2858]

NEW:
Address Family Numbers
Reference[RFC2453][RFC2858][RFCXXXX]

It also needs to tell us to add a note (and ideally give us the text of the note) to add to the top of each affected registry that will tell us (and registry users) that for each registration, IANA must make registrations in [whichever registry]. 

There's a high potential for missed registrations in lockstep registries.

> since not all registrations (and I assume reservations) are done in

Sounds good.

>           "RFC 4760: Multiprotocol Extensions for BGP-4";

I forgot about this. I'm a little puzzled by the inclusion of the RFC title because I can't think of any other registries that do this. It would actually be worth noting in the IANA Considerations section that this is the type of reference you require.

This might be a good/easy way to list it for us (the data I'm presenting might actually be wrong):

Registration fields:

Value: replicate the value from the original registry 

Description: replicate the registration from the original registry

Reference: (describe the way a name, RFC, or other type of document should be presented)

Status: include only if a registration has been deprecated or obsoleted (?)

You should also note that unassigned ranges shouldn't be listed. (Apologies if I missed this.)

 As for the registry I think we'd prefer that the description replicated the original registry's description precisely, and used "Reserved for Private Use," if that's what appears in the registry, rather than "Private Use."
 
> the registry, to help human readers.

OK. I was under the impression that we aren't allowed to simply place a comment in this registry. As the designated expert, Dan will have to sign off on this before publication.

>   -- value NN is reserved by XX

Works for us. Thanks!

Amanda

> > >     A new version (-06) has been submitted for draft-ietf-netmod-
> iana-
> > > if-type:
> > > > See http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-if-
> type-
> > > 05
> > > > for the new proposal
> > > >
> > > > Now, what about
> > > > The proposal is not to add it, for consistency reason with the
> YANG
> > > > module.
> > > > What do you think? As far as I can tell, the "IANA
> considerations"
> > > is
> > > > A new version (-05) has been submitted for draft-ietf-netmod-
> iana-
> > > if-type:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-
> type-
> > > 05.txt
> > > >

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 20 Apr 2013 22:51:11 +0200 (CEST)

Hi,

"Amanda Baber via RT" <[email-masked]> wrote:
> Sorry, I said this in a convoluted way. I meant that this document needs to
> tell us to make it an additional reference for the Address Family Numbers
> registry itself (for example), along with [RFC2453][RFC2858].
> 

Ok.  Is this ok:

  The Reference text in the "ifType definitions" registry needs to be
  updated as:
  
    OLD:
      [RFC1213][RFC2863]
    
    NEW:
      [RFC1213][RFC2863][RFCXXXX]

(and similar for the other two registries).

BTW, the "Subsequent Address Family Identifiers" registry that we
refer to is actually named "SAFI Values", right?  I will change to
this name instead.

> It also needs to tell us to add a note (and ideally give us the text of the
> note) to add to the top of each affected registry that will tell us (and
> registry users) that for each registration, IANA must make registrations in
> [whichever registry].
> 

Ok.  I thought that the current text would solve this problem:

  The iana-if-type module is intended to reflect the "ifType
  definitions" registry.  When an interface type is added to this
  registry, a new "enum" statement must be added to the "iana-if-type"
  typedef [...]

The document does not create any new registries; it merely defines a
new "reflections" of three existing registries.

But what you ask for certainly makes sense to me.  Does this work:

  IANA is requested to add this new Note to the "ifType definitions"
  registry:
 
    When this registry is modified, the YANG module iana-if-type must
    be updated as defined in RFC XXXX.

[Side note - shouldn't a similar note be written for the
IANAifType-MIB?]

> I forgot about this. I'm a little puzzled by the inclusion of the RFC title
> because I can't think of any other registries that do this. It would actually
> be worth noting in the IANA Considerations section that this is the type of
> reference you require.

We can remove the title if you prefer this.  The only reason we added
the title is to make it easier to the human reader (one extra lookup
is avoided).

> You should also note that unassigned ranges shouldn't be listed. (Apologies if

I tried to rewrite the text according to this template.  The complete
text for the ifType registry would be:

   The iana-if-type module is intended to reflect the "ifType
   definitions" registry.  When an interface type is added to this
   registry, a new "enum" statement must be added to the "iana-if-type"
   typedef.  The name of the "enum" is the same as the corresponding
   enumeration in the IANAifType-MIB.  The following substatements to
   the "enum" statement should be defined:

     "value": Replicate the value from the registry.

     "status": Include only if a registration has been deprecated (use
               the value "deprecated" or obsoleted (use the value
               "obsolete").

     "description": Replicate the description from the registry, if any.

     "reference": Replicate the reference from the registry, if any.

   Unassigned values are not present in the module.

   When the iana-if-type YANG module is updated, a new "revision"
   statement must be added.

   The Reference text in the "ifType definitions" registry needs to be
   updated as:

     OLD:
       [RFC1213][RFC2863]

     NEW:
       [RFC1213][RFC2863][RFCXXXX]

I noticed that there are no rules (that I can see) for how you
construct a MIB enumeration label out of the name of an ifType in the
registry.  For example, in the registry, value 7 has the Name
"IEEE802.3", but the label in the MIB is "iso88023Csmacd".  Ok, it
also seems that recent names actually match the MIB name one-to-one,
so maybe this is not a problem.   But how is this done for the
"Address Family Numbers" registry and corresponding
IANA-ADDRESS-FAMILY-NUMBERS-MIB?   I guess we need to figure something
out for the SAFI values.

>  As for the registry I think we'd prefer that the description replicated the
>  original registry's description precisely, and used "Reserved for Private
>  Use," if that's what appears in the registry, rather than "Private Use."

The text "Private Use" seems to be what appears in the registry, (from
http://www.iana.org/assignments/safi-namespace/safi-namespace.xml)
that's why I used it.

/martin

> OK. I was under the impression that we aren't allowed to simply place a comment
> in this registry. As the designated expert, Dan will have to sign off on this
> before publication.
> 
> > > We
> > > > type-06.txt

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Thu, 25 Apr 2013 17:08:22 +0000

Hi Martin,

Sorry I took so long on this one. With some cuts:

> > OLD: Address Family Numbers Reference[RFC2453][RFC2858]
> > > > > > > >
> > NEW: Address Family Numbers Reference[RFC2453][RFC2858][RFCXXXX]
> > > > > > > 
> Ok.  Is this ok:
> 
>   The Reference text in the "ifType definitions" registry needs to
>   be updated as:
> 
>     OLD: [RFC1213][RFC2863]
> 
>     NEW: [RFC1213][RFC2863][RFCXXXX]
> 

All of this works. Thanks!

> > It also needs to tell us to add a note (and ideally give us the
> > text
> of the
>   registry, a new "enum" statement must be added to the
>   "iana-if-type" typedef [...]
> 
>     When this registry is modified, the YANG module iana-if-type
>     must be updated as defined in RFC XXXX.
> 
> > > > 
This note works, and you're right. We'll add a note there, too.

> > because I can't think of any other registries that do this. It
> > would
> actually
> We can remove the title if you prefer this.  The only reason we
> added the title is to make it easier to the human reader (one extra
> lookup is avoided).
> 

Including them makes sense. The text-only registries IANA maintained
before adopting XML included detailed reference sections, since there
was no link to follow. If you decide to keep the titles, the
document's description of the reference section should probably be
changed to something like "'reference': Replicate the reference from
the registry, if any, and add the title of the document," since none
of the registries that have been converted to XML list the titles.

> > This might be a good/easy way to list it for us (the data I'm
> presenting might
> > actually be wrong):
> > > > > > > >
> > Registration fields:
> > > > > > > >
> > Reference: (describe the way a name, RFC, or other type of document
> should be
> > presented)
> > > > > > > >
> > You should also note that unassigned ranges shouldn't be listed.
> (Apologies if
> > I missed this.)
> > > > > > > 
> I tried to rewrite the text according to this template.  The
> complete text for the ifType registry would be:
> 
>    registry, a new "enum" statement must be added to the "iana-if-
>    type" typedef.  The name of the "enum" is the same as the
>    corresponding enumeration in the IANAifType-MIB.  The following
>    substatements to the "enum" statement should be defined:
> 
>      "status": Include only if a registration has been deprecated
>      (use the value "deprecated" or obsoleted (use the value
>      "obsolete").
> 
>      // >      // >      // > 
>    The Reference text in the "ifType definitions" registry needs to
>    be updated as:
> 
>      OLD: [RFC1213][RFC2863]
> 
>      NEW: [RFC1213][RFC2863][RFCXXXX]
> 
> > 

This works for us, thanks.

> construct a MIB enumeration label out of the name of an ifType in
> the registry.  For example, in the registry, value 7 has the Name
> IANA-ADDRESS-FAMILY-NUMBERS-MIB?   I guess we need to figure
> something out for the SAFI values.
> 
> > 
> > 

I have to point you to Dan on the ifType question, since he's the
IESG-designated expert for ifTypes.

I was delighted to find out on account of this thread that the mib
associated with Address Family Numbers registry has in fact not been
updated in several years. We'll have to identify the person who can
tell us how to format new entries, since the registration procedures
for Address Family Numbers don't require a registry expert.

> http://www.iana.org/assignments/safi-namespace/safi-namespace.xml)

Yikes, my mistake. I must have been looking at the wrong registry.

thanks, Amanda

> /> /> />

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Apr 2013 23:16:59 +0200 (CEST)

Hi Amanda,

> for Address Family Numbers don't require a registry expert.

Ok.  I also noticed that the corresponding MIB
(http://www.iana.org/assignments/ianaaddressfamilynumbers-mib/ianaaddressfamilynumbers-mib)
does not contain the assigned values 16384-16388 (assigned in the
registry).  Why is that?  Is this exclusion explained somewhere?

/martin

---

From: "Martin Bjorklund via RT" <[email-masked]>
Date: Thu, 25 Apr 2013 21:17:24 +0000

Hi Amanda,

/martin

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Thu, 25 Apr 2013 21:56:02 +0000

Hi Martin,

> registry).  Why is that?  Is this exclusion explained somewhere?

No, it's not explained anywhere. The explanation is simply that because there is no note at the top of address-family-numbers instructing us to register the numbers in the MIB, and because registrations there don't require an expert who might remind us (which isn't an expert's job to do), the fact that there was a MIB to make registrations in got lost sometime around 2006. (Allow me a sheepish note re: the fact that IANA maintains more than a thousand registries.) 

As far as I know, those values from the first-come, first-served range need to be added to the MIB, but I have yet to find a document that actually defines the MIB. RFC 2453 refers to an "RIP Version 2" MIB, which is defined in RFC 1389, but that doesn't look helpful. The address-family-numbers page appears to be missing at least one reference.

Amanda

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Apr 2013 09:17:41 +0200 (CEST)

"Amanda Baber via RT" <[email-masked]> wrote:
> No, it's not explained anywhere. The explanation is simply that
> because there is no note at the top of address-family-numbers
> instructing us to register the numbers in the MIB, and because
> registrations there don't require an expert who might remind us (which
> isn't an expert's job to do), the fact that there was a MIB to make
> registrations in got lost sometime around 2006. (Allow me a sheepish
> note re: the fact that IANA maintains more than a thousand
> registries.)

I certainly understand this!  I thought that maybe the values from the
first-come range for some reason were designed to not show up in the
MIB, and if that was the case, the same would apply to the YANG
module as well.

> As far as I know, those values from the first-come, first-served range
> need to be added to the MIB, but I have yet to find a document that
> actually defines the MIB. RFC 2453 refers to an "RIP Version 2" MIB,
> which is defined in RFC 1389, but that doesn't look helpful. The
> address-family-numbers page appears to be missing at least one
> reference.

Interestingly, the IANA-ADDRESS-FAMILY-NUMBERS-MIB from
http://www.iana.org/assignments/ianaaddressfamilynumbers-mib/ianaaddressfamilynumbers-mib
has this:

      REVISION     "9908260000Z"  -- August 26, 1999
      DESCRIPTION  "Initial version, published as RFC 2677."

But this MIB is not defined in 2677.  (However, the MIB 2677 has the
exact same note, so this is probably a copy&paste error).

/martin

---

From: "Martin Bjorklund via RT" <[email-masked]>
Date: Fri, 26 Apr 2013 07:18:05 +0000

/martin