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:
On Sunday, October 27, 2013, Adrian Farrel wrote:
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
> d