Subject: RE: [NSIS] QSPEC Comment: IANA Consideration Section

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 6 Jul 2006 11:10:49 +0100

hi,

some comments on the 'reserved' bits (no pun intended):

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 03 July 2006 08:57
> To: Ash, Gerald R (Jerry), ALABS
> Cc: "Attila Báder (IJ/ETH)"; NSIS; Kappler Cornelia
> Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section
> 
> 
> Hi Jerry,
> 
> thanks for your quick feedback.
> Please find my comment below:
> 
> Ash, Gerald R (Jerry), ALABS wrote:
> > Hi Hannes,
> > 
> > See below.
> > 
> > 
> >> -----Original Message----- From: Hannes Tschofenig
> >> [mailto:[email-masked]] Sent: Sunday, July 02, 2006 6:01
> >> AM To: NSIS Subject: [NSIS] QSPEC Comment: IANA Consideration
> >> Section
> >> 
> >> Hi QSPEC authors,
> >> 
> >> let me comment on the IANA consideration section.

[snip]

> >> [hannes] What does 'reserved' mean? The Object Type has 12 bits and
> >>  according to Section 7 all of them are used.
> > 
> > 
> > I'm not sure of your question, Section 9 says:
> > 
> > Object Types (12 bits): The following values are allocated by this
> > specification: 0-4: assigned as specified in Section 7. The
> > allocation policies for further values are as follows: 5-63:
> > Standards Action 64-127: Private/Experimental Use 128-4095: Reserved
> > 
> > This is how the 12 bits are used in the registry.  Perhaps your
> > question pertains to the "Reserved" above?
> 
> The packet format looks as follows:
> 
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |R|E|r|r|       Object Type     |r|r|r|r|         Length        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The Object Type has 12 bytes but in the IANA consideration 
> section you 
> define more bytes as reserved. This means: A few bytes are 
> reserved in 
> the Object Type and then followed by a few bytes that are reserved.
> 
> The meaning of the two reserved is different: The 'r's from the above 
> figure indicate padding and the other reserved mean for 
> undefined future 
> use. Then, there are the 'r's at the beginning of the object 
> that mean 
> 'will be specified if you add something to the registry'.
> 
> Sounds confusing to me.

i think it is true that there are two sorts of 'reserved' here:
1) there are the bits marked 'r' in the object header
2) there are the values for Object Type listed as 'Reserved' in the
   IANA section.

the first type could conceptually be used in a future spec revision
to define additional flags which apply to the processing of existing
and new objects. conceptually i suppose you could discuss these flag
bits in the IANA section (as Diameter does, section 11.2.2 of 3588),
but since in each case new flag bits can only be defined by a standards
action I don't really see the point. In other words, the existence
of these flag bits should not be relevant to the IANA section.

> 
> 
> 
>    Here the specified range
> > designated as 'reserved' is a normal use of allocated space in a
> > registry that is reserved for future definition by a specification.
> > Future specifications can redefine the registry allocations, and
> > allocate more space to various designations, as necessary 
> (e.g., more
> > space allocated to "Standards Action" or to "Private/Experimental
> > Use", etc.).
> 
> I am not so sure that this is common and useful practice.
> The IANA consideration section already indicates that a 
> fraction of the 
> namespace requires standards track actions.

this is similar to what is in the GIST spec, and to me it just seems
like common sense. basically, you could parcel up the whole registry
(4096 values) for different allocation policies, but what happens if
you get the division wrong and run out of (for example) expert review
space in 3 years? you would have to start stealing codes from other
parts of the registry. leaving a Reserved chunk allows a second chance
at getting the division right in the light of some deployment experience.
(see also http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html
for this discussion of this topic in the GIST context).

r.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 06 Jul 2006 13:08:54 +0200

Hi Robert,

> of these flag bits should not be relevant to the IANA section.

I think that there are better ways to provide the ability to extend 
functionality in the future. The current approach is confusing.

The easiest way is to register a namespace with IANA and provide 
guidelines for allocation of new values.

> for this discussion of this topic in the GIST context).
If this is the intention of this approach then maybe it would be worth 
adding a few lines somewhere. The link to the previous discussions seems 
  to support my comment that the intention of the reserved space is 
misleading. I wonder whether IANA knows what todo when it sees the stuff.

Ciao
Hannes

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 16:20:04 +0300

Small comment:

>the first type could conceptually be used in a future spec 
>revision to define additional flags which apply to the 
>processing of existing and new objects. conceptually i suppose 
>you could discuss these flag bits in the IANA section (as 
>Diameter does, section 11.2.2 of 3588), but since in each case 
>new flag bits can only be defined by a standards action I 
>don't really see the point. In other words, the existence of 
>these flag bits should not be relevant to the IANA section.

Agree with Robert.

>> The IANA consideration section already indicates that a fraction of 
>> the namespace requires standards track actions.
>
>this is similar to what is in the GIST spec, and to me it just 
>seems like common sense. basically, you could parcel up the 
>whole registry
>(4096 values) for different allocation policies, but what 
>happens if you get the division wrong and run out of (for 
>example) expert review space in 3 years? you would have to 
>start stealing codes from other parts of the registry. leaving 
>a Reserved chunk allows a second chance at getting the 
>division right in the light of some deployment experience.
>(see also 
>http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html

If we get it wrong, we write a -bis draft, updating the IANA registry
info.  No big deal.

John