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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 15 Dec 2020 11:51:55 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-roll-unaware-leaves-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/

----------------------------------------------------------------------
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

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

** 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?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Dec 2020 08:50:08 +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:

> Thank you for responding to the SECDIR review and thank you to Carl Wallace
> for performing it
> 
> 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.

> 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