Hello Alvaro, Thanks for this Discuss. I think you found a hole in draft-ietf-pce-lsp-control-request. It doesn't look like a big hole because if you tried to apply both the C and the R flag, presumably the R flag would get executed making the C flag irrelevant. But I agree that the clarity of how to handle "conflicting" flags is missing.
Now we have to work out how to handle it. The options seem to be: 1. Set a rule, as you suggest, that documents that define new flags MUST define how to handle the case when the new flags contradict or clash with existing flags. Fix draft-ietf-pce-lsp-control-request according to that rule. 2. Fix draft-ietf-pce-lsp-control-request to clarify how the C flag interacts with other existing flags (specifically the R flag) 3. Define the processing of messages with "conflicting" flags 1.requires a specification and a modification to draft-ietf-pce-lsp-control-request 2. requires a modification to draft-ietf-pce-lsp-control-request 3. requires a specification (that updates 8231) I agree that this document could be the home for the specification in 1 or 3. But it could also be argued (especially for 3) that a new document with some thought and WG consensus on this new point is required. While the title of this document certainly puts that work in scope, I don't see that we necessarily have to hold back the simple clarification in this document in order to work on the other (perfectly valid) point. I would also say that documents that apply 2119 language to future documents are not necessarily successful. That is, constraining the authors of future documents is notoriously (but not impossibly) hard. That makes me think that options 2 or 3 are best. Option 2 does not require a modification to this document, but does require pulling draft-ietf-pce-lsp-control-request back to fix it. Option 3 does not necessarily require a change to this document *if* a new document is written, and does not require pulling draft-ietf-pce-lsp-control-request back. This is a worthy Discuss! But I don't know how to resolve it as a document author. Thanks, Adrian ---------------------------------------------------------------------- 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.] _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
