Hi, I'm continuing my campaign of reviewing PCE I-Ds that have been around for a while. This one had a very long run as an individual I-D, saw an implementation reported back in 2020, and was adopted in July last year. It seems the work is pretty stable. Perhaps it's time to polish it and move to last call.
So here is a review. The document is really well written and easy to read. I only find a few nits. Cheers, Adrian === Abstract s/the associated and the dependent/any associated and dependent/ --- 1. s/[RFC7470] defined Vendor/[RFC7470] defined the Vendor/ s/defined VENDOR-INFORMATION-TLV/defined the VENDOR-INFORMATION-TLV/ OLD This document extends the usage of Vendor Information Object and VENDOR-INFORMATION-TLV to Stateful PCE. NEW This document extends the usage of the Vendor Information Object and the VENDOR-INFORMATION-TLV to Stateful PCE. END --- 2. Somewhere in this document, you need a reference to RFC 5511. The usual form of words is something like... The message formats in this document are specified using Routing Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. --- Section 2 uses the VENDOR-INFORMATION object. That's all fine, but it would be good to be more explicit with the pointer to RFC 7470. Something like... OLD The contents and format of the object are described in Section 4 of [RFC7470]. NEW The contents and format of the object, including the VENDOR-INFORMATION object, are described in Section 4 of [RFC7470]. END --- I think that the 1.5 lines of Section 4 could easily be placed at the top of Section 2 and so remove the need for the section. --- 8. Something we never included in RFC 7470 (and 7150, before it) was the potential for the vendor-specific information to act as a covert channel. That is, as a way for applications to exchange information that is out of scope of PCEP. It could be used by malign software that has infected a PCE and PCC, It could even carry executable code. The nature of vendor-specific information is that it cannot be decoded or inspected by third parties. So it is difficult to protect against a covert channel. There is some protection in the "unrecognised object" and "unknown enterprise number" for a receiver, but this doesn't provide full protection against misuse. That is hard to mitigate. I think that we should have raised this point in 7470, and that it is not really something specific for this document. However, I think this work should mention the problem and say what can be done. Something like... The use of vendor-specific information as defined in [RFC7470] and in this document may provide a covert channel that could be misused by PCEP speaker implementations or by malign software at PCEP speakers. There is little protection against this, however, an operator that monitors the PCEP sessions can determine that vendor- specific information is being used and ask their suppliers (the PCE and PCC implementers) to provide a mechanism to decode the vendor- specific information. _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
