Subject: [Last-Call] Opsdir last call review of draft-ietf-roll-turnon-rfc8138-10

From: Nagendra Nainar via Datatracker <[email-masked]>
Date: Mon, 17 Aug 2020 18:56:53 -0700

Reviewer: Nagendra Nainar
Review result: Has Issues

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts per guidelines in RFC5706.

Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Overall Summary:

This draft is a standard track proposing a new bit in the RPL DODAG
Configuration Option (defined in RFC6550) and update the compression behavior
defined in RFC8130.

Overall this is a very well written document. Some ambiguities that need
attention are listed below.

More details below:

--> Section 3 assigns a bit from the Configuration Options. This flag field is
instructed by RFC6550 to set to zero and should be ignored by the receiver. So
I think this draft should also update RFC6550 (in addition to RFC 8138).

--> I understand that the T flag is mentioned as bit position 2 in section 6.
AFAIK, bit position may start from 0 and can be LSB/MSB. To avoid confusing
(and any interop issues), I think the flag can be clarified in Fig 1 (or by
just defining another figure with the updated flag field).

A node SHOULD source packets in the compressed form using [RFC8138]
   if and only if the "T" flag is set.  This behaviour can be overridden
   by e.g., configuration or network management.

--> It appears that the above overriding exception can be interpreted as either
of the below:

Opt1 - A config knob can be used to let a node source packets in [RFC8138]
compressed form  even if T flag is not set. Opt2 - A config knob can be used to
let a node source packets without compression even if T flag is set.

Further section 5.2 mentions the below:

"To ensure that a packet is forwarded across the RPL DODAG in the form
   in which it was generated, it is required that all the RPL nodes
   support [RFC8138] at the time of the switch."

So I assume that the config exception is applicable only for Opt2?. I think it
is good to clarify the same to avoid any misinterpretation.

Thanks,
Nagendra

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Aug 2020 14:03:14 +0000

Hello Nagendra

Many thanks for your review!

Let's see below:

> --> Section 3 assigns a bit from the Configuration Options. This flag
> --> field is

This looked reasonable, and we did that till version 7 (https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-07).
It was our A-D comment that this was not actually an update. Quote from Alvaro in his "AD Review of draft-ietf-roll-turnon-rfc8138-07" on July 1st:
"

155	3.  Updating RFC 6550

[major] I don't think that a formal Update to rfc6550 is necessary.
In general, a formal Update indicates (at least to me) that an rfc6550 implementation has to also support this specification.  IOW, all RPL routers will have to support the new flag to be compliant with rfc6550.  Also, rfc8138 did not formally Update rfc6550.

"

> (and any interop issues), I think the flag can be clarified in Fig 1 (or by just
> defining another figure with the updated flag field).

I just added it based on the same comment by Stewart. It was not there so far because IANA did not confirm the bit position, now they did.

> --> It appears that the above overriding exception can be interpreted as
> --> either
> of the below:
> 

Both are valid. The next sentence says
"
                                                                                        Overriding may be
   needed e.g., to cope with a legacy implementation of the Root that
   supports [RFC8138] but not this specification and cannot set the "T"
   flag.
"
This is a case where RFC 8138 can be used but the T flag cannot be set, so it is an example of opt1.

> So I assume that the config exception is applicable only for Opt2?. I think it is
> good to clarify the same to avoid any misinterpretation.

There is text that indicates that in a transition phase there will be packets in both forms. 
The forwarding routers thus need to forward both forms. So all routers must support RFC8138.

Proposed change:
"
   A node SHOULD generate packets in the compressed form using [RFC8138]
   if and only if the "T" flag is set.  This behavior can be overridden
   by configuration or network management.  Overriding may be needed
   e.g., to turn on the compression in a network where all nodes support
   [RFC8138] but the Root does not support this specification and cannot
   set the "T" flag, or to disable it locally in case of a problem.

"

The resulting changes are visible at 
https://github.com/roll-wg/roll-turnon-rfc8138/commit/5aee34e2ea2ccacd77df278638199b178d9bb2c7
and the full text is 
https://github.com/roll-wg/roll-turnon-rfc8138/blob/master/roll-turnon-rfc8138.txt

Please let me know if we need more work.

Many thanks again, Nagendra!

Pascal

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 27 Aug 2020 11:23:22 +0000

Hi Pascal,

The changes are fine.

Regards,
Nagendra

On 8/18/20, 10:03 AM, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

    Hello Nagendra

    155	3.  Updating RFC 6550

    "

    Proposed change:
    "

    "

    Pascal