Skip to main content

A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header
RFC 9035

Revision differences

Document history

Date Rev. By Action
2021-04-30
18 (System)
Received changes through RFC Editor sync (created alias RFC 9035, changed title to 'A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed …
Received changes through RFC Editor sync (created alias RFC 9035, changed title to 'A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header', changed abstract to 'This document updates RFC 8138 by defining a bit in the Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance and to specify the behavior of nodes compliant with RFC 8138 when the bit is set and unset.', changed pages to 9, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-04-30, changed IESG state to RFC Published, created updates relation between draft-ietf-roll-turnon-rfc8138 and RFC 8138)
2021-04-30
18 (System) RFC published
2021-04-22
18 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9035">AUTH48-DONE</a> from AUTH48
2021-04-20
18 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9035">AUTH48</a>
2021-02-23
18 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-01-28
18 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-01-27
18 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-01-27
18 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-01-27
18 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-01-26
18 (System) RFC Editor state changed to EDIT
2021-01-26
18 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-01-26
18 (System) Announcement was received by RFC Editor
2021-01-26
18 (System) IANA Action state changed to In Progress
2021-01-26
18 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-01-26
18 Cindy Morgan IESG has approved the document
2021-01-26
18 Cindy Morgan Closed "Approve" ballot
2021-01-26
18 Alvaro Retana IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-01-26
18 Alvaro Retana Ballot approval text was generated
2020-12-30
18 Alvaro Retana Waiting for the approval of draft-ietf-roll-useofrplinfo.
2020-12-30
18 Alvaro Retana IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup
2020-12-30
18 Alvaro Retana Ballot approval text was generated
2020-12-30
18 Benjamin Kaduk [Ballot comment]
Thank you for addressing my Discuss (and Comment) points!
2020-12-30
18 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-12-18
18 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-18.txt
2020-12-18
18 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-12-18
18 Pascal Thubert Uploaded new revision
2020-11-18
17 Ines Robles Added to session: IETF-109: roll  Thu-1600
2020-11-11
17 Martin Duke
[Ballot comment]
Thanks for addressing my DISCUSS.

I found last paragraph of Section 3 confusing. I suggest the following change:

OLD:
Section 6.3.1 of [ …
[Ballot comment]
Thanks for addressing my DISCUSS.

I found last paragraph of Section 3 confusing. I suggest the following change:

OLD:
Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification applies to MOP values 0 to 6. For a MOP value of 7, the compression MUST be used by default regardless of the setting of the "T" flag.

NEW:
"Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification adds codepoint 7 to the registry for this field.  For a MOP value of 7, the compression MUST be used by default regardless of the setting of the "T" flag.“
2020-11-11
17 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss
2020-09-30
17 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-17.txt
2020-09-30
17 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-09-30
17 Pascal Thubert Uploaded new revision
2020-09-24
16 Alvaro Retana
The resolution of the DISCUSS positions is normatively linked to draft-ietf-roll-useofrplinfo, which we will circle back through IETF LC and IESG Evaluation. 

I'm holding …
The resolution of the DISCUSS positions is normatively linked to draft-ietf-roll-useofrplinfo, which we will circle back through IETF LC and IESG Evaluation. 

I'm holding this document in this state waiting for that process to complete.
2020-09-24
16 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-16.txt
2020-09-24
16 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-09-24
16 Pascal Thubert Uploaded new revision
2020-09-18
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-09-18
15 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-15.txt
2020-09-18
15 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-09-18
15 Pascal Thubert Uploaded new revision
2020-09-10
14 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tirumaleswar Reddy.K.
2020-09-10
14 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2020-09-10
14 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-09-10
14 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-09-10
14 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-09-09
14 Benjamin Kaduk
[Ballot discuss]
The situation w.r.t. MOP values 5, 6, and 7 seems inconsistent to me.
We are not allocating them, but we are changing the …
[Ballot discuss]
The situation w.r.t. MOP values 5, 6, and 7 seems inconsistent to me.
We are not allocating them, but we are changing the RFC 6550 behavior in
the presence of at least one of them (but are not currently claiming to
Update 6550).  I have some further thoughts in the COMMENT section, but
I don't think the current state is consistent enough to be approved
as-is.
2020-09-09
14 Benjamin Kaduk
[Ballot comment]
The description of the RFC 8138 as a "packet compression technique"
throughout the document (e.g., "with the [RFC8138] compression turned
on") …
[Ballot comment]
The description of the RFC 8138 as a "packet compression technique"
throughout the document (e.g., "with the [RFC8138] compression turned
on") has been fairly confusing to me, since as I understand it, RFC 8138
defines a new routing header that just happens to have, as a primary
design consideration, a compression technique included.  So, the
incompatibility between non-8138 and 8138 nodes relates to the
understanding of the header, not the compression within the header.  As
8138 itself puts it: "It is expected that a router that does not
recognize the 6LoRH general format detailed in Section 4 will drop the
packet when a 6LoRH is present."  The discussion in (e.g.) section 5.2
then makes more sense when we have a mix of different header formats in
the same network, etc.  In my mind, the "T" flag is controlling "do we
use RFC 8138" and not "do we use RFC 8138 compression" (but perhaps I'm
just confused!).

This also (perhaps tangentially) relates to the concern brought up at
WG-adoption time relating to whether this is an appropriate mechanism
for conveying this kind of configuration.  If the intent is to say "this
DODAG uses RPL with a given routing header format", that seems a fairly
reasonable match for DODAG configuration information (though not
perfect), whereas "use this compression format for your RPI" seems
somewhat farther removed.  I say it's not a perfect fit for two reasons:
(1) as I understand it, the routing header behavior applies to the whole
RPL instance, not just the specific DODAG, so if there was an "RPL
Instance Configuration Option" that would be better; and (2) the
description in RFC 6550 of the Option is "used to distribute
configuration information for DODAG Operation", but "DODAG Operation" is
not defined.  If it was defined to be affecting the global configuration
for RPL operation within the DODAG that seems a better match for my
understanding of what it's intened to do.  (To be fair, my understanding
is shaped largely by looking at the existing 'A' flag and pondering that
it's not really related to DODAG formation/modification, and
extrapolating from a single data point is risky.)  An Update to RFC 6550
to clarify this aspect of the DODAG Configuration Option would make me
more comfortable with using this mechanism to affect what routing header
is used on the network.

Section 1

  Enabling [RFC8138] requires a Flag Day where the network is upgraded
  and rebooted.  Otherwise, if acting as a Leaf, a node that does not

[My inner pedant notes that this is not true for greenfield deployments,
where the "upgrade" is in place on first boot.]

Section 2.2

  SubDAG:  Subset of a DAG that is a child of a node

(nit) This seems a little ambiguous as to whether the node in question
is included (and also whether inclusion is based on transitive child
relationship vs. direct, though that interpretation doesn't acutally
make sense); perhaps "subset of a DAG that is itself a DAG, rooted at a
given node"?

Section 3

  This specification defines a new flag "Enable RFC8138 Compression"
  (T).  The "T" flag is set to turn-on the use of the compression of
  RPL artifacts with [RFC8138] within the DODAG.  The new "T" flag is
  encoded in position 2 of the reserved Flags field in the RPL DODAG
  Configuration Option, and set to 0 in legacy implementations as
  specified in Section 6.7.6 of [RFC6550].

(I agree with the other comments about "position 2" needing further
explanation, even if that's just a more prominent pointer to the
relevant IANA registry.)

  Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
  the DIO Base Object.  This specification applies to MOP values 0 to
  6.  For a MOP value of 7, the compression MUST be used by default
  regardless of the setting of the "T" flag.

I see that this is getting discussed elsewhere already, but it's not
entirely clear to me why we need to be so precise about the future
behavior.  Won't it be fine if whatever document allocates MOP value 7
also says whether or not to use compression^Wthe 8138 header format?
We could say something about "unless otherwise specified by the document
allocating the MOP value, this specification applies", even.

Section 5.2

  the RPL Instance may potentially join any DODAG.  The network MUST be
  operated with the "T" flag reset until all nodes in the RPL Instance
  are upgraded to support this specification.

nit: maybe s/reset/unset/?
2020-09-09
14 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-09-09
14 Warren Kumari
[Ballot comment]
Thanks to Nagendra for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-roll-turnon-rfc8138-10-opsdir-lc-nainar-2020-08-17/ ) and to the authors for working to address these.
This has made the …
[Ballot comment]
Thanks to Nagendra for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-roll-turnon-rfc8138-10-opsdir-lc-nainar-2020-08-17/ ) and to the authors for working to address these.
This has made the document clearer and better - thank you!
2020-09-09
14 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-09-09
14 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-09-09
14 Roman Danyliw
[Ballot comment]
Section 5.  Typo. s/an homogenous/a homogeneous/

