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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 21 Jan 2020 16:20:02 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-stateful-flags-00: No Objection

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-pce-stateful-flags/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this clear and well-written document!  I just have a couple
of editorial comments that probably don't even need a response.

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

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?

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jan 2020 01:08:08 -0000

> of editorial comments that probably don't even need a response.

Thanks for reading, Ben.

Every review comment deserves a response.

> say anything specifically about a flag value getting allocated (or

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.

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 21 Jan 2020 20:06:10 -0800

> Every review comment deserves a response.

You're too kind!

Both proposed changes look good to me :)

-Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jan 2020 04:21:58 -0000

>> Every review comment deserves a response.

Never knowingly 😉

> Both proposed changes look good to me :)

Great, thanks. They are in the buffer.

A