Ben, Apologies for missing your additional questions. Please see below for a response. Best regards, Matthew From: Ben Campbell <ben@xxxxxxxxxxx> To: "Bocci, Matthew (Matthew)" <matthew.bocci@xxxxxxxxxxxxxxxxxx> Reply-to: ben@xxxxxxxxxxx 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@xxxxxxxxxxx> 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.bocci@xxxxxxxxxxxxxxxxxx> wrote: >Ben, > >Thank you for your comments. Please see below. > >Best regards > >Matthew > >On 21/12/2010 22:13, "Ben Campbell" <ben@xxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf