The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
RFC 6670
Yes
No Objection
Note: This ballot was opened for revision 01 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Benoît Claise; former steering group member) Yes
Thanks for the document. Three editorial points: - Transport profile -> Transport Profile - "It is possible to argue that using MPLS for Transport is only a stepping stone in the middle of a longer transition." Transport -> transport or Transport Profile? - "As we shall demonstrate, ..." The RFC editor gave me in the past the advice to remove "we", "us", "our" from the future RFCs.
(Martin Stiemerling; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
(Russ Housley; former steering group member) Yes
Section 7 should be removed before publication as an RFC. The Gen-ART Review by Brian Carpenter reported one editorial problem. There is duplicated text in section 1.2: ... be managed using tools with similar look and feel. The requirements specifications [RFC5654] and [RFC5860] specifications [RFC5654] and [RFC5860] capture the essential issues that must be resolved to allow ...
(Sean Turner; former steering group member) Yes
(Stephen Farrell; former steering group member) Yes
I fully support the conclusion here and the argument varies from compelling at best to good enough at worst. typos: s/documentationin/document in/? s/viably/viability/ s/a E1 only/an E1 only/
(Stewart Bryant; former steering group member) Yes
(Barry Leiba; former steering group member) No Objection
Excellently written, clear document. Just a few minor editorial things; no need to reply to them: -- Section 3.4 -- OLD In an isolated system this may be the case, however when, as is usually case with communications technologies, simplification in one element of the system introduces a (possibly non-linear) increase in complexity elsewhere. NEW In an isolated system this may be the case; however, as is usually case with communications technologies, simplification in one element of the system introduces a (possibly non-linear) increase in complexity elsewhere. OLD the cost of increased complexity at a peer network element we loose out economically NEW the cost of increased complexity at a peer network element we lose out economically -- Section 3.6 -- OLD At the very least, the evaluation of these questions constitute a cost and introduce delay for the operator. COMMENT The subject is "evaluation", not "questions", so it's singular. NEW At the very least, the evaluation of these questions constitutes a cost and introduces delay for the operator. -- Section 4.3.2.2 -- "straightforward" is one word, not hyphenated. (Also in Appendix A.5)
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection