Updated Rules for Processing Stateful PCE Request Parameters Flags
draft-ietf-pce-stateful-flags-01

[Ballot 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?

[Ballot discuss]
The acknowledgement to the authors of I-D.ietf-pce-lsp-control-request prompted me to go take a look at that document and refresh my mind on the fact that it defines a new flag called LSP-Control Request Flag (C).  I find it hard to resolve in my mind when it would make sense for the R (LSP REMOVE from rfc8281) and C flags to be set at the same time. 

I couldn't find in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request or this document any discussion about the ability (or not) to set more than one Flag at a time.

In line with it's title, I would like to see this document include rules about processing of multiple flags.  I know that it is not possible to set out rules for the interaction of yet-to-be-defined flags, but at least adding text to the effect of "documents defining additional flags MUST discuss how they interact with existing flags" would go a long way.

I am balloting DISCUSS because even though this document is not introducing new issues, the combination of what is defined in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request does...and a document titled "Updated Rules for Processing Stateful PCE Request Parameters Flags" is then the optimal place to address them.

[Aside: If this DISCUSS is resolved as suggested above, then I-D.ietf-pce-lsp-control-request, which is on the RFC EDitor's queue, will have to be updated.]

[Ballot comment]
(1) Compatibility

The compatibility issue described at the end of §4 could result in all types of unforeseen errors or more serious issues; even considering just the one flag defined in rfc8281: the R flag = LSP REMOVE.  One of the incompatibility results could be for an rfc8231-only implementation to set the R flag (it has unknown functionality to the sender), and then for an rfc8281 implementation to receive the object and remove the LSP.  Not only could this result in operational issues by removing an LSP that shouldn't have been removed, but this action could also be considered a denial of service. 

This is not a new issue created by this document, but given that the latent compatibility issues are presented, then a more robust discussion is needed -- I would like to see it in the Security Considerations, but using the Compatibility Considerations section works for me too.

To be clear on my expectation.  The current text sounds tentative and even alarming: (paraphrasing) there's an issue that cannot be solved unless we start over!  It would be nice to then add some text that talks about the potential effects: taking an unintended action, opening the door for an attacker, etc.


(2) Going back to the specification:

      Flags (32 bits): This document does not define any flags.
      Unassigned flags MUST be set to zero on transmission and MUST be
      ignored on receipt.  Implementations that do not understand any
      particular flag MUST ignore the flag.

Aren't the two Normative sentences redundant?  The most likely reason for a receiver to not understand a flag is for it to not have it implemented, which is the same as it considering it not assigned.  Are there cases that I'm missing which require both statements?  Perhaps s/Unassigned/Unknown and remove the second sentence.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-stateful-flags-00. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the SRP Object Flag Field registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

[ RFC-to-be ] will be added to [RFC8281] as the reference for the registry. IANA understands that no other changes to the registry are required.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-stateful-flags@ietf.org, db3546@att.com, Hariharan Ananthakrishnan , hari@netflix.com, pce@ietf.org, pce-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Updated Rules for Processing Stateful PCE Request Parameters Flags) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Updated Rules for Processing Stateful PCE
Request Parameters Flags'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Extensions to the Path Computation Element Communication Protocol
  (PCEP) to support stateful Path Computation Elements (PCEs) are
  defined in RFC 8231.  One of the extensions is the Stateful PCE
  Request Parameters (SRP) object.  That object includes a Flags field
  that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
  for tracking assigned flags.  However, RFC 8231 does not explain how
  an implementation should set unassigned flags in transmitted
  messages, nor how an implementation should process unassigned,
  unknown, or unsupported flags in received messages.

  This document updates RFC 8231 by defining the correct behaviors.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
-> Proposed Standard

Why is this the proper type of RFC?
-> It is a technical specification of a protocol extension

Is this type of RFC indicated in the title page header? 
-> Yes
(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 
Technical Summary:
->Extensions to the Path Computation Element communications Protocol
  (PCEP) to support stateful Path Computation Elements (PCEs) are
  defined in RFC 8231.  One of the extensions is the Stateful PCE
  Request Parameters (SRP) object.  That object includes a Flags field
  that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
  for tracking assigned flags.  However, RFC 8231 does not explain how
  an implementation should set unassigned flags in transmitted
  messages, nor how an implementation should process unassigned,
  unknown, or unsupported flags in received messages.

  This document updates RFC 8231 by defining the correct behaviors.

Working Group Summary:
->This I-D being a very focused and uncontroversial fix, it has been moved
directly from individual draft to WGLC and submitted to the AD. Based
on the direction from the AD, the file name was changed to reflect the
WG output and to garner more visibility within the WG.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? 
-> A private and unscientific poll of implementers of RFC 8231 conducted
  by the author suggests that existing implementations already abide by
  the modification set out in this document.

Personnel:
Who is the Document Shepherd?
-> Hariharan Ananthakrishnan

Who is the Responsible Area Director? 
-> Deborah Brungard

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 
-> The document has been reviewed, updated and is ready to progress.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 
-> No ( We trust the RFC Editor to catch the remaining nits.)

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
-> N/A
 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 
-> N/A

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
-> Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 
-> No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 
-> It reflects WG consensus, extending RFC 8231 to make sure the
unknown flags are handled properly. The document has been reviewed by
some of the key WG members.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 
-> N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 
-> A reference to a living I-D will need to be kept to the latest version.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 
-> N/A

(13) Have all references within this document been identified as either normative or informative? 
-> Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 
-> No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 
-> No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relaationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 
-> This document updates RFC 8231 by defining the correct behaviors.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 
-> The IANA section is consistent with the document's body.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 
-> N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
-> N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
-> N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? 
-> Proposed Standard

Why is this the proper type of RFC?
-> It is a technical specification of a protocol extension

Is this type of RFC indicated in the title page header?
-> Yes


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Extensions to the Path Computation Element communications Protocol
  (PCEP) to support stateful Path Computation Elements (PCEs) are
  defined in RFC 8231.  One of the extensions is the Stateful PCE
  Request Parameters (SRP) object.  That object includes a Flags field
  that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
  for tracking assigned flags.  However, RFC 8231 does not explain how
  an implementation should set unassigned flags in transmitted
  messages, nor how an implementation should process unassigned,
  unknown, or unsupported flags in received messages.

  This document updates RFC 8231 by defining the correct behaviors.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
-> This I-D being a very focused and uncontroversial fix, it has been moved directly from individual draft to WGLC.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
-> A private and unscientific poll of implementers of RFC 8231 conducted
  by the author suggests that existing implementations already abide by
  the modification set out in this document.


Personnel

  Who is the Document Shepherd?
-> Hariharan Ananthakrishnan

Who is the Responsible Area Director?
-> Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
-> The document has been reviewed, updated and is ready to progress.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
-> No ( We trust the RFC Editor to catch the remaining nits.)


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
-> N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
-> N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
-> Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
-> No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
-> It reflects WG consensus, extending RFC 8231 to make sure the
unknown flags are handled properly. The document has been reviewed by
some of the key WG members.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
-> N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
-> A reference to a living I-D will need to be kept to the latest version.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
-> N/A

(13) Have all references within this document been identified as
either normative or informative?
-> Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
-> No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
-> No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
-> This document updates RFC 8231 by defining the correct behaviors.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).
-> The IANA section is consistent with the document's body.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
-> N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
-> N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? 
-> Proposed Standard

Why is this the proper type of RFC?
-> It is a technical specification of a protocol extension

Is this type of RFC indicated in the title page header?
-> Yes


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Extensions to the Path Computation Element communications Protocol
  (PCEP) to support stateful Path Computation Elements (PCEs) are
  defined in RFC 8231.  One of the extensions is the Stateful PCE
  Request Parameters (SRP) object.  That object includes a Flags field
  that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
  for tracking assigned flags.  However, RFC 8231 does not explain how
  an implementation should set unassigned flags in transmitted
  messages, nor how an implementation should process unassigned,
  unknown, or unsupported flags in received messages.

  This document updates RFC 8231 by defining the correct behaviors.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
-> This I-D being a very focused and uncontroversial fix, it has been moved directly from individual draft to WGLC.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
-> A private and unscientific poll of implementers of RFC 8231 conducted
  by the author suggests that existing implementations already abide by
  the modification set out in this document.


Personnel

  Who is the Document Shepherd?
-> Hariharan Ananthakrishnan

Who is the Responsible Area Director?
-> Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
-> The document has been reviewed, updated and is ready to progress.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
-> No ( We trust the RFC Editor to catch the remaining nits.)


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
-> N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
-> N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
-> Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
-> No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
-> It reflects WG consensus, extending RFC 8231 to make sure the
unknown flags are handled properly. The document has been reviewed by
some of the key WG members.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
-> N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
-> A reference to a living I-D will need to be kept to the latest version.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
-> N/A

(13) Have all references within this document been identified as
either normative or informative?
-> Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
-> No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
-> No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
-> This document updates RFC 8231 by defining the correct behaviors.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).
-> The IANA section is consistent with the document's body.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
-> N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
-> N/A