RE: Routing directorate review of draft-ietf-6man-rfc2460bis

"Papadimitriou, Dimitri (Nokia - BE)" <> Thu, 02 March 2017 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71E3A129656; Thu, 2 Mar 2017 13:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZF4ye8aeQIz9; Thu, 2 Mar 2017 13:02:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 449AB1294FD; Thu, 2 Mar 2017 13:02:46 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 2133E42174DB8; Thu, 2 Mar 2017 21:02:40 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id v22L2hE0016648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Mar 2017 22:02:43 +0100
Received: from ( []) by (GMO) with ESMTP id v22L2em8001935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Mar 2017 21:02:41 GMT
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Thu, 2 Mar 2017 22:02:40 +0100
From: "Papadimitriou, Dimitri (Nokia - BE)" <>
To: "" <>, "" <>
Subject: RE: Routing directorate review of draft-ietf-6man-rfc2460bis
Thread-Topic: Routing directorate review of draft-ietf-6man-rfc2460bis
Thread-Index: AdKFwZDg9wFxEPPGS96EtpTiRnPBlQAqvXfAAxKG9ZA=
Date: Thu, 2 Mar 2017 21:02:40 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Mar 2017 21:02:51 -0000


I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-6man-rfc2460bis-08.txt
Reviewer: Dimitri Papadimitriou 
Review Date: 01-03-2017
Intended Status: Standards Track


I have some minor comments about this document that I think might have to be resolved before publication.

Major Issues: 

No major issues found.

Minor Issues:

Section 4.4: processing of the "segment left" field is left undocumented (shouldn't it be decremented after being processed ?)

Section 4.5: "If insufficient fragments are received to complete reassembly" does "insufficient" means the last fragment ?

Section 4.8: states "New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header" does this configuration change because options are new or old ? there seems to be confusion here between "new vs. existing" options and "intermediate nodes MAY be configured to ignore/drop packets with these options included". 

Section 8.3: one would have expected a self-consistent formula to determine the max.payload size instead of a relative comparison to IPv4

Section 8.4: automatically reversed or not, this section doesn't state if the response (understood here that the option type is recognized) is to be sent to the source address (directly) or the last entry from the record route for instance (cf. Section 4.4).


p2. s/Internet Protocol/Internet Protocol (IP)

Section 2 defines link for link MTU but doesn't define path for path MTU

p14. s/a source node know/a source node knows