Telechat Review of draft-ietf-6man-rfc2460bis-09

Request Review of draft-ietf-6man-rfc2460bis
Requested rev. no specific revision (document currently at 13)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2017-02-28
Requested 2017-02-09
Authors Steve Deering, Bob Hinden
Draft last updated 2017-04-11
Completed reviews Rtgdir Last Call review of -08 by Papadimitriou Dimitri (diff)
Intdir Early review of -08 by Bob Halley (diff)
Genart Last Call review of -08 by Peter Yee (diff)
Tsvart Telechat review of -09 by Martin Stiemerling (diff)
Secdir Telechat review of -09 by Hilarie Orman (diff)
Opsdir Early review of -09 by Linda Dunbar (diff)
Assignment Reviewer Martin Stiemerling
State Completed
Review review-ietf-6man-rfc2460bis-09-tsvart-telechat-stiemerling-2017-04-11
Reviewed rev. 09 (document currently at 13)
Review result Ready with Issues
Review completed: 2017-04-11



I've reviewed this document as part of the transport area review team 
(TSV-ART) ongoing effort to review key IETF documents. These comments 
were written primarily for the transport area directors, but are copied 
to the document's authors for their information and to allow them to 
address any issues raised. When done at the time of IETF Last Call, the 
authors should consider this review together with any other last-call 
comments they receive. Please always CC tsv-art@… if you reply to or 
forward this review.

Sorry for being so late with the review...

This draft has serious issues out of a transport area perspective, 
described in the review, and needs to be rethought.

Major issues:

- Section 4.8. "Defining New Extension Headers and Options":

It says new hop-by-hop headers must never ever defined. This is 
problematic, as this closing the door forever, even if future instances 
of the IETF do would like to wish to define new hop-by-hop headers. A 
better way would have to say "that new hop-by-hop headers must have IETF 

- Section 4.8. "Defining New Extension Headers and Options":

Also the „not recommended“ to define new extension headers looks 
strange, especially with the phrase "There has to be a very clear 
justification". The term "clear justification" is not an exact 
engineering specification. Why not using "technical protocol 
specification and real word use case required, plus IETF consensus"?

Minor issues:


Thank you,

   Martin Stiemerling