Section 7.  Editorial. To be clearer on where the attacker is in the topology and on who …
[Ballot comment]
Section 5.  Typo. s/an homogenous/a homogeneous/

Section 7.  Editorial. To be clearer on where the attacker is in the topology and on who is incurring the cost:

OLD
An attacker in the middle of the network may reset the "T" flag to cause extra energy spending in its subDAG. 

NEW
An on-path attacker may reset the “T” flag to force additional energy consumption by the nodes in the subDAG.
2020-09-09
14 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-09-09
14 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-09-08
14 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-14.txt
2020-09-08
14 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-09-08
14 Pascal Thubert Uploaded new revision
2020-09-07
13 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Carles Gomez has done a Last Call IoT directorate review at https://mailarchive.ietf.org/arch/msg/iot-directorate/_UG_q8yutQU28ldYK1cdySTQoNs and had …
[Ballot comment]
Thank you for the work put into this document.

Carles Gomez has done a Last Call IoT directorate review at https://mailarchive.ietf.org/arch/msg/iot-directorate/_UG_q8yutQU28ldYK1cdySTQoNs and had a couple of nits and comments that were discussed and implemented. Thank you Carles for the review and thank you Pascal for updating the document accordingly.

I have only one comment/suggestion below.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 5  --
I find this text confusing at first read "adding nodes that do not support [RFC8138] after a roll back may be problematic if the roll back did not fully complete" I had to read section 5.3 to fully understand it.

Should something like ", the network operator must ensure that the roll back operation is completed before adding nodes that do not support RFC 8138" be easier to understand ?
2020-09-07
13 Éric Vyncke Ballot comment text updated for Éric Vyncke
2020-09-07
13 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Carles Gomez has done a Last Call IoT directorate review at https://mailarchive.ietf.org/arch/msg/iot-directorate/_UG_q8yutQU28ldYK1cdySTQoNs and had …
[Ballot comment]
Thank you for the work put into this document.

Carles Gomez has done a Last Call IoT directorate review at https://mailarchive.ietf.org/arch/msg/iot-directorate/_UG_q8yutQU28ldYK1cdySTQoNs and had a couple of nits and comments that were discussed and implemented. Thank you Carles for the review and thank you Pascal for updating the document accordingly.

I have only one comment/suggestion below.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 5  --
I find this text confusing at first read "adding nodes that do not support [RFC8138] after a roll back may be problematic if the roll back did not fully complete" I had to read section 5.3 to fully understand it.

Should something like ", the network operator must ensure that the roll back operation is completed before adding nodes that do not support RFC 8138" ?
2020-09-07
13 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-09-07
13 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-13.txt
2020-09-07
13 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-09-07
13 Pascal Thubert Uploaded new revision
2020-09-06
12 Murray Kucherawy
[Ballot comment]
The glossary lists "OF" and "OCP", but those acronyms are not present in the document.

I had to do some bouncing between documents …
[Ballot comment]
The glossary lists "OF" and "OCP", but those acronyms are not present in the document.

