Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-l3sm-l3nm-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** RFC8177 already defines a container to represent an individual key -- key-string – as both a string and hex format. Additionally, this representation has built in ACLs to protect it. This model appears to maximize flexibility by supporting both key-chains and an explicit key for protocols like BGP, RIP and ISIS. Is there a reason why this model does not (or perhaps cannot) reuse the key-string representation from RFC8177 (the same way key-chain is)? And/or to not provide the flexibility for a hex encoded key? ** Section 9. The text notes that ‘vpn-service’ is sensitive to write operations. Wouldn’t ‘vpn-profiles’ be equally sensitive to alterations with similar consequences? For example, altering an encryption-profile-identifier could change the algorithm chosen or the key. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Rifaat Shekh-Yusef for the SECDIR review. To the authors: the explanatory text in Sections 4 and 7 made this large YANG model very accessible. It's sometimes hard to find the right balance between the text narrative and letting the model speak for itself, but this document negotiated it well. ** Section 7.6.5. Could we ever end up in a situation where security/enabled=True but the key-chain-ref pointed a key-chain who’s crypto-algorithm was cleartext? ** Section 9. In addition to sensitivity of customer-name and ip-connection to read operation, wouldn’t the corresponding topology information revealed by pretty much everything in vpn-service also be of concern? ** Section 9. The text enumerating sensitive read operations provides no caution about protecting the various key material. RFC8177 is cited later, but as noted in the DISCUSS, the suggested key wrap primitive is not usable with instances of “key” as the hex-key-string feature is not supported. ** Typos: Section 7.5. Typo. s/rendez-vous/rendezvous/ YANG. A few places. s/adresss/addresses/ YANG. Typo. s/oubtound/outbound/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
