[Pce] Alvaro Retana's Discuss on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-stateful-flags-00: Discuss

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/



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


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