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

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 02 Sep 2020 10:27:50 -0700

Martin Duke has entered the following ballot position for
draft-ietf-roll-turnon-rfc8138-12: Discuss

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/

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

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Sep 2020 15:51:46 -0400

> included in the IANA considerations for the "Mode of Operation" Registry.

Okay, but we don't know what MOP #7 is yet.
We have another WG document (draft-ietf-roll-mopex-01) that, for MOP#7
extends the bit space.  That document will register MOD#7.

This document avoids keeping the reservation of the scarce bits in the header
for future versions of the protocol.  We can define it always on in the future.
(Or not. It's the future)

The WG has spent a lot of time in the last year getting this right.

So having this document allocate MOP#7 is just wrong.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

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

Hello Martin

Code point 7 is not defined and éthique doc does not define it. The intention and WIP draft is that the value 7 will signal RPLv2, and that the support of RFC 8138 will be mandated at that point. The mop itself will be signaled in an extension, more in https://tools.ietf.org/html/draft-ietf-roll-mopex-cap. The text here is to prepare the current implementation so that it behaves correctly in the presence of RPLv2.

Does that answer the discuss?

Pascal

Le 2 sept. 2020 à 21:52, Michael Richardson <[email-masked]> a écrit :

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 2 Sep 2020 14:27:01 -0700

Hi!

Regardless of any future work, this document doesn’t define a new MOP.

Maybe what needs to be slightly clarified is this text from §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.

The specification does apply to all MOPs in that it is specifying what to do.

NEW>
   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the
   DIO Base Object.  This behavior specified in this document 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.

Alvaro.

On September 2, 2020 at 4:34:40 PM, Pascal Thubert wrote:

> Hello Martin
>
> Code point 7 is not defined and éthique doc does not define it. The
> intention and WIP draft is that the value 7 will signal RPLv2, and that the
> support of RFC 8138 will be mandated at that point. The mop itself will be
> signaled in an extension, more in
> https://tools.ietf.org/html/draft-ietf-roll-mopex-cap. The text here is to
> prepare the current implementation so that it behaves correctly in the
> presence of RPLv2.
>
> > Le 2 sept. 2020 à 21:52, Michael Richardson a écrit :
> >
> > Martin Duke via Datatracker wrote:
> > > 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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Sep 2020 17:32:03 -0400

NEW>
    >    default regardless of the setting of the "T" flag.

That doesn't really work better.
For a MOP value of 7, there is no T flag.

---

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

I find this all very odd, which maybe is a sign we should simply DISCUSS in
the telechat. As far as I can understand:
- codepoints 5, 6,  and 7 are currently unassigned, though
draft-ietf-roll-mopex-01 (still in the WG) allocates 7 as a field extender
(though this is not listed as a dependency)
- The intent of this document is to define a compression behavior of MOP 7
independently of the eventual outcome of roll-mopex, or indeed what the
extended MOP codepoints might want to do
- MOP 7 might indicate there is no T flag, although the current draft says
there would be and quick scan of draft-ietf-roll-mopex-01 doesn't reveal
why that might be true..

It is entirely possible I missed something critical, but as described this
seems unsatisfactory to me.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Sep 2020 21:32:41 -0400

> (though this is not listed as a dependency)

Right, we aren't sure what will be codepoints 5 and 6, but we suspect that we
might need them before we have an RPLv2.  Maybe.

    > extended MOP codepoints might want to do

No, that's not the goal.
The intent of this document is to define a compression behaviour for MOP 0..6 only.
We are signaling that before looking at the T flag, you need to know the MOP number.

    > there would be and quick scan of draft-ietf-roll-mopex-01 doesn't reveal

Because mopex doesn't define RPLv2.
mopex gives us enough more bits in order that we can eventually define
things.  Nodes that do not not understand the MOP value join a leaves rather
than routers (and we have several documents that clarify this behaviour).

So, the MOP value is the highest order determination of behaviour.

    > seems unsatisfactory to me.

I think that the first step is to make get you to understand our goals,
and then you can tell us where our text led you astray.