Subject: RE: [NSIS] GIST extensibility concern (IANA considerations)

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 14 Feb 2006 15:40:48 -0000

Hi Henning,

This is a good question. I imagine we can continue to fine-tune
the assignment ranges (and indeed policies) independently of the
technical development of the specificiation, but if we actually
need different message formats or to define escape mechanisms that
should be done now.

At least part of this discussion overlaps with the scope of the
overall NSIS extensibility draft (draft-loughney-nsis-ext), 
because experiments are likely to be about NSIS (e.g. an
experimental signalling application) rather than pure GIST
experiments. It would be good to know how that draft was going
to progress.

My thinking on private/experimental ranges was mainly driven by
rfc3692 (Thomas Narten's document). That seems to recommend specifically
against large ranges, apparently mainly to avoid people abusing 
experimental allocations for long term use. I'm not sure how any
sort of large scale experiment on the open Internet could be 
accommodated when those types of concerns are taken into account.
(I've also sensed vibes from some quarters that making too much
allowance for extensibility is a Bad Thing, but I don't know how
to turn that into concrete requirements for protocol specification.)
In other words, the current IANA text is deliberately conservative 
on what sort of extensibility is allowed, and maybe we need to 
address that fundamental point first.

A practical point is that (I suspect) most experiments will be
in the context of a new signalling application, rather than GIST
extensions per se. And the GIST design largely insulates NSLPs
from each other, so we could use a larger range of private/
experimental NSLPIDs as part of a solution. (The current IANA
considerations allow 16 out of 64k, and I was queried even on 
why that number was so large ...). There is some discussion on what 
RAO value to use for such applications in the thread starting here:
http://www1.ietf.org/mail-archive/web/nsis/current/msg05111.html

The "message type object" could also be a possible approach. If
we want it, I think it has to be included in the base specification;
I don't see how to add it as an extension. (I think you basically
want an object which says "If you don't understand me, ignore or
forward the whole message containing me unchanged" which we can't
describe currently, although there are flag bits available to
denote this.) However, I'm not clear whether we really need this
(or indeed whether it would be seen as an example of "excessive
extensibility" as noted above).

r.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Henning Schulzrinne
> Sent: 14 February 2006 02:38
> To: [email-masked]
> Subject: [NSIS] GIST extensibility concern (IANA considerations)
> 
> 
> On re-reading the extensibility section in the IANA 
> considerations, I  
> have a concern that the mechanism as specified will lead to  
> interoperability problems. In several cases, e.g., for object types  
> and message types, there is a range for "private/experimental use".  
> However, in all these cases, the range is small. For example, for  
> GIST Message Type, only 8 values are available. Thus, if there are  
> two experiments going on in the Internet, it is extremely 
> likely that  
> the two experiments will clash accidentally. In other words, such  
> experiments are rather unsafe unless you operate a very tightly  
> controlled, closed network. It certainly wouldn't be suitable for,  
> say, Internet2-scale experiments or a vendor-specific experiment.
> 
> In other protocols, private extensions are usually designed so that  
> it is *un*likely that two entities would pick the same 
> identifier. As  
> an example, header names (e.g., X- headers in email) are designed so  
> that two parties can build new extensions, with only a modest  
> likelihood of accidental collisions. DHCP also has vendor-specific  
> codes that have a similar design.
> 
> I don't think we want to extend the GIST Message Type, for example,  
> beyond 8 bits, as this is likely wasteful. The only 
> alternative is to  
> have an escape mechanism that adds a message type object with 
> a long,  
> random identifier (e.g., a GUID) for such private message types or  
> uses the DHCP-style mechanism.
> 
> Henning
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Feb 2006 11:00:18 -0500

I'm not in favor of excessive, non-standardized extensibility. I 
believe, however, that we need to either have a mechanism that allows 
non-interfering experiments or to have a strong statement that these are 
a BAD THING. I'm afraid that we have a dangerous middle ground here: 
There is a mechanism that kind of allows experiments, but is likely to 
fail badly and unpredictably if actually used.

This is not about rejecting unknown code points, but rather of two 
experiments colliding, with vendor A and vendor B assigning 
contradictory meanings to the same message type, for example. If 
suddenly, equipment from vendor B is introduced, things break badly, but 
probably only for some paths. This is the worst kind of failure since it 
is almost impossible to debug.

If all you want to support are truly private-network experiments, no 
extension mechanism is needed. People will just use any unassigned code 
point (unassigned for their current use) since they know all the devices 
that are going to see the packets.

I think GIST and NSIS are somewhat different from other protocols since 
they are much more likely to cross administrative and vendor boundaries 
than simple client-server protocols.

In summary, I think we probably need to look at each of the IANA 
assignments and make a "discourage random experiments" vs. "facilitate 
experimentation" decision.

Henning

---

From: [email-masked]
Date: Wed, 15 Feb 2006 09:42:03 +0200

Hi Henning,

Its unclear what kind of extensibility you'd like and the usage 
model of the extensiblity.  If you had a more concrete proposal,
it might be easier to follow.

I'm basically following the extensibility model proposed in 
rfc3692.  Also, I think that GIST will be a more 'standard'
transport protocol, where open extesibility is discouraged
(as in TCP, SCTP, DCCP, etc).

John
>Behalf Of ext Henning Schulzrinne
>Sent: 14 February, 2006 18:00
>To: Hancock, Robert
>Cc: [email-masked]
>Subject: Re: [NSIS] GIST extensibility concern (IANA considerations)
>
>I'm not in favor of excessive, non-standardized extensibility. 
>I believe, however, that we need to either have a mechanism 
>that allows non-interfering experiments or to have a strong 
>statement that these are a BAD THING. I'm afraid that we have 
>a dangerous middle ground here: 
>There is a mechanism that kind of allows experiments, but is 
>likely to fail badly and unpredictably if actually used.
>
>This is not about rejecting unknown code points, but rather of 
>two experiments colliding, with vendor A and vendor B 
>assigning contradictory meanings to the same message type, for 
>example. If suddenly, equipment from vendor B is introduced, 
>things break badly, but probably only for some paths. This is 
>the worst kind of failure since it is almost impossible to debug.
>
>If all you want to support are truly private-network 
>experiments, no extension mechanism is needed. People will 
>just use any unassigned code point (unassigned for their 
>current use) since they know all the devices that are going to 
>see the packets.
>
>I think GIST and NSIS are somewhat different from other 
>protocols since they are much more likely to cross 
>administrative and vendor boundaries than simple client-server 
>protocols.
>
>In summary, I think we probably need to look at each of the 
>IANA assignments and make a "discourage random experiments" 
>vs. "facilitate experimentation" decision.
>
>Henning
>
>
>Hancock, Robert wrote:
>> Hi Henning,
>> 
>> This is a good question. I imagine we can continue to fine-tune the 
>> assignment ranges (and indeed policies) independently of the 
>technical 
>> development of the specificiation, but if we actually need different 
>> message formats or to define escape mechanisms that should be done 
>> now.
>> 
>> overall NSIS extensibility draft (draft-loughney-nsis-ext), because 
>> experiments are likely to be about NSIS (e.g. an experimental 
>> signalling application) rather than pure GIST experiments. 
>It would be 
>> good to know how that draft was going to progress.
>> 
>> rfc3692 (Thomas Narten's document). That seems to recommend 
>> specifically against large ranges, apparently mainly to avoid people 
>> abusing experimental allocations for long term use. I'm not sure how 
>> any sort of large scale experiment on the open Internet could be 
>> allowance for extensibility is a Bad Thing, but I don't know how to 
>> turn that into concrete requirements for protocol specification.) In 
>> other words, the current IANA text is deliberately conservative on 
>> what sort of extensibility is allowed, and maybe we need to address 
>> that fundamental point first.
>> 
>> A practical point is that (I suspect) most experiments will 
>be in the 
>> context of a new signalling application, rather than GIST extensions 
>> per se. And the GIST design largely insulates NSLPs from each other, 
>> so we could use a larger range of private/ experimental NSLPIDs as 
>> part of a solution. (The current IANA considerations allow 16 out of 
>> 64k, and I was queried even on why that number was so large ...). 
>> There is some discussion on what RAO value to use for such 
>> applications in the thread starting here:
>> The "message type object" could also be a possible approach. If we 
>> want it, I think it has to be included in the base specification; I 
>> don't see how to add it as an extension. (I think you basically want 
>> an object which says "If you don't understand me, ignore or forward 
>> the whole message containing me unchanged" which we can't describe 
>> currently, although there are flag bits available to denote this.) 
>> However, I'm not clear whether we really need this (or 
>indeed whether 
>> it would be seen as an example of "excessive extensibility" as noted 
>> above).
>> 
>> r.
>> 
>> 
>>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>>> Of Henning Schulzrinne
>>> have an escape mechanism that adds a message type object 
>with a long,

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Feb 2006 09:32:09 -0500

