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

From: "Robert Hancock" <[email-masked]>
Date: Sun, 19 Mar 2006 09:20:11 -0600

I've stored this in the issue tracker
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue106
so it gets into the next update.

r.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: 16 February 2006 08:35
> To: Hancock, Robert
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] GIST extensibility concern (IANA considerations)
> 
> 
> 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.
> 
> On Feb 16, 2006, at 4:09 AM, Hancock, Robert wrote:
> 
> > 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.
> >
> 

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

---

From: <[email-masked]>
Date: Sun, 19 Mar 2006 18:19:42 +0200

Robert,

I think that the GIST document should have a general statement in the
IANA considerations section, but I could also add a short discussion
about
this in the extensions draft as well.

Thoughts?
John 

>From: ext Robert Hancock [mailto:[email-masked]] 
>Sent: 19 March, 2006 17:20
>To: 'Henning Schulzrinne'
>Cc: Loughney John (Nokia-NRC/Helsinki); [email-masked]
>Subject: RE: [NSIS] GIST extensibility concern (IANA considerations)
>
>> > 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:
>> > 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.
>> >
>> > 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.
>> >
>> 
>
>