Hi Robert, Thanks for your review and for working with me offline on the security considerations.
I have posted the -11 revision, which addresses your comments and comments from others. https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-aggregation-label-10&url2=draft-ietf-bess-mvpn-evpn-aggregation-label-11&difftype=--html Please let me know if you have any other comments. Thanks! Jeffrey Juniper Business Use Only -----Original Message----- From: Robert Sparks via Datatracker <nore...@ietf.org> Sent: Tuesday, July 11, 2023 12:05 PM To: sec...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-aggregation-label....@ietf.org; last-c...@ietf.org Subject: Secdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10 [External Email. Be cautious of content] Reviewer: Robert Sparks Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments. This document is mostly ready for publication as a Proposed Standard RFC, but has nits (one bordering on an issue) to address before publication. This document requires quite a bit of background provided outside of the document to make it meaningful. There is some effort to point to where essential concepts are defined, but a few more might be appropriate. It reads reasonably well, but I have provided some editorial comments at the end. Nit bordering on issue: The Security Considerations need more consideration. The essence of what's provided so far is "Nothing new to consider here, see RFC 5331, RFC 6514, RFC 7432, and RFC 8402 for the things you should really think about before using the procedures defined in this document". It's not clear how what the security consideration section in 5331 applies to these procedures - some discussion of what's important from that, and the other referenced docs, to _this_ document would be helpful. The primary concern seems to be entirely about the safe handling of, and consequences of (mis)-provisioning of, labels. Is there not a concise discussion in the literature around these labels to point to? Structural nit: The last paragraph and four bullets at the end of section 3.2 appears to be a set of pre-condition requirement (something that can only be violated by mis-configuration) rather than something to test for at runtime. Consider stating this earlier and as a requirement on configuration of the system. Or, if I'm incorrect, say what to do should a receiving PE encounter this configuration. Editorial nits: Consider more explicit instruction where you require PEs to program things. I think "place an entry in" or similar would be clearer. There is something that looks like normative text in the Terminology definition of SRGB (last sentence). Consider moving it into the body of the document, pointing to where it's specified (if specified elsewhere), or removing it. At "This document simply specifies" (in 2.1) - what does "simply" mean here? Please see if you can avoid the term. Consider rewriting the first sentence of 3.2 more directly (think about translation into other languages). Something like "The procedures here MAY be used when...". The "need not...unless" construction is difficult. At the last sentence of section 2.2 (before 2.2.1), consider how this will read in a decade. Avoid "today's networks" and simplify "more and more". Please break the single sentence paragraph at the end of page 12 (starting "When a PE receives an x-PMSI/IMEI") into several simpler sentences. Consider reworking the first part of "A PE MUST NOT both carry the DCB flag...". The route is carrying the flag, not the PE. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
