The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
draft-sprecher-mpls-tp-oam-considerations-03
Yes
(Adrian Farrel)
(Martin Stiemerling)
(Ron Bonica)
(Sean Turner)
(Stewart Bryant)
No Objection
(Brian Haberman)
(Gonzalo Camarillo)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Wesley Eddy)
Note: This ballot was opened for revision 01 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
Benoît Claise Former IESG member
Yes
Yes
(2012-05-09)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Russ Housley Former IESG member
Yes
Yes
(2012-05-06)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2012-05-08)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2012-05-02)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown