Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Jan 22, 2020 at 01:08:08AM +0000, Adrian Farrel wrote:
> > Thanks for this clear and well-written document!  I just have a couple
> > of editorial comments that probably don't even need a response.
> 
> Thanks for reading, Ben.
> 
> Every review comment deserves a response.

You're too kind!

Both proposed changes look good to me :)

-Ben

> > Section 4
> >
> >  There will remain an issue with compatibility between implementations
> >  of RFC 8231 that might set any of the unassigned flags, and current
> > (such as [RFC8281]) and future (such as
> >  [I-D.ietf-pce-lsp-control-request]) specifications.  That problem
> >  cannot be fixed in old implementations by any amount of
> >  documentation, and can only be handled for future specifications by
> >  obsoleting the Flags field and using a new technique.  Fortunately,
> >  however, most implementations will have been constructed to set
> >  unused flags to zero which is consistent with the behavior described
> >  in this document.
> >
> > I had a little bit of trouble reading this, as I keep expecting the
> > first sentence to be saying that there is a legitimately-allocated flag
> > value that is set with intent to change behavior, but it doesn't really
> > say anything specifically about a flag value getting allocated (or
> > used).
> 
> How about this becomes...
> 
>   There will remain an issue with compatibility between implementations
>   of RFC 8231 that might set any of the unassigned flags, and current
>  (such as [RFC8281]) and future (such as
>   [I-D.ietf-pce-lsp-control-request]) specifications that assign specific
>   meanings to flags if set.
> 
> > W.r.t. obsoleting Flags vs. relying on "most implementations" to be
> > consistent with this document's recommendations, is it worth being more
> > clear about the conclusion that this document is drawing, namely that
> > the risk of bad interactions is sufficiently small that there is no
> > desire to incur the cost of obsoleting/replacing the Flags field?
> 
> How about
> OLD
>    Fortunately,
>    however, most implementations will have been constructed to set
>    unused flags to zero which is consistent with the behavior described
>    in this document.
> NEW
>    Fortunately,
>    however, most implementations will have been constructed to set
>    unused flags to zero which is consistent with the behavior described
>    in this document and so the risk of bad interactions is sufficiently
>    small that there is no need to obsolete the existing Flags field.
> END
> 
> Thanks,
> Adrian
>