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