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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2013 11:54:42 +0000

Hi Juergen,

I am moving the thread to the WG mail list, as you requested. 

The argument in the previous thread were: 

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

I fail to understand how a clarification that the value us reserved by IANA can be confusing. Actually all this thread shows that many folks (with the few exceptions of old-timers who designed MIB modules ages ago) are not aware about the parallelism between the ifTime and transmission enumerations, and the need to reserve the corresponding value if only one of them is defined. The lack of documentation seems to be the confusing element here. What am I missing? 

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

I do not understand about what modification we are talking. We discuss future entries in the enumeration, not about modifying published ones. 

Regards,

Dan

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Tuesday, April 09, 2013 12:36 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-
> netmod-iana-if-type-04
> 
> On Fri, Apr 05, 2013 at 07:22:06AM +0000, Romascanu, Dan (Dan) via RT
> wrote:
> >
> > So there are a few questions here:
> >
> > - should they show up in the MIB / YANG modules? I believe that yes,
> > they should, it provides clarity and avoids mistakes
> 
> Dan,
> 
> it seems at least Martin and Lada prefer that reserved values do not
> show up in the MIB module / YANG module but are only maintained in the
> IANA registry and I think they do have a point. See this email and
> followups:
> 
> http://www.ietf.org/mail-archive/web/netmod/current/msg07925.html
> 
> Can you please defend your suggestion that reserved values should be in
> the MIB / YANG modules on the mailing list or declare that you rethought
> things?
> 
> I like to continue the discussion on the WG mailing list since this
> avoids duplication.
> 
> /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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Apr 2013 13:59:53 +0200

> I do not understand about what modification we are talking. We discuss future entries in the enumeration, not about modifying published ones. 

If it is reserved, it might be used in the future, no? In that case,
you want to modify the 'label' but that would break YANG rules,as
Martin pointed out.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2013 12:02:39 +0000

> Sent: Tuesday, April 09, 2013 3:00 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> > I do not understand about what modification we are talking. We discuss
> future entries in the enumeration, not about modifying published ones.
> >
> 
> If it is reserved, it might be used in the future, no? In that case, you
> want to modify the 'label' but that would break YANG rules,as Martin
> pointed out.
> 
> /js
> 

[[DR]] I believe that what we mean is that it is NOT to be used in the future. Modifying the label would break SMI as well. 

Dan

---

From: Benoit Claise <[email-masked]>
Date: Tue, 09 Apr 2013 14:36:56 +0200

Dear all,
> [[DR]] I believe that what we mean is that it is NOT to be used in the future. Modifying the label would break SMI as well.
That's one of the sources of my confusion.
Reserved: is there a difference between reserved for a specific RFC and 
reserved because it will be assigned in the future?

http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-5 has 
only one Reserved, and there is a RFC next to it
However, in 
http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-7, 
I see multiple entries. For example: 50-55    Reserved    Reserved

Bottom line: the IANA considerations must explain what to do with the 
"Reserved" values, for both interface type and SAFI
And if there are two different of "Reserved" meaning, the IANA 
considerations section must explain the different treatments, if different.

Note also that there is a similar issue with "unassigned" in 
http://www.iana.org/assignments/safi-namespace/safi-namespace.xml . I 
guess that we don't want to register them

Regards, Benoit

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2013 12:57:32 +0000

> From: Benoit Claise [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2013 3:37 PM
> To: Romascanu, Dan (Dan)
> Cc: Juergen Schoenwaelder; [email-masked]
> >>>>  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).
> > [[DR]] I believe that what we mean is that it is NOT to be used in the
> future. Modifying the label would break SMI as well.
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-
> 5 has only one Reserved, and there is a RFC next to it However, in
> "Reserved" values, for both interface type and SAFI And if there are two
> different of "Reserved" meaning, the IANA considerations section must
> explain the different treatments, if different.
> 

[[DR]] I thought that ' reserved because it will be assigned in the future ' = 'unassigned'. 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Apr 2013 15:02:19 +0200

