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

[Benjamin Kaduk <[e-mail]>]

On Thu, Sep 10, 2020 at 04:58:33PM -0400, Alvaro Retana wrote:
> Hi!
> 
> Jumping in here on the Updates/MOP 7 point.
> 
> 
> The only reason we’re trying to treat MOP 7 differently is because we (the
> WG) know that the mopex draft is coming…which is the future document that
> will define what 7 really means.
> 
> However, we’re still not there…and the mopex draft should be the one
> defining all the changes.
> 
> I think the easiest thing to do at this point is to ignore mopex, and the
> knowledge that things will change in the future…because we still don’t know
> exactly what that future will be…this extension should then simply be
> defined as other extensions have been: applicable to all MOPs.  When mopex
> comes we can deal with the respective Updates, changes to the registries,
> etc.

That seems like it's setting us up for exactly the situation that
Pascal/Michael want to avoid -- if we allocate the T flag "normally" then
an implementation written next month will treat the bit in position 2 as
the T flag, independnetly of the MOP value.  When MOP==7 finally comes
along then the bit is burned and can't be repurposed, so long as that
implementation is still deployed, and that can't be fixed by Updates or
registry changes.

Is it so bad to say that the bit allocation is only defined for a subset of
MOPs?

-Ben