Subject: RE: Last Call: <draft-ietf-mpls-tp-rosetta-stone-12.txt> (A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.) to Informational RFC

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 27 Oct 2013 12:37:54 -0000

Herewith a late response to your review comments.

> 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. 

The objective is quoted in the Abstract as:

   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.

I think the aim of "providing a thesaurus" *is* achieved by the document.
You have some suggestions below that can be considered, but the "not ready to be
publish" is an extreme reaction.

> This thesaurus is difficult
> to trace and gather information related to MPLS, even though it is
> informational draft. 

I wonder if you are using the document in the wrong way. You are supposed to use
this to look up terms, not educate yourself on MPLS.

> 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.

That is correct. 
But saying "I would not have done it like this" is not very helpful.
4397 presented material in a different way and for a different purpose.

> 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.

Right, the title could be changed to match the quote from the Abstract that I
gave above. Thus:

OLD
        A Thesaurus for the Terminology used in Multiprotocol Label
       Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's
                    Transport Network Recommendations.
NEW
        A Thesaurus for the Interpretation of Terminology used in 
  Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs
     in the Context of the ITU-T's Transport Network Recommendations
END

> There are many terminology not clear but more general definition.

That is not actionable as it stands, but I presume that the "many" are all in
your more detailed comments below.

> 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). 

All RFCs are for ALL, but can often only be understood in the context of wider
reading.
This document is a thesaurus for people to look things up. It is not something
you read and use to get an understanding of MPLS-TP.

> 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.

The paragraphs I quoted from the Abstract explains this.
The purpose is to be able to look up a term found in an MPLS-TP draft/RFC and
understand it in the context of the ITU-T Recommendations. Thus, often, it is
sufficient to say something like:
   See also [RFC6371] section 3.1 and [ITU-T G.8113.1],
   [ITU-T G.8113.2] clause 6.1.
I repeat: the purpose is not to explain the details of MPLS-TP. For that you
must read a large set of RFCs.

> 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.

Again, this misunderstands the purpose of the document. 
You cannot expect a 20 page document to explain MPLS-TP to you. For that, you
must read either the set of MPLS RFCs or the set of ITU-T Recommendations.
What this document does is help a reader who already knows the ITU-T
Recommendations to read and understand the MPLS-TP RFCs.

> 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).

No change from what I have already said.

> 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.

The paragraphs quoted from the Abstract makes this implicitly clear.

> 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.

The authors fixed this in -13

> 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 think you have still missed the point as stated in the quote from the
Abstract.

We are happy for people to do work in the appropriate standards bodies.

> 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.

Fixed in -13

> 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.

This may or may not be a true statement, but I don't see the value of including
it in this document. It is far better to present a document for what it is and
leave the politics outside the door if at all possible.

> 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?

There is nothing that can be done in an IETF document to make any changes to the
way the rest of the world operates and thinks. This document does its best by
enabling a translation between those worlds.

Various people from within the ITU-T reviewed this document in an attempt to
ensure it is correct. That was both helpful and diligent.

If you want to understand or influence the way the ITU-T works, you need to go
there and talk with them.

> 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.

The authors have cited the correct versions of the documents for the references
they needed to make.

If you wish to understand the ITU-T documentation process, you need to go to the
ITU-T not the IETF.

> 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.

The citations are made to the documents that define the terms or contain the
text that is referenced.

> 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.

The sentence is very clear, IMHO:
- MPLS-TP developed in IETF
- MPLS-TP facilitates LSPs in an environment defined by the ITU-T

While it is clear that the paragraph could be understood in a number of ways, I
do not believe that a misunderstanding can be easily achieved.

> 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.

You added "and defined". That is a superfluous duplication of "developed".

You added "for interoperability". Since you don't say "interoperable with what"
I think this only clouds the text and adds no meaning.

> 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.

For what purpose?
Not every document has to include a base definition of everything it mentions.

> AB> add> please mention that this definition of MPLS-TP by IETF will
> allow consistent with other transport technologies defined by ITU-T.

Something like...
   This document provides a thesaurus for the interpretation of MPLS-TP
   terminology within the context of the ITU-T Transport Network
   Recommendations.

Oh, that text is already there.

> 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).

The intention is not to explain the terms used in ITU-T Recommendations. That is
out of scope.

> Why authors used CC why not CCh as in other RFC? or does the CC has
> been used in the ITU? please clarify why.

-13 has tidied this up

> AB> suggest> CC to be changed to MPLS-TP Comm Channel (MTCC) and also
> all others related terms.

That would be inventing a new term.

> 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.

Again, you are not expected to read this document and magically understand all
of networking.

You are supposed to read this document if you want to understand MPLS-TP terms
in the context of ITU-T Recommendations. That implies that you possibly have
some understanding of those Recommendations.

> In ITU documents in abbreviation section, it mentions as this
> recommendation abbreviation, this draft needs to mention that this is
> its abbreviation as well.

I don't understand.
You want, "....network element (NE)..." to have some additional indication that
"NE" is an abbreviation that means "network element"? 
And the inclusion in section 1.2 "Abbreviations" of a line that says "NE
Network Element" is not enough?

> Please refer to below editor abbreviation in section 2:
> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

Yes. You will notice that this I-D conforms to the guidance and this list of
abbreviations.

> The draft makes in its first page an abbreviation of IETF even though
> it is mentioned in the webpage above of RFC editor.

Golly, yes, so it does.
Of course, you leave me to guess which abbreviation you are referring to which
is immensely frustrating for me.