> [[DR]] I believe that what we mean is that it is NOT to be used in the future. Modifying the label would break SMI as well. 

This is incorrect, quoting RFC 2579 section 5:

(1)  A SYNTAX clause containing an enumerated INTEGER may have new
     enumerations added or existing labels changed.

I am not saying this is a good idea but the SMI allows this.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Apr 2013 15:06:54 +0200

On Tue, Apr 09, 2013 at 02:36:56PM +0200, Benoit Claise wrote:

> Reserved: is there a difference between reserved for a specific RFC
> and reserved because it will be assigned in the future?
> 
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-5
> has only one Reserved, and there is a RFC next to it
> However, in http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-7,
> Bottom line: the IANA considerations must explain what to do with
> the "Reserved" values, for both interface type and SAFI

Lets not confuse registries. The 50-55 Reserved Reserved line belongs
to the transmission OID allocations, not ifTypes (if only implicitely)
and hence this is not relevant for the document we are discussing
here.

/js

---

From: Benoit Claise <[email-masked]>
Date: Tue, 09 Apr 2013 15:04:52 +0200

On 9/04/2013 14:57, Romascanu, Dan (Dan) wrote:
>> 7,
I thought so, until I saw 
http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-7
see 50-55, 57-80, 83-93, etc...

B.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2013 13:10:57 +0000

> Sent: Tuesday, April 09, 2013 4:02 PM
> To: Romascanu, Dan (Dan)

[[DR]] I stand corrected. It does not seem a good idea, indeed.

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Apr 2013 15:18:44 +0200 (CEST)

"Romascanu, Dan (Dan)" <[email-masked]> wrote:
> I fail to understand how a clarification that the value us reserved by
> IANA can be confusing. Actually all this thread shows that many folks
> (with the few exceptions of old-timers who designed MIB modules ages
> ago) are not aware about the parallelism between the ifTime and
> transmission enumerations, and the need to reserve the corresponding
> value if only one of them is defined. The lack of documentation seems
> to be the confusing element here. What am I missing?

The confusing part is that a real value is defined in the data model,
but the intent is (?) that the value is reserved so that it is not
used by anyone else.  And for this purpose, marking it as reserved in
the registry seems perfectly fine.

> future entries in the enumeration, not about modifying published ones.

I see that Juergen replied to this.

/martin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2013 13:22:41 +0000

> From: Martin Bjorklund [mailto:[email-masked]]
> 
> but the intent is (?) that the value is reserved so that it is not used
> by anyone else.  And for this purpose, marking it as reserved in the
> registry seems perfectly fine.
> 
[[DR]] What do you mean by 'a real value is defined in the data model'? The 'real value' is for the transmission entry, but not all transmission entries map onto corresponding ifType values. The data model needs to distinguish between the two. 

Regards,

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Apr 2013 15:28:27 +0200 (CEST)

"Romascanu, Dan (Dan)" <[email-masked]> wrote:
> > used
> [[DR]] What do you mean by 'a real value is defined in the data
> model'? The 'real value' is for the transmission entry, but not all
> transmission entries map onto corresponding ifType values.

Juergen suggested this YANG:

         enum "reserved273" {
           value 273;
           description
             "Reserved by IANA";
         }

This is a real value in the typedef.  The transmission value *is* thus
mapped onto a corresponding if-type value.

/martin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2013 13:31:14 +0000

> Sent: Tuesday, April 09, 2013 4:28 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-
> netmod-iana-if-type-04
> 
> > > The confusing part is that a real value is defined in the data
> > > model, but the intent is (?) that the value is reserved so that it
> > > is not used by anyone else.  And for this purpose, marking it as
> > > reserved in the registry seems perfectly fine.
> > >

[[DR]] So? We have a label. This label cannot be changed according to RFC 6020. Rge 'description' clause explains who made the reservation. Where is the confusion? 

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Apr 2013 15:42:16 +0200 (CEST)

