A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations
draft-ietf-mpls-tp-rosetta-stone-13

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

(Adrian Farrel; former steering group member) Yes

Yes ()
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2013-10-21)
No email
send info
The well done shepherd writeup clearly tells us that this document has been widely reviewed and is widely seen as a useful tool.  Given that and a quick breeze through it, I see nothing that I might even consider objecting to.

(Benoît Claise; former steering group member) No Objection

No Objection (2013-10-24)
No email
send info
Section 1.1 "contributing authors" should be called "Contributors" section.
See http://www.ietf.org/proceedings/62/slides/editor-0.pdf, slide 37
Let's not invent a new term.

OAM stands for "Operations, Administration and Maintenance"
Section 1 mentions "Operation, Administration and Management". Please correct this.

(Brian Haberman; former steering group member) No Objection

No Objection ()
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ()
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection (2013-10-22)
No email
send info
looks good. earlier reviews I've seen raise no red flags after the recent edit.

(Martin Stiemerling; former steering group member) No Objection

No Objection ()
No email
send info

(Richard Barnes; former steering group member) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection ()
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection (2013-10-22)
No email
send info
I would be a "Yes" if I understood the technology better. This is very good, and very helpful. I wish I'd had a doc like this as a Gen-ART reviewer.

I did have a couple of questions you might want to consider, along with any other comments you receive during IESG evaluation.

In section 1.1 Contributing Authors

   Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven
   Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci,

                         ^ this isn't Stewart Bryant, is it? :-)

   Vincenzo Sestito, Vigoureux, Yaacov Weingarten

In section 3.19 Maintenance Entity Group End Point (MEP):

   Maintenance Entity Group End Points (MEPs) are the end points of a
   pre-configured (through the management or control planes) ME.  MEPs
   are responsible for activating and controlling all of the OAM
   functionality for the ME. A source MEP may initiate an OAM packet to
   be transferred to its corresponding peer or sink MEP, or to an
   intermediate MIP that is part of the ME. See also [RFC6371] section
   3.3 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3.

Are "peer" and "sink" being used as synonyms? Is that normal optical terminology? in which case, tell me "yes" ...

(Stephen Farrell; former steering group member) No Objection

No Objection ()
No email
send info

(Stewart Bryant; former steering group member) Recuse

Recuse ()
No email
send info