AD evaluation: draft-ietf-6man-rfc1981bis-03

Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 26 January 2017 03:59 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C25B12946B; Wed, 25 Jan 2017 19:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngl-TVpdAzYj; Wed, 25 Jan 2017 19:59:31 -0800 (PST)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162C4129468; Wed, 25 Jan 2017 19:59:31 -0800 (PST)
X-AuditID: c6180641-e73ff70000000a0b-10-58891fb4e7f6
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 2C.E8.02571.4BF19885; Wed, 25 Jan 2017 22:59:18 +0100 (CET)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 22:59:28 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: "draft-ietf-6man-rfc1981bis.all@ietf.org" <draft-ietf-6man-rfc1981bis.all@ietf.org>
Subject: AD evaluation: draft-ietf-6man-rfc1981bis-03
Thread-Topic: AD evaluation: draft-ietf-6man-rfc1981bis-03
Thread-Index: AQHSd4iWxq+eHy7wFEedQHnPCBKYwA==
Date: Thu, 26 Jan 2017 03:59:27 +0000
Message-ID: <6BBA4B27-FE19-405C-A165-9973A8E9AE68@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: text/plain; charset="utf-8"
Content-ID: <76F1E59602D3354C95BFE3A9460D5C3E@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXRPoO42+c4IgzfNehbH1r5msXh59j2T A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyfm3/wlrQwFsxd/98lgbGKzxdjJwcEgImEv92rmbu YuTiEBJYzyix+l8/E4SznFGi9ft0ZpAqNqCqDTs/M4HYIgKREk/W7WIDsZkFpCVuLXkOFOfg EBYwlVi/ihOixEqiZ8UVdghbT2LN0wlgrSwCqhLfTnaBlfMK2Evs+SgNEmYUEJP4fmoNE8RE cYlbT+YzQdwmILFkz3lmCFtU4uXjf6wQtpLEnNfXmEHGMAtoSqzfpQ/Rai3xc95HFghbUWJK 90OwC3gFBCVOznzCMoFRZBaSDbMQumch6Z6FpHsWku4FjKyrGDlKiwtyctONDDcxAoP/mASb 4w7Gvb2ehxgFOBiVeHgNWjsihFgTy4orcw8xSnAwK4nwpl8GCvGmJFZWpRblxxeV5qQWH2KU 5mBREue9HnI/XEggPbEkNTs1tSC1CCbLxMEp1cDoqC5bFp5yyL1vt/33/U0Jnlb3ZvDX/5xx RuFi5YWbLzjMZu87LHvLS/Vuny5/romwsh9LkM+J3zr5O84xck3Jlcu/pOa9XG/Hk5N7qh7w JiUxrjlUIXjiS3ToffOwLwwGxr/2NqifyLYsmrdxil1qru9ChZcrt3jwHp6VJ5cSsWSKVNDT +5xKLMUZiYZazEXFiQAcqPERegIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gPiWpL2kd4738b38y_QzrbuIckw>
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2017 03:59:32 -0000

Hi all,
  I have gone through draft-ietf-6man-rfc1981bis-03 and I found it to be in good shape to progress. I just saw two minor issues that need to be addressed

* Section 1

I don’t think that his text that is copied over from RFC4821 is helpful. I think the earlier part of the paragraph is well written, useful and conveys exactly the right amount of context.

“          In this algorithm, the	
 	   proper MTU is determined by starting with small packets and probing	
 	   with successively larger packets.  The bulk of the algorithm is	
 	   implemented above IP, in the transport layer (e.g., TCP) or other	
 	   "Packetization Protocol" that is responsible for determining packet	
 	   boundaries."

* Section 3

I am not sure why the following text is required. What are these nodes? I thought we discussed this and decided to not put in such text.

"(regardless of whether it decrements the Hop Limit)"

I would suggest removing the text or adding an example of such a node.

Thanks
Suresh

P.S.: I agree with Donald’s comment in his INT Dir review that the “security classifications” paragraph seems dated but I would prefer for it to be removed rather than rewritten.