"Romascanu, Dan (Dan)" <[email-masked]> wrote:
> [[DR]] So? We have a label. This label cannot be changed according to
> RFC 6020. Rge 'description' clause explains who made the
> reservation. Where is the confusion?

It is probably just in the word "reserved".  It seems at least two
people interpreted this to mean "reserved for now, might be used in
the future".

May I ask what we gain by adding this enum to the module?

If we do it, maybe we could do something like this:

  enum not-used-273 {
    value 273;
    description
      "The corresponding transmission value
       is allocated according to the following
       reference.

       This enumeration must not be used by implementations.";
    reference
      "RFC 6825";
  }

(the first part of the description is the same as in the "ifType
definitions" registry.)

/martin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2013 14:04:15 +0000

> Sent: Tuesday, April 09, 2013 4:42 PM
> To: Romascanu, Dan (Dan)
> > > > > model, but the intent is (?) that the value is reserved so that
> > > > > it is not used by anyone else.  And for this purpose, marking it
> > > > > as reserved in the registry seems perfectly fine.
> > > > >
> > > > model'? The 'real value' is for the transmission entry, but not
> > > > all transmission entries map onto corresponding ifType values.
> > >
> > > This is a real value in the typedef.  The transmission value *is*
> > > thus mapped onto a corresponding if-type value.
> > >
> > >
> > > /martin
> >
> > RFC 6020. Rge 'description' clause explains who made the reservation.
> > Where is the confusion?
> 
> people interpreted this to mean "reserved for now, might be used in the
> future".
> 

[[DR]] (this also) wfm

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Apr 2013 16:46:31 +0200

> (the first part of the description is the same as in the "ifType

Speaking as technical contributor, I fail to see the value of doing
this. not-used-273 is not an assigned ifType and so why bother to have
it in SMIv2/YANG modules? How does this help to manage a network?

I understand that it is important for the registry maintainer to know
that there are values that are reserved for specific future usages or
reserved to never be used, but it is not clear to me why information
about this should to appear in an SMIv2 or YANG module as if these
numbers were actually registered as an ifType. And I am concerned that
some of the not-used-XYZ entries then later may find a usage and we
run into trouble with that.

/js

PS: Note that hyphens are not allowed in SMIv2 labels...

---

From: Andy Bierman <[email-masked]>
Date: Tue, 9 Apr 2013 07:55:08 -0700

> it in SMIv2/YANG modules? How does this help to manage a network?

I agree.
The typedef should only have valid interface types in it.
What's the point of having the list if a developer
has to hard-code specific non-values out of the list?

> PS: Note that hyphens are not allowed in SMIv2 labels...

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 9 Apr 2013 16:58:00 +0200

> run into trouble with that.

I agree with Juergen. In fact, if a value is NOT among the enums, it cannot be used, and this is how I understand the normal meaning of "reserved". The case of RFC 6825 looks somewhat abnormal and I'd suggest to use a more descriptive label.

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Apr 2013 09:34:55 +0200 (CEST)

Hi,

I am not sure if anything has been decided for this issue, but if we
go with the solution that values that are "reserved" in the registry
are NOT reflected in the YANG module, I suggest we add this sentence to
the second paragraph in the IANA Considerations section:

  If an interface type is marked as "reserved" in the "ifType
  definitions" registry, no "enum" statement is added to the
  "iana-if-type" typedef.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Apr 2013 10:44:03 +0200

>  definitions" registry, no "enum" statement is added to the

Yes, but for all three registries and enumerations, i.e. also for address family and SAFI.

Lada

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Apr 2013 16:25:42 +0200

> Yes, but for all three registries and enumerations, i.e. also for address family and SAFI.
That works for me.
As I wrote in a previous email:

    Bottom line: the IANA considerations must explain what to do with
    the "Reserved" values, for both interface type and SAFI. And if
    there are two different of "Reserved" meaning, the IANA
    considerations section must explain the different treatments, if
    different.

Martin,
I propose that you get a new version of the draft with those changes.
 From there, we could check it with the MIB doctors & yang doctors

Regards, Benoit