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

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

hi,

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 06 July 2006 12:09
> To: Hancock, Robert
> Cc: Ash, Gerald R (Jerry), ALABS; "Attila Báder (IJ/ETH)"; 
> NSIS; Kappler Cornelia
> Subject: Re: [NSIS] QSPEC Comment: IANA Consideration Section
> 
> 
> Hi Robert,
> 
> > 
> > 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.
> > 
> 
> 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.

i'm not sure what you are recommending here. that the 'r' bits are
hard coded as 0? or something else?

sometimes new functionality doesn't require a whole new namespace.

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

i agree that more explanation never hurts, up to a point. 

however, i went through the GIST IANA considerations with IANA
people in Vancouver and they seemed happy with them. the problem
isn't with the instruction itself ('Reserved' just means 'don't 
give these out' which is pretty easy to follow), but with the
motivation for the instruction.

r.

> Ciao
> Hannes
> > r.

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

---

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

Hi Robert,

> hard coded as 0? or something else?

The 'r' bit in the object header unless it has the meaning of (2).

> motivation for the instruction.
Why not to just add one line saying this? It would someone like me help 
to understand the document.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 06 Jul 2006 16:18:33 +0200

Hi Jerry,

I will take the time to talk to the IANA folks by myself about this issue.
I am interested to hear what they think about the concept and whether 
they have experience with it.

Ciao
Hannes

Ash, Gerald R (Jerry), ALABS wrote:
> Hi Hannes,
> 
> See below.
> 
> Jerry> Here the specified range
> Jerry> designated as 'reserved' is a normal use of allocated space in a
> Jerry> registry that is reserved for future definition by a 
> Jerry> specification.
> Jerry> Future specifications can redefine the registry allocations, and
> Jerry> allocate more space to various designations, as necessary 
> Jerry> (e.g., more
> Jerry> space allocated to "Standards Action" or to "Private/Experimental
> Jerry> Use", etc.).
> 
> Hannes> I am not so sure that this is common and useful practice.
> Hannes> The IANA consideration section already indicates that a 
> Hannes> fraction of the 
> Hannes> namespace requires standards track actions.
> 
> Robert> this is similar to what is in the GIST spec, and to me it 
> Robert> just seems
> Robert> like common sense. basically, you could parcel up the 
> Robert> whole registry
> Robert> (4096 values) for different allocation policies, but what 
> Robert> happens if
> Robert> you get the division wrong and run out of (for example) 
> Robert> expert review
> Robert> space in 3 years? you would have to start stealing codes from other
> Robert> parts of the registry. leaving a Reserved chunk allows a 
> Robert> second chance
> Robert> at getting the division right in the light of some 
> Robert> deployment experience.
> Robert> (see also 
> Robert> http://www1.ietf.org/mail-archive/web/nsis/current/msg06337.html
> Robert> for this discussion of this topic in the GIST context).
> 
> Hannes> If this is the intention of this approach then maybe it would 
> Hannes> be worth 
> Hannes> adding a few lines somewhere. The link to the previous 
> Hannes> discussions seems 
> Hannes> to support my comment that the intention of the reserved space is 
> Hannes> misleading. I wonder whether IANA knows what todo when it 
> Hannes> sees the stuff.
> 
> Robert> i agree that more explanation never hurts, up to a point. 
> Robert> however, i went through the GIST IANA considerations with IANA
> Robert> people in Vancouver and they seemed happy with them. the problem
> Robert> isn't with the instruction itself ('Reserved' just means 'don't 
> Robert> give these out' which is pretty easy to follow), but with the
> Robert> motivation for the instruction.
> 
> Hannes> Why not to just add one line saying this? It would someone 
> Hannes> like me help 
> Hannes> to understand the document.
> 
> We can add a line of explanation.  However, Robert has confirmed that this practice is already understood by IANA, and I believe is common practice for the reasons given by Robert.  You have commented also to remove several "explanatory" notes and/or "examples" from the IANA section because they were not needed by IANA.
> 
> Thanks,
> Jerry
>  
> 
>>Ciao
>>Hannes
> 
> 
>

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 6 Jul 2006 09:13:52 -0500

Hi Hannes,

See below.

Thanks,
Jerry

---

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

Hannes,

>The 'r' bit in the object header unless it has the meaning of (2).

So, are you saying that the reserved bits should have a value, and
the value should be fixed? 

>> however, i went through the GIST IANA considerations with IANA people 
>> in Vancouver and they seemed happy with them. the problem isn't with 
>> the instruction itself ('Reserved' just means 'don't give these out' 
>> which is pretty easy to follow), but with the motivation for the 
>> instruction.
> 
> Why not to just add one line saying this? It would someone 
> like me help to understand the document.

that would work for me.
John