A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network
draft-ietf-l2vpn-etree-frwk-10
Yes
(Adrian Farrel)
No Objection
(Alissa Cooper)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
Note: This ballot was opened for revision 07 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -07)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -07)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-08-07 for -07)
Unknown
Could figure 1 be placed after the first paragraph of Section 3? This would make it easier to look at the figure while reading the description that comes before and after the figure.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -07)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-08-07 for -07)
Unknown
I believe that its about time that text like sections 5 and 6 identified the lack of confidentiality mechanisms as a gap that needs to be filled. Which could done be via MACsec or (self-promotion alert!) MPLS with opportunistic security, or something else. Can you justify (given BCP188) why this is not a gap that's worth a look? This isn't a discuss since I'd be happy to raise such on a protocol spec if warranted, but also because it'd be wrong to expect you to re-do all L2VPN (by adding a "real" P:-) in this draft.