Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt

"Georgios Z. Papadopoulos" <> Wed, 20 May 2020 11:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D75A3A08EA for <>; Wed, 20 May 2020 04:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X1zzjAH8FP2C for <>; Wed, 20 May 2020 04:45:41 -0700 (PDT)
Received: from ( [IPv6:2001:660:330f:2::c0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FF893A08CC for <>; Wed, 20 May 2020 04:45:40 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 5FECF80CB4; Wed, 20 May 2020 13:45:38 +0200 (CEST)
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id b4YkD7LWpG3k; Wed, 20 May 2020 13:45:33 +0200 (CEST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id CBABE819C2; Wed, 20 May 2020 13:45:33 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 CBABE819C2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1589975133; bh=ihI+ptTI+Ge6FhA/yP9lKQbtr0DuWZNpDLqpoTNuWz8=; h=Mime-Version:From:Date:Message-Id:To; b=DwGT97sDL8Ge+st9a0nEoYSziuvsVmPlJ8VEzGlOdIpoxxpMyCztlW9ytC/cxdhzH azOFWurOGzxDtDLuLQYgR4JDsY3bWMp80vue8YbbIHDWG3BKJnkqGiKBVoGrAqPIwx jLDKG7FpkqEXGn9L5AfHsg35YXlPkXzei+YJ1bVo=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id La__pQgmA4pn; Wed, 20 May 2020 13:45:33 +0200 (CEST)
Received: from [IPv6:2a01:e0a:170:d730:9fe:1c09:70d1:d436] (unknown [IPv6:2a01:e0a:170:d730:9fe:1c09:70d1:d436]) by (Postfix) with ESMTPSA id 9BEB980CB4; Wed, 20 May 2020 13:45:33 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B1B5841C-A537-46D2-A8F3-A5D999D01FAE"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Georgios Z. Papadopoulos" <>
Date: Wed, 20 May 2020 13:45:33 +0200
Cc: Routing Over Low power and Lossy networks <>
Message-Id: <>
References: <> <BM1PR01MB4020422CFBBF9205B39DF0E8A9BA0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
To:, Rahul Jadhav <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 May 2020 11:45:45 -0000

Hello Rahul,

Many thanks for the updated version.
I went through it today, and yes, it is in much more better shape now.

Below you will find my comments on this version : 

High level comments : 
- Section 2.1, second paragraph : “A router may use capabilities carried in DIO message as additional metrics/constraints.”. 
[GP]: One may ask : what prevents to have multiple metrics in DIO messages, without using the capabilities?

- Section 4.1, first sentence : “A node MUST drop or discard the message silently having an unknown capability with ’D’ (discard) flag set.”
[GP]: This sentence is not clear to me. Why a node would send an unknown to itself D flag to its neighbors. Could you please rephrase it?

- Section 4.1.1, second paragraph : “If the node is operating as 6LR and subsequently it receives a capability which it doesn’t understand with ’J’ flag set, then the node has to switch itself to 6LN mode.”
[GP]: This part is not clear to me. Why a 6LR should switch? I mean, simply because a neighbor node sends a DIO control packet with J that it does not understand? What is the ultimate objective by doing so?

- Setion 5.2 : I liked very much your description and justifications here. 
[GP]: Do you think would be possible to add here an example/figure with a simple topology to visualise the procedure.

Minor comments/typos/rephrasing : 
- [GP]: 1. Introduction, page 2, second paragraph, first sentence : “This document adds a notion of capabilities using which the nodes in the network” —> "This document adds a notion of capabilities using which nodes in the network”? (without THE nodes?)

- [GP]: 1. Introduction, page 2, second paragraph : “Mode of operation”, you already defined it earlier in the previous paragraph, you may write directly MOP, or keep o from operation in capital.

- [GP]: Section 2.1, 1st paragraph : Mode of Operation (MOP), you define it for the second time in the document.

- Section 4.1.1, 1st sentence : “On receiving a capability it does not support”
[GP]: You mean the following : A non-RPL node on receiving a capability that it does not support

- [GP]: Next paragraph : doesn’t understand with ‘J’ —> does not

- In the same Section, last paragraph : “Capabilities are used to indicate a feature that is supported by the node.  Capabilities are not meant for configuration management for”
[GP]: Maybe these sentences you should put move on section what is capabilities?

- [GP]: At the end of this paragraph : ./>, you might need to recompile it :-)

— — 
Best, and stay safe,

> On May 16, 2020, at 10:51, Rahul Jadhav <> wrote:
> Dear all,
> The update fixes all the points discussed during interim and subsequent ML discussions, namely:
> Flag for ignoring (silently discarding) the message if cap not understood.
> removal of global flag
> removal of info present flag. Earlier we had optional length for capabilities who do not have any information. Such capabilities are now aggregated as part of 'Capability Indicators'.. Thus this bit is no longer required.
> The indicator bits are ordered from left to right.
> Feedback/reviews are appreciated. Thanks.
> Best,
> Rahul
> ________________________________________
> From: Roll <> on behalf of <>
> Sent: 16 May 2020 04:41 PM
> To:
> Cc:
> Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF.
>         Title           : RPL Capabilities
>         Authors         : Rahul Arvind Jadhav
>                           Pascal Thubert
>                           Michael Richardson
>                           Rabi Narayan Sahoo
>         Filename        : draft-ietf-roll-capabilities-04.txt
>         Pages           : 12
>         Date            : 2020-05-16
> Abstract:
>    This draft enables the discovery, advertisement and query of
>    capabilities for RPL nodes.
> The IETF datatracker status page for this draft is:
> <>
> There are also htmlized versions available at:
> <>
> <>
> A diff from the previous version is available at:
> <>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> <>
> _______________________________________________
> Roll mailing list
> <>
> _______________________________________________
> Roll mailing list
> <>
> <>