John,

Let me try to make some suggestions:

NSLP Identifier:
   Seems likely to need experiments and there's a pretty-well defined  
mechanism for ignoring unknown NSLPs. I would suggest an escape code  
and a new TLV field. One possibility that avoids registration is to  
use a UUID, which is 128 bits. See RFC 4122 for the text version. An  
alternative is to use the enterprise codes and an enterprise-specific  
number (say, 16 bits). See http://www.iana.org/assignments/enterprise- 
numbers  This would be a total of 48 bits, assuming 32 bits are long  
enough for an enterprise number.

GIST Message Type:
   Seems less likely to need experiments and experiments seem more  
dangerous, as it is unclear how well nodes that don't understand  
message types can deal with them. I would suggest dropping private/ 
experimental use, given that there is an expert review space that  
should make getting an identifier reasonably easy.

Object Types:
   Similar to NSLP identifier. Define an extension object that always  
starts with a UUID or the enterprise code/type.

Message Routing Methods:
   Again, experiments seem likely to be disruptive. What do I do with  
an unknown MRI? Thus, I'd suggest dropping the experimental range.

MA-Protocol-ID
   same

I think a basic issue is as to how well a system can deal with  
unknown values. In some cases, it can, at best, generate an error and  
terminate the flow of GIST messages. In others, such as the NSLP  
identifier, it can ignore the value.

Is this a bit less vague?

Henning