MPLS Transport Profile (MPLS-TP) Survivability Framework
RFC 6372

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

(Stewart Bryant) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Russ Housley) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss, No Objection) No Objection

Comment (2010-06-30)
No email
send info
I thought this I-D was very well written.  I just found nits, which I bet the RFC-editor would have caught:

1) Section 1.2: r/in[RFC4427]/in [RFC4427]

2) Section 2: I think a verb is missing:

 The terms "defect" and "failure" are used interchangeably to
 indicate any defect or failure in the sense that they defined in
                                                      ^ are?

3) Section 4.1: r/OAM mechanisms ,/OAM mechanisms,

4) Section 4.1.3: Add period: [MPLS-TP-OAM-Framework].

5) Section 4.4.2: Add period: (1:n or m:n).

6) Section 4.4.3: Add period: service degradation.

7) Section 4.7: Missing ): (see Section
   4.5 associated with the protection function. 

8) Section 4.7.6: Extra "1"?:

 Additionally, note that the shared-protection resources could be used
 1 to carry extra traffic,  for example, in Figure 4, an LSP JPQRK
 ^ ?

9) Section 6.1.1: Missing period: etc.).

10) Section 6.1.2: Missing periods (X2): recovery entity.

11) Section 6.4: r/(Maintenance Group Intermediate Points (MIPs)/MIPs (Maintenance Group Intermediate Points)

12) Section 6.5: r/t1he/the

(Adrian Farrel) Recuse