I had to do some bouncing between documents while reading Section 3.  Figure 1 shows what appear to be five flags, not four, and says "T" is declared in "position 2", though in the diagram it looks like the third position.  If position numbering is zero-based, that should be made clear (it's not in RFC 6550 either).
2020-09-06
12 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-09-05
12 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-09-02
12 Martin Duke
[Ballot discuss]
Now that I know that an IANA registry exists for MOP, codepoint 7 should be included in the IANA considerations for the "Mode …
[Ballot discuss]
Now that I know that an IANA registry exists for MOP, codepoint 7 should be included in the IANA considerations for the "Mode of Operation" Registry.
2020-09-02
12 Martin Duke
[Ballot comment]
I found last paragraph of Section 3 confusing. I suggest the following change:

OLD:
Section 6.3.1 of [RFC6550] defines a 3-bit …
[Ballot comment]
I found last paragraph of Section 3 confusing. I suggest the following change:

OLD:
Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification applies to MOP values 0 to 6. For a MOP value of 7, the compression MUST be used by default regardless of the setting of the "T" flag.

NEW:
"Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification adds codepoint 7 to the registry for this field.  For a MOP value of 7, the compression MUST be used by default regardless of the setting of the "T" flag.“
2020-09-02
12 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to Discuss from No Objection
2020-09-02
12 Martin Duke
[Ballot comment]
Sec 3. “Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification applies …
[Ballot comment]
Sec 3. “Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification applies to MOP values 0 to 6. For a MOP value of 7, the compression MUST be used by default regardless of the setting of the "T" flag.“

Is “This specification” referring to 6550 or roll-turn on-rfc8138? I have a feeling you mean RFC6550. But that document only defines MOPs 0-3!

On a similar note, it might be useful to establish an IANA registry for MOP code points so that change control for these bits is clearer.
2020-09-02
12 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-09-02
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-09-02
12 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-12.txt
2020-09-02
12 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-09-02
12 Pascal Thubert Uploaded new revision
2020-09-01
11 Barry Leiba
[Ballot comment]
Just a couple of very minor comments:

“RPL” should be expanded on first use.
We should probably ask the RFC Editor to mark …
[Ballot comment]
Just a couple of very minor comments:

“RPL” should be expanded on first use.
We should probably ask the RFC Editor to mark “DAG” and “DODAG” as “well known”, but they are not yet so marked, so “DODAG” should be expanded on first use.

— Section 5.3 —

  It is RECOMMENDED to only deploy nodes that support [RFC8138] in a
  network where the compression is turned on.

I think I misread this the first time; it’s ambiguous, so please reword it to make this clear.  What is it that’s recommended?:
1. In a network where compression is turned on, only deploy nodes that support 8138?
2. Don’t deploy nodes that support 8138 unless compression is turned on?

— Section 7 —

  An attacker in the middle of the network may reset the "T" flag

Thank you for this phrasing; I like it.
2020-09-01
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-08-31
11 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-08-27
11 Cindy Morgan Placed on agenda for telechat - 2020-09-10
2020-08-27
11 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2020-08-27
11 Alvaro Retana Ballot has been issued
2020-08-27
11 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2020-08-27
11 Alvaro Retana Created "Approve" ballot
2020-08-27
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-08-27
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-08-27
11 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-11.txt
2020-08-27
11 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-08-27
11 Pascal Thubert Uploaded new revision
2020-08-20
10 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2020-08-18
10 Alvaro Retana IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup
2020-08-18
10 Alvaro Retana Ballot writeup was changed
2020-08-18
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-08-17
10 Nagendra Nainar Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Nagendra Nainar. Sent review to list.
2020-08-17
10 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-08-17
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-roll-turnon-rfc8138-09. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-roll-turnon-rfc8138-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the DODAG Configuration Option Flags registry on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

a single new registration is to be made as follows:

Bit number: [ TBD-at-Registration ]
Capability Description: Turn on RFC8138 Compression (T)
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested Bit Number = 2 for this registration.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-08-14
10 Stewart Bryant Request for Last Call review by RTGDIR Completed: Not Ready. Reviewer: Stewart Bryant. Sent review to list.
2020-08-13
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2020-08-13
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2020-08-13
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2020-08-13
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2020-08-06
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tirumaleswar Reddy.K
2020-08-06
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tirumaleswar Reddy.K
2020-08-05
10 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-10.txt
2020-08-05
10 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-08-05
10 Pascal Thubert Uploaded new revision
2020-08-05
09 Carles Gomez Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Carles Gomez. Sent review to list.
2020-08-04
09 Carlos Pignataro Assignment of request for Last Call review by OPSDIR to Carlos Pignataro was rejected
2020-08-04
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Pignataro
2020-08-04
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Pignataro
2020-07-31
09 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2020-07-31
09 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2020-07-30
09 Samita Chakrabarti Request for Last Call review by IOTDIR is assigned to Carles Gomez
2020-07-30
09 Samita Chakrabarti Request for Last Call review by IOTDIR is assigned to Carles Gomez
2020-07-30
09 Min Ye Assignment of request for Last Call review by RTGDIR to IJsbrand Wijnands was rejected
2020-07-30
09 Min Ye Request for Last Call review by RTGDIR is assigned to Stewart Bryant
2020-07-30
09 Min Ye Request for Last Call review by RTGDIR is assigned to Stewart Bryant
2020-07-27
09 Min Ye Request for Last Call review by RTGDIR is assigned to IJsbrand Wijnands
2020-07-27
09 Min Ye Request for Last Call review by RTGDIR is assigned to IJsbrand Wijnands
2020-07-27
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-07-27
09 Amy Vezza
The following Last Call announcement was sent out (ends 2020-08-18):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-roll-turnon-rfc8138@ietf.org, roll-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2020-08-18):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-roll-turnon-rfc8138@ietf.org, roll-chairs@ietf.org, Ines Robles <mariainesrobles@googlemail.com>, aretana.ietf@gmail.com, mariainesrobles@googlemail.com, roll@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-roll-turnon-rfc8138-09.txt> (A RPL DODAG Configuration Option for the 6LoWPAN Routing Header) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document: - 'A RPL DODAG
Configuration Option for the 6LoWPAN Routing Header'
  <draft-ietf-roll-turnon-rfc8138-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-08-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document updates RFC 8138 by defining a bit in the RPL DODAG
  Configuration Option to indicate whether compression is used within
  the RPL Instance, and specify the behavior of RFC 8138-capable nodes
  when the bit is set and reset.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/



