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

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Sat, 29 June 2019 02:58 UTC

From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-roll-efficient-npdao@ietf.org" <draft-ietf-roll-efficient-npdao@ietf.org>, Peter Van der Stok <consultancy@vanderstok.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>
Thread-Topic: Martin Vigoureux's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)
Thread-Index: AQHVLOdNw7Yz5yBN5kmurujYBJgKGKax5jwg
Date: Sat, 29 Jun 2019 02:57:25 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DF1B2EB@BLREML503-MBS.china.huawei.com>
References: <156163998890.21568.17755918950369424230.idtracker@ietfa.amsl.com>
In-Reply-To: <156163998890.21568.17755918950369424230.idtracker@ietfa.amsl.com>
Accept-Language: en-IN, zh-CN, 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/skhA2J_IfBXapuexdZDusYNe_es>
Subject: Re: [Roll] Martin Vigoureux's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)
Precedence: list

Thank you Martin for the review and feedback.
Please find my responses inline.

Thanks,
Rahul

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

Hi,

thank you for this document.

I only have minor comments/questions:
* Please expand LLNs
[RJ] Yes. Will add LLN in the terminology section. LLN term is not used anywhere before terminology section, so it should be ok to add in terminology section.

* it's a bit pity that D flag is bit '0' in DCO and bit '1' in DCO-ACK
[RJ]: Yes!

* 0x05 RPL Target and 0x06 Transit Information are RPL Control Message Options but they are not really DCO Options as they MUST be present.
[RJ]: That's true! The document has inherited this terminology from 6550! But I don't think we can call "Options" anything else in this document.

* it is not fully clear to me whether Path Sequence can or should be incremented on DCO retry.
[RJ]: Section 4.3.3 clarifies that the Path Sequence in DCO should be copied from the DAO message in response to which this DCO is generated.
I had to add one more sentence here to clarify another condition, "When the DCO is generated in response to a DCO from upstream parent, the Path Sequence MUST be copied from the received DCO."

* I'm not sure this has any meaning (didn't have enough time to think about this scenario) but what would happen if D sends a DAO which never reaches A and A decides to send an unsolicited DCO. How would D react to receiving a message with a sequence number which is smaller than the one it has sent? Is that an issue?
[RJ] This is a possible scenario. Section 4.4. "DCO Base Rules" point 5 explains how to deal with this. Essentially the DCO would be dropped because the Path Sequence is old.

* I feel that imposing the unused flags to be set to zero is not necessary.
MUST ignore the unspecified flags is sufficient.
[RJ] Again the document has inherited the wordings as-is from the parent document (RFC 6550). Unless it is "needed" to be removed, I would prefer keeping it in sync. Please let know if you still believe we should remove the imposing statement. Thanks

[Roll] Martin Vigoureux's No Objection on draft-i… Martin Vigoureux via Datatracker
Re: [Roll] Martin Vigoureux's No Objection on dra… Rahul Arvind Jadhav