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

[Martin Duke <[e-mail]>]

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.

On Wed, Sep 2, 2020 at 2:32 PM Michael Richardson <[e-mail]>
wrote:

>
> Alvaro Retana <[e-mail]> wrote:
>     > 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.
>
> That doesn't really work better.
> For a MOP value of 7, there is no T flag.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>