No IPR declarations have been submitted directly on this I-D.




2020-07-27
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-07-27
09 Alvaro Retana Requested Last Call review by RTGDIR
2020-07-27
09 Alvaro Retana Requested Last Call review by IOTDIR
2020-07-27
09 Alvaro Retana Last call was requested
2020-07-27
09 Alvaro Retana Ballot approval text was generated
2020-07-27
09 Alvaro Retana Ballot writeup was generated
2020-07-27
09 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-07-27
09 Alvaro Retana Last call announcement was changed
2020-07-27
09 Alvaro Retana Last call announcement was generated
2020-07-27
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-07-27
09 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-09.txt
2020-07-27
09 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-07-27
09 Pascal Thubert Uploaded new revision
2020-07-20
08 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-07-08
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-07-08
08 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-08.txt
2020-07-08
08 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-07-08
08 Pascal Thubert Uploaded new revision
2020-07-01
07 Alvaro Retana === AD Review of draft-ietf-roll-turnon-rfc8138-07 ===
https://mailarchive.ietf.org/arch/msg/roll/gT5lwjn6UIBUuFnX5sKCQ4ewJTM/
2020-07-01
07 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-07-01
07 Alvaro Retana Notification list changed to Ines Robles <mariainesrobles@googlemail.com>, aretana.ietf@gmail.com from Ines Robles <mariainesrobles@googlemail.com>
2020-06-29
07 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2020-04-17
07 Ines Robles
Shepherd write-up for draft-ietf-roll-turnon-rfc8138 - A RPL Configuration Option for the 6LoWPAN Routing Header-

