Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Fri, Sep 11, 2020 at 12:23:50PM -0400, Michael Richardson wrote:
> 
> Benjamin Kaduk <[e-mail]> wrote:
>     > to MOPs 0..6; but the situation for MOP 7 seems slightly different.  If we
>     > were *just* leaving the bit undefined/free for reuse in that situation,
>     > that is probably also something that we can do in a normal "allocate a bit
>     > from an IANA registry" document without need for Updates.
> 
> Up to here, we agree.
> 
>     > But that's not
>     > all we're doing; we're also saying that if you see MOP==7, then you have to
>     > use the 8138 header/compression/whatever-we-end-up-calling-it.  Yet we are
>     > *not* allocating MOP==7.
> 
> Tthat's exactly what we don't want to do.
> 
> We are saying NOTHING about rfc8138 when MOP==7.
> Nor are we saying that the T-bit exists (or doesn't exist).

That's not how I read:

       For a MOP value of 7, the compression MUST be used by default
   regardless of the setting of the "T" flag.


> What behaviour is default and what behaviour is negotiated, and how it it
> negotiated, and how the results are turned on, would be up to a document that
> specifies MOP=7 (or larger mopex)

What you describe here is more along the lines of what I expected.

-Ben

> As an analogy, when we did the ToS->DSCP + bits-that-became-ECN
> change, we did this for IP_version==4 and IP_version==6.
> We specifically did not change it for IP_version==7 or 8.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>