Subject: [Roll] Martin Duke's No Objection on draft-ietf-roll-turnon-rfc8138-12: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 02 Sep 2020 09:25:20 -0700

Martin Duke has entered the following ballot position for
draft-ietf-roll-turnon-rfc8138-12: 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-turnon-rfc8138/

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Sep 2020 16:35:19 +0000

Hello Martin

Many thanks for your time and review!

Let’s see below :

This specification means this draft not RPL.
Not sure how to improve this text. Curiously it went through a lot of massaging already.

Good point, and we actually did it.

Please see https://www.iana.org/assignments/rpl/rpl.xhtml#mop

Did you find anything else we could clarify ?

Take care,

Pascal

---

From: Martin Duke <[email-masked]>
Date: Wed, 2 Sep 2020 10:23:19 -0700

Ah, OK, I understand what is happening now though I would not have gotten
that from the text.

1. It is critical that IANA considerations then add instructions to add MOP
codepoint 7 to the registry.

2. May I suggest new text for this paragraph:
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.“

Martin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Sep 2020 20:39:22 +0000

Hello Martin

I answered separately but the intention is not to define a mop 7 now.  It will be defined later, when there is a need for it, see section 1.1 https://tools.ietf.org/html/draft-ietf-roll-mopex-cap-01.

All we say is that in the future when new mops are definitely, RFC 8138 will not be an option but taken for granted.

Take care,

Pascal

Le 2 sept. 2020 à 19:23, Martin Duke <[email-masked]> a écrit :

Ah, OK, I understand what is happening now though I would not have gotten that from the text.

1. It is critical that IANA considerations then add instructions to add MOP codepoint 7 to the registry.

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

Martin

On Wed, Sep 2, 2020 at 9:35 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Martin

Let’s see below :

Take care,

Pascal