[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    Re: [mpls] draft-ietf-mpls-ldp-iana
From:       "Carlos Pignataro (cpignata)" <cpignata () cisco ! com>
Date:       2011-10-27 16:15:12
Message-ID: 960EC8F9A775AB40BF58D8953342D863069AA0C1 () XMB-RCD-206 ! cisco ! com
[Download RAW message or body]

Similar states happen for other protocols as well. For example with the
IPv6 ND Router Advertisement flags, where RFC2461 left a 6-bit Reserved
opaque field next to two bit-flags (see
<http://tools.ietf.org/html/rfc4861#section-4.2>), and then other RFCs
(RFC3775, RFC4191, RFC4389) define more bits from that Reserved.
Finally, RFC5175 rationalizes all this in an IANA Registry, and further
extends the bit-flag.

But, to Eric's point, note that here an Experimental RFC 4389 defines a
"Reserved" bit from a Std-track one. So it might not be automatically
evident that the only redefinition path is as per "standards action".

Seems like the proposed path forward good.

Thanks,

-- Carlos.
PS: Tom: you may have also missed
<http://www.ietf.org/proceedings/80/slides/mpls-16.pdf> to oppose?
Hindsight is 20/20.


-----Original Message-----
From: t.petch [mailto:ietfc@btconnect.com] 
Sent: Thursday, October 27, 2011 10:30 AM
To: Eric Rosen (erosen); Carlos Pignataro (cpignata)
Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org; mpls@ietf.org
Subject: Re: [mpls] draft-ietf-mpls-ldp-iana

----- Original Message ----- 
From: "Eric Rosen" <erosen@cisco.com>
To: "Carlos Pignataro" <cpignata@cisco.com>
Cc: <draft-ietf-mpls-ldp-iana@tools.ietf.org>; <mpls@ietf.org>
Sent: Thursday, October 27, 2011 3:31 PM
> 
> > The fields marked "reserved" are atomic fields without syntax or
> > semantics. draft-ietf-mpls-ldp-iana does not attempt to define the
field
> > or start using it. But without it, there are no rules as to what is
> > needed for something to start using them.
> 
> Since there are currently no IANA registries for the fields in
question, it
> is currently impossible for IANA to make any assignments to those
fields.
> As those fields are part of an IETF standard protocol, a redefinition
of
> those fields could only be accomplished by a "standards action".  So
what is
> wrong with the status quo?
> 
> The only issue I see is that if one wants to use one of the currently
unused
> bits, there is no central place to go to see if any other
standards-track
> RFC is already using it.  I think this is a real issue, but I'm not
sure it
> can be addressed by creating an IANA registry.  IANA will ask not only
for
> the allocation policy, but for the range of values that are
assignable.  If
> we don't know whether we may want to use a field as a bit field or as
13-bit
> integer, I don't know how we would provide that information to them.
> 
> Maybe all that is needed is to have the GTSM draft indicate that it
updates
> RFC 5036, and mention in the abstract and introduction that it uses a
bit
> that is reserved in RFC 5036.
> 
> It's also hard to see the point of creating registries for "ATM Label
TLV",
> "Frame Relay Label TLV".  The first standards track RFC that needs
these
> registries can request them.

I agree; this I-D, which I regret not having read earlier else I would
have 
opposed its adoption seems to be setting in concrete matters that the 
editors of RFC5036, in their wisdom, left open until and when there 
was a need to be more specific, and, with the exception
of one small item for GTSM, that wisdom appears, to me, still to be
wise.

Tom Petch

> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]