Reviewer: Abdussalam Baryun (AB) I-D name: draft-ietf-mpls-tp-rosetta-stone-12 Date: 17.10.2013 Reply to IETF LC message dated 02.10.2013 +++++++++++++++++++++++++++++++++ Overall Review: The reviewer decision is that the I-D is not ready to be publish because it does not achieve clearly its aim and objectives and subject to additional information and structure. This thesaurus is difficult to trace and gather information related to MPLS, even though it is informational draft. This draft's terminology section is not done in a methodology similar to RFC4397 in terms of showing separate resources in each subsection and relating to the document aim. The title seems like the terminology of both documentations are made as thesaurus, but when we go into the I-D the reviewer feels it is not organised as a thesaurus to simplify search and relating terms or issues of MPLS-TP. There are many terminology not clear but more general definition. I prefer specific defining to clarify to ALL Internet-Community not only specific readers (otherwise should mention that it is not for ALL community to understand). Also many times refers to references to define without mentioning what was that definition, is that defined only in ITU? is there an agreement that some one defines parts and other org defines other parts? why IETF draft cannot define its technology developed MPLS-TP? or is this draft agreeing on a joint definitions of many documents without clear methodology or IETF is just following ITU in some terms? The answers to these questions are very important to make the thesaurus easy to trace. Draft methodology of definition and terminology: The way the draft starts a definition should not be refering to a reference, this makes the reader leave the document and distracted, and does not know where to go which page in such reference. In ITU-T documents we find more organised which it defines and then refers to the location of such definition but not the page which the reviewer prefers in such situation. Therefore, it is better for an IETF partcipant to understand the context and even get thesaurus-of-terms when going through the some ITU-T documents (e.g. ITU-T G.8101/Y1355 (10/12) ) better than this ietf-draft, which means the IESG needs to compare between this draft and ITU-T way of representing terms and defining them, to make a better draft representation facing other organisations, otherwise, people stop using this draft in future. AB>Question to authors> Who is the reader: is this document only designed for IETF familiar RFCs readers or if someone from ITU refered by one document wants to read this doc could he/she understand? (please note that ITU does refer people to this draft as this draft is defining some terms and they acknowledge). In the reviewer's opinion it should mention this issue or who can read or what are the documents that should be read, because it was mentioned that this I-D is for IETF to get the ITU context. I-D> Scope and Applicability: ++++++++++++++++++++ AB> The scope is not clear because in the draft says:- I-D>page 2> in Abstract> This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. I-D>page 4> in Introduction> This document provides a thesaurus for the interpretation of ITU-T Transport Network terminology within the context of the MPLS-TP. I-D>page 17> Section 4> As discussed in the introduction to this document, this thesaurus is intended to bring the concepts and terms associated with MPLS-TP into the context of the ITU-T’s Transport Network architecture. AB> The above objectives are not consistent scoped or not explained how and which context and terms are related and interpreted. The methodology of doing both is not clear, or even how they relate within the draft. The reviewer thinks there may be an editorial mistake, but still the scope was confused by that because terms were referenced to both RFCs and ITU-Gs. AB> suggest adding> The motivation of the scope is nice to mention as done in RFC4397. However, it is easier to write scope/motivation of RFC4397 but not this draft because we want our participants to be familiar with other organisation's documents or concepts. I hope we don't loose our participants to go work for ITU and stop participating in our IETF :-) I-D> page 4> This document provides a thesaurus for the interpretation of ITU-T Transport Network terminology within the context of the MPLS-TP. This allows MPLS-TP documents to be generally understood by those familiar with MPLS RFCs. AB>not clear why it allows understanding> the reviewer thinks that the draft's thesaurus does show pointers to ITU documents but does not deliver the specific definitions of thoes terminologies within the ITU nor within Transport Network context. AB> to strengthen the scope of the draft to make both ITU and IETF participant work on similar terminologies> Add info: In past ITU-T developed extensions to MPLS developed by IETF to address the requirements of the transport network (T-MPLS). However, concerns were raised by the IETF that the approach taken by the ITU-T was incompatible with widely deployed - MPLS - technology. Now both ITU and IETF have work together to set a next generation transport network technologies compatible with MPLS-TP. AB> Question> Is there a discussion with the ITU Group responsible about defining terms, because in one document of theirs they mention something like some terms listed defined by IETF and some listed defined by ITU-T? (yes it is mentioned in acknowledgement about ITU and designe team, but not reflected or shown in the document scope). Why is there different in concepts between MPLS-TP and the ITU Transport Network, if the MPLS-TP was developed to facilitate technologies within ITU transport Network context? AB> Questions> Are the ITU documents under normative referencing the last documents as up to date? and what are the affects of amendment of ITU documents are they like our RFCs. Therefore, the reviewer request all normative to be in force documents and including any amendments if related to this I-D. AB> suggest> Some documents of amendments are related but not referenced, such as amendments to ITU-T G.8101/Y1355 as [ITU-T G.8101/Y1355 (10/12)] in 2012. Please consider adding and refering to it. I-D> Introduction Section> +++++++++++++++++++ I-D>Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been developed by the IETF to facilitate the Operation, Administration and Management of Label Switched Paths (LSPs) in a Transport Network environment as defined by the ITU-T. AB> the MPLS-TP is defined by IETF not by ITU-T, so prefer to make it clear in the paragraph. It can be understood: the IETF developed it as defined by ITU-T. AB> amend to: Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been developed and defined by the IETF to facilitate the Operation, Administration and Management of Label Switched Paths (LSPs) for interoperability in a Transport Network environment as defined by the ITU-T. AB> please add> MPLS-TP is a connection-oriented packet-switched transport layer network technology, is a profile of the MPLS that supports deployment in transport networks and allows operations in a manner consistent with other transport technologies. AB> add> please mention that this definition of MPLS-TP by IETF will allow consistent with other transport technologies defined by ITU-T. AB>In Section 1.2> please explain or add info: In the document there are many abbreviations as CC, CE, ME, etc., but not mentioned if these abbreviations are used in ITU-T as a common abbreviation or are not, the IETF participant would like to know such information in this thesaurus. Also the section prefered to say this is the documents abbreviation (e.g. wondering why some have abbrv and others have not within the thesaurus). Why authors used CC why not CCh as in other RFC? or does the CC has been used in the ITU? please clarify why. AB> suggest> CC to be changed to MPLS-TP Comm Channel (MTCC) and also all others related terms. AB> some words are not clear related to terminologies and MPLS and ITU concepts. As there are words not defined but abbreviated as: Network Element (NE). Other words not defined as : Channel, path, point, connection, .etc. The reviewer wants to know it under the context of MPLS-TP and Transport Network concept as the draft aims to do but not found by reviewer. In ITU documents in abbreviation section, it mentions as this recommendation abbreviation, this draft needs to mention that this is its abbreviation as well. Please refer to below editor abbreviation in section 2: http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt The draft makes in its first page an abbreviation of IETF even though it is mentioned in the webpage above of RFC editor. AB>no consistency> The ITU-T has no abbreviation but still document mentions the IETF abbreviation while the IETF is our organisation and ITU is not and both are in RFC editor as no need abbreviation. Also MPLS is similar abbreviated in the document and the editor signals it as known, but in document mentioned more than one time. The ITU documents mentions the ITU abbreviation. I-D>Page 1> Internet-Drafts are working documents of the Internet Engineering Task Force (IETF) AB> the document uses the word * see * to refer to document that has the definition, but not refers to pages that has the definition. I prefer not to refer, because this is a thesaurus so it is better to explain with words and refer in the end of sentence as for example pointing page in ref as [ITU-T_G.806, p4]. I-D> Section 2> Terminology: ++++++++++++++++++++ AB>Discuss> Section 2 needs an introduction, the reader does not know what is the document terminology, we have two organisations IETF and ITU, two sources of terminology and concepts that this document is considering but it seems that is not clear mentioned in the section in details. For example, Is the terms in the thesaurus taken from ITU documents or from IETF? or both? and then are they defined in the context of ITU-T or of Transport Network? AB> the sections 2.1 and 2.2 has references that are repeated in 2-3 which is confusing because it was thought that these sections show distinction where references are for MPLS-TP terms and others for ITU and others references having common terms. Please clarify and rephrase. I-D>Section 3> Thesaurus: ++++++++++++++++++ AB>The section needs an introduction to explain these terms and their relationships, I get confused when I see a thesaurus terms without good relationship based on a model or methodology. It seems that the draft is more referencing where are definitions than giving a clear thesaurus and guidance/interpretation. The concept of Transport Network should be defined, and also the MPLS-TP concept. The Network Elements are defined in ITU with deep specification but in this draft seems general, also in ITU-T it related NE as in concept MPLS-TP Network Element (MT.NE), why this is not reflected in this draft. This I-D's name is mentioned in the reference [ITU-T G.8101/Y1355 (10/12)], and that ITU reference is not mentioned in this I-D, why. The [ITU-T G.8101/Y1355 (10/12)] explains better than this I-D that there are definitions defined in this I-D and there are definition defined by ITU documents and they list them all. Why does this I-D not explain in similar clarifications to readers to distinguish and avoid conflict in understandnings. I-D> 3.1 Associated bidirectional path: AB>Question> how can a path defined as a path without mentioning its between what and through what? this is not specific definition, but general, or too general. I-D> 3.2 Bidirectional path: AB>Question> how can a path defined as a path without mentioning its between what and through what? this is not specific definition, but general, or too general. How does it differ from the 3.1 definition? I-D> 3.3 Client layer network: AB> it is a network but not defined under the MPLS-TP concept, to show what is these layers or layer-network, and not distinguished from the server layer network, please clarify. I-D> 3.4 Communication Channel AB> what is this channel? it cannot be defined as a path, as you say between NEs, the reviewer thinks a channel is bandwidth of the communication path. You must relate the channel to the path or paths and connections, etc. This section is very poor in information delivering. I-D>3.6 Control Plane: AB> not defined, and the reviewer though we are looking into MPLS-TP under ITU-T context not the scope of RFC5654, please rephrase. AB> In general> The above are examples of confusion not all confusions. In the opinion of the reviewer that the definitions and thesaurus is week represented to easily find the specific definition related to draft objectives. ****Nits***** AB> Question> the I-D uses words differently *end point* and *endpoint* why? please amend to consistentancy. Relate it in the draft interpretation to *connection point*, and/or NEs. I-D> customer’s (individual or bundled) AB> amend to : customer’s (i.e. individual or bundled) AB> RFC3031 wrong title and not complete authors>amend reference in sec 9.1 to: [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label Switching Architecture", January, 2000. AB> RFC5654 not complete authors>amend reference in sec 9.1 to: [RFC5645] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and Ueno, S., "Requirements of an MPLS Transport Profile", September, 2009. AB> RFC5860 not in order authors and title not same>amend reference in sec 9.1 to: [RFC5860] Vigoureux, M., Ward, D., and Betts, M., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", May, 2010. AB> RFC5860 not complete authors>amend reference in sec 9.1 to: [RFC5921] Bocci, M., Frost, D., Bryant, S., Levrau, L., and Berger, L., "A Framework for MPLS in Transport Networks", July, 2010. AB> RFC5951 not complete authors and wrong title>amend reference in sec 9.1 to: [RFC5951] Lam, K., Gray, E., and Mansfield, S., "Network Management Requirements for MPLS-based Transport Networks", September 2010. ++++++++++ The End ++++++++++ Sorry for the delay, Best Regards AB On 10/2/13, The IESG <iesg-secretary@xxxxxxxx> wrote: > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'A Thesaurus for the Terminology used in Multiprotocol Label Switching > Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport > Network Recommendations.' > <draft-ietf-mpls-tp-rosetta-stone-12.txt> as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2013-10-16. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > MPLS-TP is based on a profile of the MPLS and PW procedures as > specified in the MPLS-TE and (MS-)PW architectures developed by the > IETF. The ITU-T has specified a Transport Network architecture. > > This document provides a thesaurus for the interpretation of MPLS-TP > terminology within the context of the ITU-T Transport Network > recommendations. > > It is important to note that MPLS-TP is applicable in a wider set of > contexts than just Transport Networks. The definitions presented in > this document do not provide exclusive nor complete interpretations > of MPLS-TP concepts. This document simply allows the MPLS-TP terms > to be applied within the Transport Network context. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone/ballot/ > > > No IPR declarations have been submitted directly on this I-D. >