Re: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-unaware-leaves-25: (with COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 16 December 2020 08:50 UTC

IronPort-PHdr: 9a23:s7a9zhLUZpkyq8eGa9mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeGvK8/h1LTQcPc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoOkVPBID5fVKB6nG35CQZTxP4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>, JADHAV Rahul <rahul.ietf@gmail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-roll-unaware-leaves-25: (with COMMENT)
Thread-Index: AQHW0xvCdS2PvjL+B0+gbd0gQq9j+qn5YStg
Date: Wed, 16 Dec 2020 08:50:08 +0000
Deferred-Delivery: Wed, 16 Dec 2020 08:49:28 +0000
Message-ID: <CO1PR11MB488115DD69F0A8A3ACE88F3DD8C50@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <160806191542.14056.12076928149451139392@ietfa.amsl.com>
In-Reply-To: <160806191542.14056.12076928149451139392@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f12ff28d-e608-4e8f-5482-08d8a19fa6ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 08:50:34.3018 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: axvffBt0l/C2BCHXx9P2fKGOUJGdiVGtJS4puDC8MPon61+tljDaXmIXymIsUVoeqs/P5cup01vQtnZrvx6x3A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4635
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/SBHyW5tQct7pfG43arju2Fq4_Lc>
Subject: Re: [Roll] Roman Danyliw's No Objection on draft-ietf-roll-unaware-leaves-25: (with COMMENT)
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: Wed, 16 Dec 2020 08:50:39 -0000

Hello Roman:

Many thanks for your review! 

I placed the proposed diffs here:

https://github.com/roll-wg/roll-unaware-leaves/commit/6695ef9f0c8596507f69fd09dc0c8b205e9e9115

And will publish -26 soon.

Let's see below:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for responding to the SECDIR review and thank you to Carl Wallace
> for performing it
> 
> ** Section 6.1.  ROVRsz value.
> 
> Indicates the Size of the ROVR.  It SHOULD be 1,
>       2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
>       respectively.  If a legacy Target Option is used, then the value
>       must remain 0, as specified in [RFC6550].
> 
> -- Why are the values of ROVRsz not constrained with a MUST to 0 – 4?  What’s
> the thinking on allowing undefined ROVR size values?  Or not specifying that
> these values comes from:
> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-
> parameters.xhtml#icmpv6-parameters-codes-type-157-code-suffix
> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-
> parameters.xhtml#icmpv6-parameters-codes-type-158-code-suffix

The SHOULD was to allow a value of 0. But thinking twice, it's good to force it to non-zero so we can identify the support of this spec.

I changed to: 
"
                        It MUST be set to 1, 2, 3, or 4, indicating a ROVR size
                        of 64, 128, 192, or 256 bits, respectively.
"


> -- If the values of ROVR are 1 – 4 why are 4 bits required, not 3 (i.e., 100 = 4)?

This denotes the size of a hash (see RFC 8928). We left a chance to expand to much larger hashes. I thought you'd appreciate.
The future role of the ROVR in RPL is along the lines of Route Ownership Validation (big surprise), to be designed though.

> 
> ** Section 11.
> Additionally, the trust model could include a role validation to
>    ensure that the node that claims to be a 6LBR or a RPL Root is
>    entitled to do so.
> 
> How does this role validation (verification of entitlement) work?
> 
Hum, how can I answer this one without a WG designing it? I added 
" e.g., using a role-based authorization) 
"
But there should be more interesting / scalable / zero-confable methods. 
I do not want this spec to look like it recommends a method when that really belongs to another Area.

I'm happy to add more text but I'd need your help crafting it.

Keep safe;

Pascal

[Roll] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker
Re: [Roll] Roman Danyliw's No Objection on draft-… Pascal Thubert (pthubert)