[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IANA assignments

humm, I think we're debating two points. One we agree on the other I'm not sure about.

Point 1: (re)assignment of values removed from or used in dead drafts.

I'm all for this and agree that these values should be reused.

Point 2: temporary assignment of *real* values for long lived drafts.

I think we disagree here, but am not sure. There needs to be a way to tentatively assign values to ensure interoperable implementations of drafts. Sure when the draft doesn't make it to RFC, point 1 applies and the values are free for reuse.

As there is no IANA process that supports this, the implementation community resorts to agreeing on values. Changing these values at RFC publication time serves no purpose other than disrupting the vendor and service provider communities.

In this case, the draft has been stable for 2+ years. There have been *many* implementations, many interop tests, and even deployments. There are also derivative works (OIF and ITU). All use the same value here. It serves no one in the community to change the value at this time. All it does is destabilize an otherwise stable technology.

In short, IANA should formally assign the values that have been used for the past few years.

I would love for IANA/IESG to come up with a formal procedure to deal with this real interoperability issue.

Lou

At 06:43 AM 1/8/2004, Wijnen, Bert (Bert) wrote:

> Bert,
>          Got to say I agree with David on this.  There is a
> long standing issue with IANA assignments for long lived drafts.
> We hit this with MPLS, GMPLS and now this document.
>
> The way this was resolved in the past was to make a formal request to IANA
> that included specific values and then for implementations to use these
> values until the formal assignment was made.

NOPE,. NOPE and NOPE. I (and IANA, and our IANA rules/guidelines) are
OK with a WG asking for a specific value (in a ID), but that does NOT
mean that early implementors can or should use that value.
Because it CAN and WILL be taken away for otehr assignments when the
ID does not make it to RFC.

> I think that the request for assignment of a specific value (3) got
> dropped in this case.
> If that had been made, all would be good.
>
NOPE, cause it would not have been assigned based on the fact that
it is in some ID.

> IMO this is an IANA process issue, but we've been here before
> (at least some of us), and never really resolved anything.
> (A simple solution would be to reserve values for long lived drafts
> and formally assign on RFC publication or return the values if/when
> the draft dies.)
>
NOPE. The simple solution is that you request a value in experimental
space while the ID is progressing and being discussed. Only at final
ID approval and RFC-publication will a value in the STDS track space
be assigned.

Bert
> Lou
>
> > -----Original Message-----
> > > From: David Charlap
> > [<<mailto:David.Charlap@marconi.com>mailto:David.Charlap@marconi.com>mailto:David.Charlap@marconi.com]

> > > Sent: dinsdag 6 januari 2004 18:34
> > > To: IETF CCAMP List
> > > Subject: IANA assignments
> > >
> > >
> > > Today, I was going through the IANA assignements for RSVP
> > >
> >
> (<<http://www.iana.org/assignments/rsvp-parameters>http://www.iana.org/assignments/rsvp-parameters>http://www.i 

ana.org/assignments/rsvp-parameters)
> and noticed
> > what may be a problem.
> >
> > The SONET/SDH FLOWSPEC C-Type
> > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt)
> > is assigned the value 3.
> >