Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)
RFC 7796

Note: This ballot was opened for revision 10 and is now closed.

Deborah Brungard Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Ben Campbell) No Objection

Comment (2015-12-01 for -10)
No email
send info
- 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

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-12-03 for -10)
No email
send info
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.)

(Joel Jaeggli) No Objection

Comment (2015-12-02 for -10)
No email
send info
 Sheng Jiang performed the opsdir review

Barry Leiba No Objection

Comment (2015-12-02 for -10)
No email
send info
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.)

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Comment (2015-11-30 for -10)
No email
send info
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.