Subject: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09

From: Martin Stiemerling <[email-masked]>
Date: Tue, 11 Apr 2017 21:14:06 +0200

Hi,

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...

Summary:
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 
consensus".

- 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:

none.

Thank you,

   Martin Stiemerling

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Apr 2017 12:54:15 -0700

Martin,

Thanks for your review.

Comments below.

Thanks,
Bob

> On Apr 11, 2017, at 12:14 PM, Martin Stiemerling <[email-masked]> wrote:
> 
> Hi,
> 
> 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.
> 
> This draft has serious issues out of a transport area perspective, described in the review, and needs to be rethought.
> 
> Major issues:
> 
> 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 consensus”.

I think there is a misunderstanding here.  There can only be one hop-by-hop header.  It has to be the first extension header in the packet.  From Section 4:

   The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv6
   header.

I think the text in Section 4.8 is correct:

   New extension headers that require hop-by-hop behavior must not be
   defined because, as specified in Section 4 of this document, the only
   Extension Header that has hop-by-hop behavior is the Hop-by-Hop
   Options header.

New Hop-by-Hop header options (that go inside of a hop-by-hop header) can be defined, but are not recommended.

> 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”?

Personally, I think the writing is clear.  It does mention standardization:

   There has to be a very clear justification why any new
   hop-by-hop option is needed before it is standardized.

“standardization” implies IETF consensus, etc., etc.

We could change it is "standardized in the IETF” or similar.

> 
> 
> Minor issues:
> 
> none.
> 
> Thank you,
> 
>  Martin Stiemerling
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------