Ballot for draft-ietf-l2vpn-vpls-pe-etree
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Section 3. (Introduction) describes an E-Tree (as defined by the MEF) using rfc2119 keywords. While the use of the keywords makes the description clearer, I don't think it is appropriate to use them as the text is describing what is defined somewhere else. In other words, this document does not normatively define an E-Tree. If parts of the description want to be emphasized, please use other means (or other words). I don't think this comment raises to a DISCUSS level, but I think it needs to be addressed before publication.
I agree with Ben and Álvaro about the use of 2119 key words to talk about something that's normatively specified in a MEF document and not here. Why does the first paragraph of the Introduction specifically mention MEF 6.1, with no reference provided? There is a reference to MEF 6.2 (but it's not cited here). Is something out of sync? And if so, why is there no citation in the Introduction? The MEF documents are cited in the Terminology section (with an incorrect citation to MEF6.1, which isn't in the references). That tells me that they should be normative references, as they're providing definitions of terminology that has to be understood... but you have them as informative references. Why? (This comment is very close to a DISCUSS, but I'm not balloting it that way.)
- Section 3, first paragaph: This seems to use 2119 keywords to describe existing requirements from the referenced specification. Please avoid 2119 keywords for that (unless in the form of direct quotes). -9: Can you elaborate on how the prevention of leaf-to-leaf communication enhances security? As written, this seems to leave the actual enhancement for the reader to infer. - 4, last sentence: s/are/is
Sheng Jiang performed the opsdir review
Could you explain a bit to me how prevention of leaf-to-leaf communication is enforced? I wasn't clear about that from a quick read, sorry. (I know it might not be quite in scope, being an implementation issue, but I'd like to know if it's easy to explain.) Are there possible attacks on signalling - e.g. to send fake packets saying some node is a root, when it's a leaf? If so shouldn't those be recognised in the security considerations? I think section 9 should describe the kind of node compromises that would invalidate the "no leaf to leaf" protections that are needed for this to work. The intent should be just to allow implementers to realise when a node that they are designing or deploying might need to be (better) protected against compromise. Were is possible to say something useful about how to mitigate such compromises, that'd be good too. (But it may amount to "harden your kit" I guess, which could be enough to say if one knows which bits of kit need hardening against what.)