Deb Cooley has entered the following ballot position for draft-ietf-pce-stateful-pce-vendor-12: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 7, para 2: The last () is a bit puzzling. Is there something specific that is anticipated? It might need some explanation. RFC8253 is old enough that TLS1.3 wasn't published yet, but RFC 9325 obviously covers both TLS 1.2 and 1.3. Section 7, para 3, sentence 1: "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." Perhaps it should be malicious vs malign? Section 7, para 3, Sentences 2 and 3: Depending on the signaling design of the covert channel, detection by an overworked operator while in use is difficult. Prevention of malicious software at the PCEP speaker might be easier (not easy, just easier). Software that is required to be protected by integrity, authentication and authorization techniques will make the installation of malicious software harder. While I'm sure this is out of scope for this draft, it is a valid mitigation. _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
