Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Deborah,

On Tue, Oct 01, 2019 at 10:24:05PM +0000, BRUNGARD, DEBORAH A wrote:
> As it seems there are still some questions on "update or not", I'll try to add some additional context. As we know, it is difficult to define "update", so each working group has their context for it. For TEAS, CCAMP, MPLS, PCE, if it is a new capability, which is making use of previously reserved bits, we have not considered it an update, otherwise every new RFC would be an update of the base RFC.
> 
> Here's an example of exactly this (a quick scan by me, I'm sure there are many more across all the groups):
> The PCE-CAP-FLAGS sub-TLV was defined in RFC5088 (bits 9-31 were reserved). RFC 8623 defined stateful P2MP and defined new capability bits (from the reserved group) using 13, 14, 15. It was not considered an update of RFC5088 (OSPF extensions for PCE Discovery), or RFC8306 (P2MP TE LSPs for PCEP), or RFC8281 (base document with extensions to support stateful PCE). And RFC5088 was not an update of OSPF (RFC2328 and RFC2740). And RFC8281 was not an update to RFC5440 PCEP base spec). As you can see, this would result in a very big waterfall if all these were considered updates. An implementor of the base spec, with no interest in these new capabilities, would need to read all the updates just to be sure the base is not impacted. We wouldn't have any implementations, everyone would still be reading😊
> 
> In this document, these new values are using several more of the previously reserved values. Only implementors of this new capability need to be aware of these assignments, so among PCE folks, it is not considered an update.
> 
> Dhruv already responded to Ben on the PLSP-ID. It is the same as these flags, only those wanting to implement this new capability need to be aware of it. And it is backwards compatible with the base spec.

This all makes sense to me, and I see the reasoning behind not using
Updates: for them.  I'm not sure that our discussion here has covered the
relaxation of error handling, though -- we have "this MUST NOT trigger the
error handling as specified in [RFC8231]" in one place, and IIRC a similar
thing in one other place.  In some sense, this is overriding RFC 8231 and
an implementation of this spec is no longer compliant with the base RFC
8231 specification.  So, I wonder if the Updates: tag is needed in order to
"legitimize" this weakening of the requirements, as otherwise we have two
specifications which are formally in conflict with each other, one of which
is needed in order to use the other.

Thanks,

Ben