Skip to main content

Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)
draft-ietf-l2vpn-vpls-pe-etree-11

Yes

(Deborah Brungard)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Jari Arkko)
(Kathleen Moriarty)
(Spencer Dawkins)
(Terry Manderson)

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

Deborah Brungard Former IESG member
Yes
Yes (for -10) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2015-11-30 for -10) Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection (2015-12-02 for -10) Unknown
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.)
Ben Campbell Former IESG member
No Objection
No Objection (2015-12-01 for -10) Unknown
- 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
Jari Arkko Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-12-02 for -10) Unknown
 Sheng Jiang performed the opsdir review
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-12-03 for -10) Unknown
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.)
Terry Manderson Former IESG member
No Objection
No Objection (for -10) Unknown