Redundancy Mechanism for Inter-domain VPLS Service
draft-ietf-l2vpn-vpls-inter-domain-redundancy-07
Yes
(Adrian Farrel)
No Objection
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)
(Stephen Farrell)
Note: This ballot was opened for revision 06 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -06)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(2014-05-14 for -06)
Unknown
The shepherd write-up says that this is BCP. The draft and data-tracker status say Standards Track. This needs to be clarified before it progresses.
Alissa Cooper Former IESG member
No Objection
No Objection
(2014-05-12 for -06)
Unknown
Section 7: "In this document, ICCP protocol is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed and highly monitored network. This should be ensured by the operator." I understand what is meant here, but it might be good to be a bit more specific about the desired monitoring given recent discussions and RFCs about pervasive monitoring. I would suggest something like: "In this document, ICCP protocol is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a network that is well managed and whose service levels and availability are highly monitored. This should be ensured by the operator." Section 9: s/author/authors/ (I assume.)
Barry Leiba Former IESG member
No Objection
No Objection
(for -06)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -06)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -06)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -06)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -06)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-05-14 for -06)
Unknown
Thanks for working through the SecDir review.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -06)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -06)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -06)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -06)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(for -06)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2014-05-12 for -06)
Unknown
It would be nice if this document contained a clear definition of what is meant by "node redundancy". I think this is referring to PE nodes, but walking back to RFC 3985 I don't find a definition for that term, but as I progress through later RFCs I start to see "PE device" and later "PE node." I suspect that this is a well-understood term of art, but for the sake of readers who are trying to find their way through these documents for the first time it would help to make that clear. This stuck out for me because I at first interpreted "node" in the usual way that we use it in IETF protocols, and that definition of "node" doesn't make a whole lot of sense in the context of this document. I'm not in love with the sketchiness of the solution to state flapping described in section 7, but I assume that people who know more about this than I are satisfied with it, so I will say no more on the subject.