On 08/10/2013 03:43, Adrian Farrel wrote: ... > Section 1.1 > > A couple of points about the following paragraph: > > In this document "standard" IPv6 extension headers are those > specified in detail by IETF standards actions. "Experimental" > extension headers are those defined by any Experimental RFC, and the > experimental extension header values 253 and 254 defined by [RFC3692] > and [RFC4727]. "Defined" extension headers are the "standard" > extension headers plus the "experimental" ones. > > My reading of the IANA registry (http://www.iana.org/assignments/ > protocol-numbers/protocol-numbers.xhtml) is that allocations can be made > by IESG Approval or Standards Action. I think both of those are covered > by what you call "standard".
I don't see that "IESG Approval" implies "standard", but I guess that's a matter of interpretation. > I am not convinced that an experiment that uses an experimental code > point needs to be documented in an Experimental RFC. Yes, the definition could perhaps be slightly wider. s/are those/include those/ for example. > > Are 253 and 254 intended solely for experimental extension headers? > Couldn't the experiment be an experimental payload protocol? I'll comment on Mike Heard's message. > > --- > > I find myself in I-wouldn't-have-done-it-this-way land, so this is, of > course, just a Comment for you to chew on and accept or reject according > to how it strikes you... > > It seems to me unwise to create a new registry that duplicates > information held in another registry. By adding a column to the > "Assigned Internet Protocol Numbers" registry you are making it > completely clear which are the IPv6 Extension Headers. Rather than risk > having this registry out of step with your new "IPv6 Extension Header > Types registry", I would have had the existing, empty "IPv6 Next Header > Types" registry redirect users to the "Assigned Internet Protocol > Numbers" registry and mention the existence of the specific column that > identifies extension headers. Logically, yes, but I (personally) think that the convenience factor of a separate list is valuable. We have running code proof in current firewall implementations that people are *not* identifying the extension headers today, and we want to make it easy for them. Brian > > > . > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
