Adrian Farrel's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

["Adrian Farrel" <[e-mail]>]

Adrian Farrel has entered the following ballot position for
draft-ietf-6man-ext-transmit-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this document. I have no objection to its
publication and just two minor observations.

---

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 am not convinced that an experiment that uses an experimental code 
point needs to be documented in an Experimental RFC. 

Are 253 and 254 intended solely for experimental extension headers? 
Couldn't the experiment be an experimental payload protocol?

---

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.