I think we can leave it to the RFC Editor to worry about this sort of nit.

> 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)

This is standard boilerplate and required to be present in exactly this format.
Have you not noticed it on every other document you have read?

The rule says what you do not need to expand, not what you must not expand.

> 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].

It is common practice to not include the page number since electronic and
searchable documents were first made available.

> 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?

You did not suggest what the introduction should say, and I don't see the need
for an introduction. True, I don't like to see empty sections like this, but I
don't think it is important or makes the document any harder to read.
 
> 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.

Nope, the distinction is by category not by reference. The references show where
the terms in any one category are found.

> 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.

Right, you got it.
The draft is not about explaining the terms, it is about giving enough
information to make it possible to understand the terms. That is largely by
reference.

> The concept of Transport Network should be defined, and also the
> MPLS-TP concept.

Why should the MPLS-TP concept be defined. Does it have a different meaning in
IETF and ITU-T? Is it not already defined well in the RFCs that the reader of
this document will be trying to interpret? 3.25 gives a base anchor, the rest is
safely assumed or additionally described in this document.

You think the concept of Transport Network should be described better than it is
in section 3.44?

> 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.

I think you are trying to map in the wrong direction again. This document is for
understanding the terms already in use in IETF draft/RFCs in the context of
ITU-T Recommendations.

>> 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.

Hmmm. I don't think this document needs to mention every document that mentions
it.

> 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.

This document does not define things. It provides a thesaurus for the
interpretation of MPLS-TP terminology within the context of the ITU-T Transport
Network Recommendations.

> 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.

The text in 3.1 looks right to me.
Maybe you are asking for an explanation of "path" to be added to the document. 
Ah, but wait. 3.32 is "Path"
I think you needed to read the whole document before typing comments (or at
least use a search).

> 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.

Answer as for 3.1

> How does it differ from the 3.1 definition?

You can see that yourself from the text.
A bidirectional path is a much less specific term than an associated
bidirectional path.

> 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.

You misunderstand the purpose of this document.
If you come across the term "client network" in an MPLS-TP document in the IETF,
this entry tells you how to interpret the term in the context of the ITU-T
Recommendations.

> 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.

The reviewer is wrong.
As the text says, it is a logical channel.
It is not necessarily related to paths.
This document is not intended to explain networking from the ground up to its
readership.

> 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.

The reviewer is still confused about the purpose of the document.
The text explains where the term arises in the MPLS-TP documents. Since "control
plan" is a very wide term in the IETF, it is appropriate to give the scoping
context within MPLS-TP.

> 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.

Yes. That is because it is not intended to provide definitions.
In general, no-one is going to be able to fix text that you only point to in
general.
Judging that the items above gave rise to just two very small changes to the
text, it is not worthwhile for the authors to revisit the text hoping to find
more issues like those above.

> ****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.

Fixed in -13

> I-D> customer's (individual or bundled)
> AB> amend to : customer's (i.e. individual or bundled)

Rejected as incorrect meaning.

> 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.

All issues with references fixed in -13 (although this is stuff the RFC Editor
reworks anyway)

Fixed in -13

> 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.

Fixed (to say RFC5654) in -13

> 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.

Fixed in -13

> 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.

Fixed (well, fixed the ref for 5921) in -13

> 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.

Fixed in -13

Adrian
(Many people have been wondering how ADs spend their time)

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 27 Oct 2013 21:12:56 +0000

I think authors/you did not reply to all my review dated 17 October, and
the new version 13 of the draft is dated 20 October before replying to my
review on the list. The last call was for version 12 and the authors found
my review to help to update fix without replying to the review with the
community.  I recommend always reply before submitting new drafts after LC.
I will not reply/discuss because I feel discouraged by authors.

The reply saying fixed but not mentioned that my review result was before
the discovery to fix, it seems like the reply is saying we fixed it before
you reviewed or discovered the nits.

AB

On Sunday, October 27, 2013, Adrian Farrel wrote:

> > d

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 27 Oct 2013 21:30:56 -0000

> I think authors/you did not reply to all my review dated 17 October,

Really?
If you look carefully you will find that I replied at considerable length to
every point you made in your lengthy review.

> and the new version 13 of the draft is dated 20 October
> before replying to my review on the list. 

Sure. And why not?
The authors saw your comments and updated the document. What more could you
possibly want?

> The last call was for version 12 and the authors found
> my review to help to update fix without replying to the
> review with the community.

Right.
How wonderful for you that your comments were adopted by the authors.

> I recommend always reply before submitting new drafts
> after LC. 

An interesting recommendation that people may take at face value.

> I will not reply/discuss because I feel discouraged by authors.

That is entirely your choice.
I don't know that I could say anything that would not discourage you further.

> The reply saying fixed but not mentioned that my review
> result was before the discovery to fix,

Frankly, I don't care about that. Your objective was to get the document
changed. The document was changed. You should be happy.

> it seems like the reply is saying we fixed it before you reviewed
> or discovered the nits.

I understand that that is how it seems to you.
But it doesn't say that.
I would positively die of boredom if every time I typed (to anyone) "fixed in
version -xx" I had to type "this has been fixed in version -xx, as a result of
your careful and most excellent review."

Some of us don't have the luxury to be discouraged by our email exchanges. Some
of us have the joy to be an AD and type long and painful responses to emails.
Some of us don't get a note saying "Thank you for responding to my review and
updating the document to take into account my comments."

I really must say that none of this is cultural or related to remote
participation. It is frankly annoying.

Adrian