(1) What type of RFC is being requested (BCP, Proposed Standard, …
Shepherd write-up for draft-ietf-roll-turnon-rfc8138 - A RPL Configuration Option for the 6LoWPAN Routing Header-

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Standards Track.
It presents a A RPL Configuration Option for the 6LoWPAN Routing Header

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document complements [RFC8138] and dedicates a flag in the RPL configuration option to indicate whether [RFC8138] compression should be used within the RPL Instance.  The setting of this new flag is  controlled by the Root and propagates as is in the whole network. When the bit is not set, source nodes that support [RFC8138] should refrain from using the compression unless the information is superseded by configuration.

Working Group Summary:

The document was discussed during the IETF 106 and adopted by the WG on Dec 11th 2019. The WG adoption was based on the following:
"-There were positive opinions, including from people who actively contribute to the writing of drafts at ROLL and related WGs, and who contribute to developing or evaluating their implementations.
-There was one opposition, arguing that RFC8138 turn on should be done another way.
-There is no substantiated technical proposal on the table other than draft-thubert-roll-turnon-rfc8138."

The document draft-ietf-roll-turnon-rfc8138-04 went on WG Last Call on February 20th 2020 and finished April 17th 2020 with version draft-ietf-roll-turnon-rfc8138-07, during Last call issues raised and were addressed by the authors.

Document Quality:

No current implementations were presented by the authors. The document improved the quality with the reviews done during the Last Call. This document is needed for the implementation of RFC8138.

Personnel:

Who is the Document Shepherd?  Ines Robles
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document and finds it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes: Pascal Thubert and Li Zhao confirmed not-be-aware of IPR on 26th March 2020.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR links to this draft.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WGLC was supported for few people, but those people are actively contributing to the WG, developing and implementing ROLL protocols.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There was one opposition during WG adoption call, arguing that RFC8138 turn on should be done another way. However, there is no substantiated technical proposal on the table other than draft-thubert-roll-turnon-rfc8138.
There was no opposition during WGLC.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ran with https://www6.ietf.org/tools/idnits: Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

ran with https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-roll-turnon-rfc8138-07.txt
Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

** Downref: Normative reference to an Informational RFC: RFC 7102
** Downref: Normative reference to an Informational RFC: RFC 7228


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not apply.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. Both normative references no-yet-rfc draft-ietf-roll-useofrplinfo and draft-ietf-roll-unaware-leaves are in the last call stages

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

- draft-ietf-roll-useofrplinfo: in last call stage

- draft-ietf-roll-unaware-leaves: : in last call stage


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This draft updates RFC 6550 (addressed in Section 3 of the draft) and RFC8138 (addressed in Section 4 of the draft).

The abstract mentions explicitly that the document updates RFC6550 and RFC 8138.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This specification updates the Registry for the "DODAG Configuration Option Flags" that was created for [RFC6550] -https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags-

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No. This specification updates an existing Registry.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not apply

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not apply
2020-04-17
07 Ines Robles Responsible AD changed to Alvaro Retana
2020-04-17
07 Ines Robles IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-04-17
07 Ines Robles IESG state changed to Publication Requested from I-D Exists
2020-04-17
07 Ines Robles IESG process started in state Publication Requested
2020-04-17
07 Ines Robles Changed consensus to Yes from Unknown
2020-04-17
07 Ines Robles Intended Status changed to Proposed Standard from None
2020-04-17
07 Ines Robles
Shepherd write-up for draft-ietf-roll-turnon-rfc8138 - A RPL Configuration Option for the 6LoWPAN Routing Header-

(1) What type of RFC is being requested (BCP, Proposed Standard, …
Shepherd write-up for draft-ietf-roll-turnon-rfc8138 - A RPL Configuration Option for the 6LoWPAN Routing Header-

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Standards Track.
It presents a A RPL Configuration Option for the 6LoWPAN Routing Header

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document complements [RFC8138] and dedicates a flag in the RPL configuration option to indicate whether [RFC8138] compression should be used within the RPL Instance.  The setting of this new flag is  controlled by the Root and propagates as is in the whole network. When the bit is not set, source nodes that support [RFC8138] should refrain from using the compression unless the information is superseded by configuration.

Working Group Summary:

The document was discussed during the IETF 106 and adopted by the WG on Dec 11th 2019. The WG adoption was based on the following:
"-There were positive opinions, including from people who actively contribute to the writing of drafts at ROLL and related WGs, and who contribute to developing or evaluating their implementations.
-There was one opposition, arguing that RFC8138 turn on should be done another way.
-There is no substantiated technical proposal on the table other than draft-thubert-roll-turnon-rfc8138."

The document draft-ietf-roll-turnon-rfc8138-04 went on WG Last Call on February 20th 2020 and finished April 17th 2020 with version draft-ietf-roll-turnon-rfc8138-07, during Last call issues raised and were addressed by the authors.

Document Quality:

No current implementations were presented by the authors. The document improved the quality with the reviews done during the Last Call. This document is needed for the implementation of RFC8138.

Personnel:

Who is the Document Shepherd?  Ines Robles
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document and finds it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes: Pascal Thubert and Li Zhao confirmed not-be-aware of IPR on 26th March 2020.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR links to this draft.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WGLC was supported for few people, but those people are actively contributing to the WG, developing and implementing ROLL protocols.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There was one opposition during WG adoption call, arguing that RFC8138 turn on should be done another way. However, there is no substantiated technical proposal on the table other than draft-thubert-roll-turnon-rfc8138.
There was no opposition during WGLC.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ran with https://www6.ietf.org/tools/idnits: Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

ran with https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-roll-turnon-rfc8138-07.txt
Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

** Downref: Normative reference to an Informational RFC: RFC 7102
** Downref: Normative reference to an Informational RFC: RFC 7228


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not apply.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. Both normative references no-yet-rfc draft-ietf-roll-useofrplinfo and draft-ietf-roll-unaware-leaves are in the last call stages

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

- draft-ietf-roll-useofrplinfo: in last call stage

- draft-ietf-roll-unaware-leaves: : in last call stage


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This draft updates RFC 6550 (addressed in Section 3 of the draft) and RFC8138 (addressed in Section 4 of the draft).

The abstract mentions explicitly that the document updates RFC6550 and RFC 8138.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This specification updates the Registry for the "DODAG Configuration Option Flags" that was created for [RFC6550] -https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags-

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No. This specification updates an existing Registry.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not apply

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not apply
2020-04-17
07 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-07.txt
2020-04-17
07 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-04-17
07 Pascal Thubert Uploaded new revision
2020-04-17
06 Ines Robles
Shepherd write-up for draft-ietf-roll-turnon-rfc8138 - A RPL Configuration Option for the 6LoWPAN Routing Header-

(1) What type of RFC is being requested (BCP, Proposed Standard, …
Shepherd write-up for draft-ietf-roll-turnon-rfc8138 - A RPL Configuration Option for the 6LoWPAN Routing Header-

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Standards Track.
It presents a A RPL Configuration Option for the 6LoWPAN Routing Header

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document complements [RFC8138] and dedicates a flag in the RPL configuration option to indicate whether [RFC8138] compression should be used within the RPL Instance.  The setting of this new flag is  controlled by the Root and propagates as is in the whole network. When the bit is not set, source nodes that support [RFC8138] should refrain from using the compression unless the information is superseded by configuration.

Working Group Summary:

The document was discussed during the IETF 106 and adopted by the WG on Dec 11th 2019. The WG adoption was based on the following:
"-There were positive opinions, including from people who actively contribute to the writing of drafts at ROLL and related WGs, and who contribute to developing or evaluating their implementations.
-There was one opposition, arguing that RFC8138 turn on should be done another way.
-There is no substantiated technical proposal on the table other than draft-thubert-roll-turnon-rfc8138."

The document draft-ietf-roll-turnon-rfc8138-04 went on WG Last Call on February 20th 2020 and finished April 17th 2020 with version draft-ietf-roll-turnon-rfc8138-06, during Last call issues raised and were addressed by the authors.

Document Quality:

No current implementations were presented by the authors. The document improved the quality with the reviews done during the Last Call. This document is needed for the implementation of RFC8138.

Personnel:

Who is the Document Shepherd?  Ines Robles
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document and finds it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes: Pascal Thubert and Li Zhao confirmed not-be-aware of IPR on 26th March 2020.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR links to this draft.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WGLC was supported for few people, but those people are actively contributing to the WG, developing and implementing ROLL protocols.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There was one opposition during WG adoption call, arguing that RFC8138 turn on should be done another way. However, there is no substantiated technical proposal on the table other than draft-thubert-roll-turnon-rfc8138.
We have no gotten opposition during WGLC.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ran with https://www6.ietf.org/tools/idnits: Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

ran with https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-roll-turnon-rfc8138-06.txt
Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not apply.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. Both normative references no-yet-rfc draft-ietf-roll-useofrplinfo and draft-ietf-roll-unaware-leaves are in the last call stages

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

- draft-ietf-roll-useofrplinfo: in last call stage

- draft-ietf-roll-unaware-leaves: : in last call stage


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This draft updates RFC 6550 (addressed in Section 3 of the draft) and RFC8138 (addressed in Section 4 of the draft).

The abstract nor introduction do not mention explicitly that the document updates RFC6550 and RFC 8138.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This specification updates the Registry for the "DODAG Configuration Option Flags" that was created for [RFC6550] -https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags-

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No. This specification updates an existing Registry.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not apply

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not apply
2020-04-17
06 Ines Robles
Shepherd write-up for draft-ietf-roll-turnon-rfc8138 - A RPL Configuration Option for the 6LoWPAN Routing Header-

(1) What type of RFC is being requested (BCP, Proposed Standard, …
Shepherd write-up for draft-ietf-roll-turnon-rfc8138 - A RPL Configuration Option for the 6LoWPAN Routing Header-

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Intended status: Standards Track.
It presents a A RPL Configuration Option for the 6LoWPAN Routing Header

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document complements [RFC8138] and dedicates a flag in the RPL configuration option to indicate whether [RFC8138] compression should be used within the RPL Instance.  The setting of this new flag is  controlled by the Root and propagates as is in the whole network. When the bit is not set, source nodes that support [RFC8138] should refrain from using the compression unless the information is superseded by configuration.

Working Group Summary:

The document was discussed during the IETF 106 and adopted by the WG on Dec 11th 2019. The WG adoption was based on the following:
"-There were positive opinions, including from people who actively contribute to the writing of drafts at ROLL and related WGs, and who contribute to developing or evaluating their implementations.
-There was one opposition, arguing that RFC8138 turn on should be done another way.
-There is no substantiated technical proposal on the table other than draft-thubert-roll-turnon-rfc8138."

The document draft-ietf-roll-turnon-rfc8138-04 went on WG Last Call on February 20th 2020 and finished April 16th 2020 with version draft-ietf-roll-turnon-rfc8138-06, during Last call issues raised and were addressed by the authors.

Document Quality:

No current implementations were presented by the authors. The document improved the quality with the reviews done during the Last Call. This document is needed for the implementation of RFC8138.

Personnel:

Who is the Document Shepherd?  Ines Robles
Who is the Responsible Area Director? Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document and finds it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes: Pascal Thubert and Li Zhao confirmed not-be-aware of IPR on 26th March 2020.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR links to this draft.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WGLC was supported for few people, but those people are actively contributing to the WG, developing and implementing ROLL protocols.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There was one opposition during WG adoption call, arguing that RFC8138 turn on should be done another way. However, there is no substantiated technical proposal on the table other than draft-thubert-roll-turnon-rfc8138.
We have no gotten opposition during WGLC.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ran with https://www6.ietf.org/tools/idnits: Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

ran with https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-roll-turnon-rfc8138-06.txt
Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not apply.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. Both normative references no-yet-rfc draft-ietf-roll-useofrplinfo and draft-ietf-roll-unaware-leaves are in the last call stages

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

- draft-ietf-roll-useofrplinfo: in last call stage

- draft-ietf-roll-unaware-leaves: : in last call stage


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This draft updates RFC 6550 (addressed in Section 3 of the draft) and RFC8138 (addressed in Section 4 of the draft).

The abstract nor introduction do not mention explicitly that the document updates RFC6550 and RFC 8138.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This specification updates the Registry for the "DODAG Configuration Option Flags" that was created for [RFC6550] -https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags-

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No. This specification updates an existing Registry.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not apply

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not apply
2020-04-16
06 Ines Robles IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2020-04-15
06 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-06.txt
2020-04-15
06 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-04-15
06 Pascal Thubert Uploaded new revision
2020-03-26
05 Ines Robles Notification list changed to Ines Robles <mariainesrobles@googlemail.com>
2020-03-26
05 Ines Robles Document shepherd changed to Ines Robles
2020-03-24
05 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-05.txt
2020-03-24
05 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-03-24
05 Pascal Thubert Uploaded new revision
2020-01-24
04 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-04.txt
2020-01-24
04 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-01-24
04 Pascal Thubert Uploaded new revision
2020-01-22
03 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-03.txt
2020-01-22
03 (System) New version accepted (logged-in submitter: Pascal Thubert)
2020-01-22
03 Pascal Thubert Uploaded new revision
2019-12-12
02 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-02.txt
2019-12-12
02 (System) New version accepted (logged-in submitter: Pascal Thubert)
2019-12-12
02 Pascal Thubert Uploaded new revision
2019-12-12
01 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-01.txt
2019-12-12
01 (System) New version accepted (logged-in submitter: Pascal Thubert)
2019-12-12
01 Pascal Thubert Uploaded new revision
2019-12-12
00 Pascal Thubert This document now replaces draft-thubert-roll-turnon-rfc8138 instead of None
2019-12-12
00 Pascal Thubert New version available: draft-ietf-roll-turnon-rfc8138-00.txt
2019-12-12
00 (System) New version accepted (logged-in submitter: Pascal Thubert)
2019-12-12
00 Pascal Thubert Uploaded new revision