[Int-dir] Review of draft-ietf-roll-routing-dispatch-01

"Bernie Volz (volz)" <volz@cisco.com> Wed, 19 October 2016 02:10 UTC

Return-Path: <volz@cisco.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A313128B44; Tue, 18 Oct 2016 19:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.951
X-Spam-Level:
X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 V23e_8W9Ug4C; Tue, 18 Oct 2016 19:10:30 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1453512946C; Tue, 18 Oct 2016 19:10:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24380; q=dns/txt; s=iport; t=1476843030; x=1478052630; h=from:to:subject:date:message-id:mime-version; bh=2Y14/1i0Yacj5T2iTrnR7bImbHsYAB+VljgZyqSvo0o=; b=aaiucZOYylTejYPHD4kXdfJwsec2Ehe05r5VPs9g1TtHtoW8yM69w4pd FeFd7sQKRdCHSleyYmdQkxDjv413fu5yp9zPy1pOgsWer3tk6wbDii5m8 zpQ5OmSbP2arBq9MxxOrBUaajrKyAQpvsi15ElYVIy01Tlaa/2bdt79jn Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAwCv1AZY/5xdJa1cGgEBAQECAQEBAQgBAQEBgwc1AQEBAQEdV3wHp0KTMCeIBDsRAQIBAQEBAQEBYieEaCcGXgFAQCYBBAEaAYhJDsNlAQEBAQYBAQEBASOKDYEFghOCEIYDBY5Ai0gBgTmHdIZRgXWEaYd5gSeQegE0IFSDBhyBU3IBhWmBL4EAAQEB
X-IronPort-AV: E=Sophos;i="5.31,364,1473120000"; d="scan'208,217";a="335580455"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2016 02:10:28 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9J2ASoA000481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Oct 2016 02:10:28 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 21:10:28 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 21:10:27 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "<int-dir@ietf.org>" <int-dir@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, "draft-ietf-roll-routing-dispatch@ietf.org" <draft-ietf-roll-routing-dispatch@ietf.org>
Thread-Topic: Review of draft-ietf-roll-routing-dispatch-01
Thread-Index: AdIprd8vQhopggFgRcuGoxIkxQnMBA==
Date: Wed, 19 Oct 2016 02:10:27 +0000
Message-ID: <88d6f1065fe64b29969766e39dac935c@XCH-ALN-003.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.247.218]
Content-Type: multipart/alternative; boundary="_000_88d6f1065fe64b29969766e39dac935cXCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/4oV7rWvaY9Y_0gHGB7Euk4HSA-g>
Subject: [Int-dir] Review of draft-ietf-roll-routing-dispatch-01
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2016 02:10:32 -0000

Hi:

I am an assigned INT directorate reviewer for draft-ietf-roll-routing-dispatch-01. These comments were written primarily for the benefit of the Internet
Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

This document seems to have required reading many other documents about 6LoWPAN which sadly I did not have time to do. So, my comment may reflect a narrow understanding of the technology. Most of my comments are fairly minor in nature to clean up the document (which the RFC-Editor would no doubt do a far better job at then my limited comments).

I did NOT find anything that would be show stopper for this document.


1.       Please check the use of LOWPAN_IPHC and LoWPAN_IPHC. Probably they should all be the same case? And there is a mix of underscore and hyphen (LOWPAN-IPHC)? Should one format be used throughout? Also, in section 7 just "IPHC" is used.

2.        Standardize the way in which RFC titles are referenced. Section 1 uses just the title, the title in square brackets and another part of the document uses single quotes around the name.

3.       Look at #RFC6554 - that likely was meant to be a reference to the RFC?

4.       In Figure 2, might be worth moving the "RPL SRH" text up below the "plus" instead of leaving a space between them?

5.       In Section 3.2.1, first paragraph, the opening parenthesis is never closed. And, might be best to add "described in" before the Section 3.1 reference?

6.       In section 3.2.2, there is a closing parenthesis in the first paragraph, but no matching opening parenthesis?

7.       In section 3.2.2, HbH is used but is not defined nor was it defined in the 3 RFCs referenced in the Terminology section. It is used twice in the document. Either define in terminology, add to first use, or just spell out "hop by hop"?

8.       In section 3.2.2, reference to Section 3.2.1 might be "(see Section 3.2.1)"? Similar issue for reference to section 5.3.

9.       In section 3.2.2, last paragraph, there is "it is REQUIRED that the in the"? This seems to be malformed? I think the "the" after that should be dropped?

10.   Section 4, the last paragraph should probably start with "For", not "for"? And, I think a comma should be a period (after "form of 6LoRH") and an extra that should be removed (that that)?

11.   Section 4.3, "that as a long" should probably be "that has a long"?

12.   Section 4.3, I think it should be compressed - "in order to reconstruct the compressed"?

13.   Section 4.3, cleanup reference to "section section 4.3.1".

14.   Section 4.3.2, "described in more details" should probably just be "described in more detail"?

15.   Section 5.1, it might be useful to indicate here that "Hop1" ... are the (possibly) compressed addresses? This field is not really defined.

16.   Section 5.1, "It results that" is a bit odd? Perhaps just say "This means that all"? Similar issue in Section 5.2.3, though I don't think the same fix would work there?

17.   Section 5.4, remove that in "used as Compression Reference is that the address". And the rest of that sentence is also a bit odd; not really sure what it is trying to convey?

18.   Section 5.5, adding a reference to Appendix A.3 would be really useful here; that example makes this much easier to understand (add to end of the section - "For an example, see Appendix A.3."?

19.   Section 6, "whereas the RPI is usually (and quiet illegally) omitted". It seems odd to use "usually" and "illegally"? Was this supposed to be legally? And later in same paragraph, "To impact of placing"? I think this was supposed to be "To impact the placing"?

20.   In section 9, 2nd paragraph, there is an opening parenthesis that is never closed.

21.   In section 10.2, the <- and -> and ## are a bit odd. Can these be changed into just normal text? Or is there a reason for these special markers?

That's it. The technical issues, as best I could understand them, seem to be in good shape.


-          Bernie Volz