Re: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Thu, 27 June 2019 01:04 UTC

From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Roman Danyliw <rdd@cert.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, The IESG <iesg@ietf.org>
CC: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "draft-ietf-roll-efficient-npdao@ietf.org" <draft-ietf-roll-efficient-npdao@ietf.org>
Thread-Topic: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)
Thread-Index: AQHVLB4eWysOD1Be6UKbGJp8dhZ8e6at6yIA
Date: Thu, 27 Jun 2019 01:03:46 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DF0BFB6@BLREML503-MBX.china.huawei.com>
References: <156155357675.19915.16385205102161062477.idtracker@ietfa.amsl.com>
In-Reply-To: <156155357675.19915.16385205102161062477.idtracker@ietfa.amsl.com>
Accept-Language: en-IN, en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/BsELbjWyaORMhMCJOG_WPkaoZuY>
Subject: Re: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)
Precedence: list

Thanks Roman for the review and feedback.
Please find my response inline.

Thanks,
Rahul

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few areas of ambiguity:

(1) Section 4.3. Per “DCOSequence: Incremented at each unique DCO message …”:

-- To confirm, DCOSequence is getting incremented for each new unique DCO message? If so, how is it incremented?

[RJ] The exact increment operation is mentioned in section 4.4 "DCO Base Rules" point 1.

-- How is roll-over handled?

[RJ] This is an important catch. DCOSequence follows the same principle as other sequence counters as in RPL RFC 6550 Section 7.2. Quoting 6650, "All the sequence counters in RPL use lollipop counters, where the values from 128 and greater are used as a linear sequence to indicate a restart and bootstrap the counter, and the values less than or equal to 127 used as a circular sequence number space of size 128 as in RFC1982."
This needs to be explicitly stated/refed in the document. Thanks

(2) Section 4.3.4. Per the Status field and “The remaining status values are reserved as rejection codes”, where are those rejections codes described and enumerated?

[RJ] We have added a request for IANA for create a registry for this . Section 6.2 describes it in detail.

A few editorial nits:

** Section 1. Editorial Nit. s/RPL has an optional messaging/RPL has operational messaging/

[RJ] We wanted to convey that RPL has NPDAO messaging which is optional per 6550. Barry suggested we remove the "an" to make the sentence grammatically correct. Using "RPL has operational messaging" won't fit the required description.

** Section 2.3. Expand the word. s/async/asynchronous/

** Section 4.2. Typo. s/[RFC6550] allows parent address/[RFC6550] allows the parent address/

** Section 4.3. All of the other fields descriptions in this section specify the size of the field (e.g., 8-bit) but the description of DCOSequence does not

** Section 4.3.2. Cite the references for the permitted options

** Section 4.3.3. Typo. s/seqeunce/sequence/

[RJ] Will fix all these points

** Section 4.6.1. Per “Note that setting the I-flag”, this sentence would read more clearly without the double negative.

[RJ] I'll change the sentence to, "Note that setting the I-flag will not result in additional control overhead or other side-effects even if there is no previous route to be invalidated." Will this be ok?

[Roll] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker
Re: [Roll] Roman Danyliw's No Objection on draft-… Rahul Arvind Jadhav