Re: [Roll] draft-ietf-roll-efficient-npdao review

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Sat, 08 September 2018 11:16 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DFE130DC8; Sat, 8 Sep 2018 04:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 GtAY0suC-XLn; Sat, 8 Sep 2018 04:16:01 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957F2130DC4; Sat, 8 Sep 2018 04:16:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13118; q=dns/txt; s=iport; t=1536405361; x=1537614961; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/8i3yEbewLXU8PN7BAPpnreEyP+n1w1Ngpa60kJbtPI=; b=ANQvMgNdCxBT8l+9oWDxJV8VuGCliBbYwx0Xj+DKDS6q6+MUgPFFzlya HDe4Cq7CkDU3dVKK5IjiJhtXbBcJQnGLPzFVTvf+ynRuCR7/WvnoCWHvA gaph6NPR6RQjlcEN+4cnQ10kzCeNpsSs6L81cMUgNnl8BGaouXu/+rOb9 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AdAgCSrpNb/4YNJK1bGgEBAQEBAgEBAQEIAQEBAYJXd2V/KINylzqHYognhUeBZgsfhE0CF4NLITgUAQIBAQIBAQJtHAyFOQYjJjAQAgEIPwMCAgIfERQRAgQOBYMhAYEdTAMVpQ2BLoNAg2YNgRmBNYplF4FBP4ESJx9RgUY1glaBcCAvJ4JDMYImAo0yE4VOiCcjKwkCiTODOoMTEQaBQIQ/gn6Fc4hJg1eHRgIRFIElNCGBVXAVOyoBgkEJiwyFPm+OMwEB
X-IronPort-AV: E=Sophos;i="5.53,346,1531785600"; d="scan'208,217";a="449461821"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2018 11:16:00 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w88BG0Vd031706 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 8 Sep 2018 11:16:00 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 8 Sep 2018 06:15:59 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Sat, 8 Sep 2018 06:15:59 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Rahul Jadhav <rahul.ietf@gmail.com>
CC: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Roll <roll@ietf.org>, "draft-ietf-roll-efficient-npdao@ietf.org" <draft-ietf-roll-efficient-npdao@ietf.org>
Thread-Topic: draft-ietf-roll-efficient-npdao review
Thread-Index: AQHUReMGP6D/WZ/UdU+9SxTvphKiTKTjv2IAgALSGYA=
Date: Sat, 08 Sep 2018 11:15:59 +0000
Message-ID: <E78532A5-D8E5-4394-921B-C67527099615@cisco.com>
References: <65ac8a93279212d8757d1ecf24ac9e42@bbhmail.nl> <CAO0Djp0HAMccSR+G6Zd=0TTPSmo0+mKv_XxAQG95vqQ+rDeN1w@mail.gmail.com>
In-Reply-To: <CAO0Djp0HAMccSR+G6Zd=0TTPSmo0+mKv_XxAQG95vqQ+rDeN1w@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_E78532A5D8E54394921BC67527099615ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/sR-Ab7Jy_7GitBMzVMQL3R6TU9A>
Subject: Re: [Roll] draft-ietf-roll-efficient-npdao review
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Sep 2018 11:16:04 -0000

Dear all

I made my own review and find the document mostly ready. I agree that Peter’s comments need handling to make the best text cleaner. The introduction could also be tightened and the English improved a bit, but I guess the rfc editor will help us there.

A word on DAO vs. NPDAO with a same sequence would clarify that the DAO is valid and the route installed or kept depending on the order of the 2 messages. A DAO received after a NPDAO but with an older sequence is ignored. This is classical RPL, but mentioning it could still be useful.

One last thing could be a bit more details on when to place options and why.

Otherwise all good for me!

Pascal

Le 6 sept. 2018 à 18:07, Rahul Jadhav <rahul.ietf@gmail.com<mailto:rahul.ietf@gmail.com>> a écrit :

Many thanks Peter for the review. We will work on these comments and update the draft and provide detailed response soon.

Thanks,
Rahul

On Thu, 6 Sep 2018 at 6:40 PM, Peter van der Stok <stokcons@bbhmail.nl<mailto:stokcons@bbhmail.nl>> wrote:
Hi authors,

Many thanks for this work and solving an open important problem.

being the shepherd of this draft, I looked at the text to look for improvements to facilitate the reading by the IESG.
I found the document difficult to read due to the use of multiple terms for the same concept.
I would appreciate that the first 3 sections are improved, such that I can continue the review afterwards without me wondering about my choices in the interpretation of the text.

For example: is a sub-node the same thing as a child in the node? and what is a dependent node?
Some suggestions to improve the document are written below.

Can you use, for example, the terms Switching-node (S-node) After-switching parent (A-parent) and Before-switching parent (B-parent); that will simplify the text and improve readability.
Please use consistently throughout one DODAG terminology like parent, child, ancestor or another preferred terminology.
What does "target" mean: an endpoint of a path, a field in a packet, or the S-node?
I thought that there can be many common ancestors on two paths with same source and destination, and one of them is the first common ancestor. BTW is the first one important; The rest of the text does not seem to rely on it.

In section 1.4; to which what subtree do you refer?

In section 8.2.1 of RFC6550 it is mentioned that there can be a set of preferred parents.
However, I have the impression that your assumption is the existence of a single preferred parent, Some explanatory text would help.

Some textual suggestions:
Every first introduction of an acronym must be introduced with the full name; for example: DAO must be written out both in the abstract as in the text for the first use; please look for all the first instances in the text.
In section 1.1 it will help if the list of used terms of RFC6550 is added.

Section 3; a reminder that this applies only to storing mode may help.

3.1 How can transmission be tolerant to a link failure when the link has disappeared completely or the node has been removed; some explanation is needed here. It would help if the assumptions are listed: like there is another path via ....

In section 3.1, 3.2 and 3.3 it should not be necessary to repeat what is written in section 2.1, 2.2 and 2.3, just a reference to the corresponding section will do.

Section 7 is rather short; I doubt that it will be accepted in this form.
There have been earlier comments on the insufficiency of the security considerations in RPL documents,

I hope I conveyed my problems sufficiently, and look forward to a new version to continue the review.

All the best,

Peter


--
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org<mailto:consultancy@vanderstok.org>, stokcons@bbhmail.nl<mailto:stokcons@bbhmail.nl>
www: www.vanderstok.org<http://www.vanderstok.org>
tel NL: +31(0)492474673     F: +33(0)966015248