Skip to main content

The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
RFC 6670

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 steering group member) Yes

Yes ()

                            

(Benoît Claise; former steering group member) Yes

Yes (2012-05-09)
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

Yes ()

                            

(Ron Bonica; former steering group member) Yes

Yes ()

                            

(Russ Housley; former steering group member) Yes

Yes (2012-05-06)
  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

Yes ()

                            

(Stephen Farrell; former steering group member) Yes

Yes (2012-05-08)
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

Yes ()

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2012-05-02)
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

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Pete Resnick; former steering group member) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Wesley Eddy; former steering group member) No Objection

No Objection ()