Ben,
Apologies for missing your additional questions. Please see below for a
response.
Best regards,
Matthew
From: Ben Campbell <ben(_at_)nostrum(_dot_)com>
To: "Bocci, Matthew (Matthew)"
<matthew(_dot_)bocci(_at_)alcatel-lucent(_dot_)com>
Reply-to: ben(_at_)nostrum(_dot_)com
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02
X-RSN: 1/0/933/9723/54927
Thanks for the quick response. Also see below. I elided sections that I
think have been addressed.
On Dec 22, 2010, at 5:44 AM, Bocci, Matthew (Matthew) wrote:
Ben,
Thank you for your comments. Please see below.
Best regards
Matthew
On 21/12/2010 22:13, "Ben Campbell" <ben(_at_)nostrum(_dot_)com> wrote:
[...]
-- Section 1.1, 1st paragraph:
More conventional in what context? Useful for what purpose?
It is the convention to represent a UNI or NNI as a specific reference
point between functional groups e.g. MEF E-NNI (Figure 2 of MEF26) or
ATM
UNI (ITU-T I.413), rather than to represent these as a span as in the
original diagrams in RFC5921. I propose to rephrase this sentence to:
"However, it is convention to illustrate these interfaces as reference
points."
With regard to your second question, I propose to rephrase the sentence
as
follows:
"Furthermore, in the case of a UNI, it is useful to illustrate the
distribution of UNI functions between the Customer Edge (CE) side and
the
Provider Edge (PE) side of the UNI (the UNI-C and UNI-N) in order to
show
their relationship to one another."
WFM
-- Figures 1 and 2:
Is the meaning of the various line types described elsewhere? If so, a
statement to that effect with a reference would be helpful.
We have used the same convention as RFC5921. However, there is no key
there. I am not sure that a complete key would clarify the diagram as
the
same line type is used to represent multiple entities due to the limited
umber of characters that are useful for ASCII drawing.
Ah, I agree it probably would be too much to add a complete key, and on
re-reading, I see most of the lines are sufficiently labeled. But I am
still confused by a few of them. For example, in under the UNI column, I
see both a single and double dashed (equal signs) line under the label of
"Client Traffic Flows". Should I assume those to just be two arbitrary
flows where the line type just helps me follow a particular flow, or are
they somehow different classes of flows?
MB> They are just flows belonging to arbitrary transport service
instances, and helps the reader to follow the path of the flow.
On the right side of the same diagram, I see 3 Transport Paths with an
outer set of arrows, and the lower two having another arrow between.
Should the outer arrows be interpreted as a "channel" over which client
traffic flows?
MB> The outer arrows are supposed to look like two sides of a tunnel (the
transport path) other which the transport service instance (TSI) is
transported.
-- Figure 2:
I suggest expanding CP somewhere.
CP is expanded in the terminology section.
So it is, right there at the top. (I could have sworn I did a text search
for that--looks like the search option in the iPad tool I use for
reviewing drafts is not reliable :-|)
On 22/12/2010 11:44, "Bocci, Matthew (Matthew)"
<matthew(_dot_)bocci(_at_)alcatel-lucent(_dot_)com> wrote:
Ben,
Thank you for your comments. Please see below.
Best regards
Matthew
On 21/12/2010 22:13, "Ben Campbell" <ben(_at_)nostrum(_dot_)com> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you
may receive.
Document: draft-ietf-mpls-tp-uni-nni-02
Reviewer: Ben Campbell
Review Date: 2010-12-21
IETF LC End Date: 2010-12-23
IESG Telechat date: (if known)
Summary: This draft is ready for publication as in informational RFC. I
have a small number of editorial comments that I think could further
improve the draft if there is another round of editing.
Major issues: None
Minor issues: None
Nits/editorial comments:
-- Section 1, 1st paragraph:
I suggest moving the expansion of MPLS-TP TP the first mention in the
body of the draft.
OK. I have moved this to the first use of the acronym in that section.
-- Section 1.1, 1st paragraph:
More conventional in what context? Useful for what purpose?
It is the convention to represent a UNI or NNI as a specific reference
point between functional groups e.g. MEF E-NNI (Figure 2 of MEF26) or ATM
UNI (ITU-T I.413), rather than to represent these as a span as in the
original diagrams in RFC5921. I propose to rephrase this sentence to:
"However, it is convention to illustrate these interfaces as reference
points."
With regard to your second question, I propose to rephrase the sentence as
follows:
"Furthermore, in the case of a UNI, it is useful to illustrate the
distribution of UNI functions between the Customer Edge (CE) side and the
Provider Edge (PE) side of the UNI (the UNI-C and UNI-N) in order to show
their relationship to one another."
-- Section 1.2, definition of UNI-N
I suggest expanding PE in the definition.
OK
-- Figures 1 and 2:
Is the meaning of the various line types described elsewhere? If so, a
statement to that effect with a reference would be helpful.
We have used the same convention as RFC5921. However, there is no key
there. I am not sure that a complete key would clarify the diagram as the
same line type is used to represent multiple entities due to the limited
umber of characters that are useful for ASCII drawing.
-- Figure 2:
I suggest expanding CP somewhere.
CP is expanded in the terminology section.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf