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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 16 Feb 2006 09:09:35 -0000

hi,

a quick comment on the message type/protocol id/mrm aspects.

i think there are actually two aspects here:
- whether GIST can cope (in some sense) with new protocol 
  numbers
- whether experimental numbers are useful

we have to be able to do the first, whether the new protocol
number comes because of an experiment or some other official
assignment. In the three cases mentioned, I think the spec is
ok:
- unknown message types are rejected with an error (don't
  change subsequent processing)
- unknown protocol IDs are ignored (when deciding what type
  of MA to build)
the case of an unknown MRM is slightly more subtle; it was 
discussed in the thread starting here
http://www1.ietf.org/mail-archive/web/nsis/current/msg05367.html
the upshot is that you should only get experimental MRMs with
experimental NSLPs; and if you don't support the experimental
NSLP you ignore the MRM. 

so I think that experimental values for these are safe in the
sense that unknown values are handled correctly.

of course, they are not safe if people adopt conflicting definitions
of the unknown values. so the only environment in which valid
experiments can be done is some sort of closed/private one (i.e.
one in which the experimenter knows all the experiments that are
in progress). i think this is (implicitly) the type of experiment
that rfc3692 is talking about. I still think it's useful to have
an assignment range for that type of experiment, because it
guarantees that some kind of software upgrade that brings in non-
experimental new protocol numbers (e.g. because of some other
standards work or expert review) will not suddenly cause a 
collision. it's a not very sophisticated mechanism for a not
very ambitious goal.

it may be that the IANA section (whatever else we do with it)
should be more explicit about what 'private/experimental' means,
including possibly a reference to 3692. i'd like not to ban 
experiments, especially in the protocol ID and MRM cases, because
actually I can think of some very interesting experiments to do
there.

cheers,

r.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: 15 February 2006 14:32
> To: [email-masked]
> Cc: Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] GIST extensibility concern (IANA considerations)
> 
> 
> 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
> 
> 
> On Feb 15, 2006, at 2:42 AM, <[email-masked]> wrote:
> 
> > 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
> >>>
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Feb 2006 09:34:32 -0500

I'd be fine with a "black box" warning, to use the medical drug  
terminology. I think compared to other experiments, this has to be  
much more tightly controlled. This isn't likely to be an issue until  
NSIS is widely deployed in routers, for example. Once NSIS has wider  
deployment, this experimental mode is essentially only suitable for a  
closed network where the experimenter is on a first-name basis with  
all network elements. In other words, "lab" experiments, rather than  
"Internet" experiments.

I'm used to the SMTP X- and SIP P- headers, which have far lighter  
impact on the non-implementing world, as they are generally only  
informational, rather than directing processing.