Redundancy Mechanism for Inter-domain VPLS Service
RFC 7309

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

(Adrian Farrel) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2014-05-14 for -06)
No email
send info
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.

(Richard Barnes) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2014-05-12 for -06)
No email
send info
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.)

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2014-05-12 for -06)
No email
send info
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.

(Kathleen Moriarty) No Objection

Comment (2014-05-14 for -06)
No email
send info
Thanks for working through the SecDir review.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection