Subject: Re: [Roll] Murray Kucherawy's No Objection on draft-ietf-roll-aodv-rpl-10: (with COMMENT)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Aug 2021 17:06:15 -0700

Hi Charles,

On Wed, Aug 18, 2021 at 1:48 PM Charles Perkins <[email-masked]>
wrote:

>  > I concur with Roman's DISCUSS, especially around the use of SHOULD.
>  > I'd go further and ask why that's not a MUST, or in the alternative,
>  > suggest that you provide some guidance around why an implementer might
>  > legitimately decide against doing what the SHOULD says.
>
> See also the response to Roman Danyliw.  An implementer might decide to
> use a proprietary security configuration, and not use the security
> specification provided by RPL.  Alternatively, certain closed systems
> will not be vulnerable to insertion of a rogue router, and cost savings
> or performance improvements might be realized by eliminating unnecessary
> security operations.
>

You might consider including such guidance around the SHOULD, if it's not
there already in some form.

  > The document shepherd writeup is more than two years old.
>
> This project fell off of my plate due to changes in employment and
> many urgent distractions.  Please excuse the delay.
>

You're the author, not the shepherd or the co-chair.  :-)  The concern I'm
raising here is that such a long time between the writeup and IESG
Evaluation forces me to wonder how stale the writeup's content is.  We,
collectively, should get in the habit of checking on this sort of detail
before it hits IESG Evaluation.

-MSK

---

From: Charles Perkins <[email-masked]>
Date: Wed, 18 Aug 2021 13:48:42 -0700

Hello Murray,

Please excuse the unusually long delay it has taken for us to respond to 
your comments.

Regarding the following:

 >  Murray Kucherawy No Objection
 > Comment (2021-04-22)
 > No email
 > send info

 > I also support John's DISCUSS.

We hope that John's DISCUSS has been resolved.

 > In Section 2, although "AODV-RPL Instance" is defined, it is present 
nowhere
 > in the document.  Also "ART Option" doesn't seem to be ordered correctly.

Deleting "AODV-RPL Instance" is an improvement.  Thanks for the observation.

It is logical to describe the RREQ option before describing how
the ART option provides the Targets of the route discovery operation.
Alternatively, the options could be presented in alphabetical order, which
would put RREP before RREQ, but that also seems counerintuitive.

 > In Section 9, I suggest being clear that what you're
 > actually updating are the named sub-registries of the
 > "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.

The text in Section 9 will refer to the "Subregistry" instead of
"Registry".  A sentence is to be included in the initial section
as follows:

     The Subregistries in this section are the named sub-registries of the
         "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.

Thank you for these useful comments.

Regards,
Charlie P.

On 4/22/2021 12:44 AM, Murray Kucherawy via Datatracker wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-roll-aodv-rpl-10: 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 DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I concur with Roman's DISCUSS, especially around the use of SHOULD.  I'd go
> further and ask why that's not a MUST, or in the alternative, provide some
> guidance around why an implementer might legitimately decide against doing what
> the SHOULD said.
>
> In Section 2, although "AODV-RPL Instance" is defined, it is present nowhere in
> the document.  Also "ART Option" doesn't seem to be ordered correctly.
>
> In Section 9, I suggest being clear that what you're actually updating are the
> named sub-registries of the "Routing Protocol for Low Power and Lossy Networks
> (RPL)" registry.
>
>
>