Hi Spencer, Thanks again, please see inline.
On 9/25/2006 2:59 PM, Spencer Dawkins allegedly said the following: > Hi, Carlos, > > Thanks for the quick feedback. I think we can finish this up today. > > Please see inline. > > Spencer > > >> Spencer, >> >> Thank you for your review and comments. Please see inline. >> >> On 9/22/2006 3:37 PM, Spencer Dawkins allegedly said the following: >>> I have been selected as the General Area Review Team (Gen-ART) reviewer >>> for >>> this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> >>> Please resolve these comments along with any other Last Call comments you >>> may receive. >>> >>> Document: draft-ietf-mpls-over-l2tpv3-01.txt >>> Reviewer: Spencer Dawkins >>> Review Date: 2006-09-22 >>> IETF LC Date: 2006-10-04 >>> IESG Telechat date: >>> Summary: This draft is almost ready for publication as a Proposed >>> Standard. >>> >>> The optional L2-Specific-Sublayer defined in [RFC3931] is generally >>> >>> Spencer (editorial): I know this term is used in RFC 3931, but wish it >>> was >>> something like "-Sublayer header" or "-Sublayer bits", just for >>> readability. >> I'd like to use the [RFC3931] term, "L2-Specific Sublayer" (without the >> second dash). I'll ensure this is used consistently throughout the doc. > > This works for me. I wish "Sublayer" sounded more like a header field than > part of a protocol stack, but the community may already be accustomed to > this usage. OK. I see your point; but I believe that the common usage of the term carries an implicit "header" in its meaning though. > >>> not present for MPLS over L2TPv3. >>> >>> 4. Applicability >>> >>> MPLS over L2TPv3 may be favorable compared to [RFC4023], if: >>> >>> Spencer: I'm not sure what "may be favorable compared to" is saying. Is >>> this >>> "may have advantages compared to"? >> OK, "may be advantageous compared to" (was using favorable as synonym to >> advantageous, or having advantages). > > This is fine, and helps me to parse the next sentence. OK. > >>> Two routers are "adjacent" over an L2TPv3 tunnel that exists for >>> some reason outside the scope of this document, and those two >>> routers need to send MPLS packets over that adjacency. >>> >>> Spencer: I'm not sure what this sentence is saying, and can't parse it >>> well >>> enough to rephrase - sorry! >> It's trying to say that one advantage is when there is already a >> pre-existing L2TPv3 tunnel between two routers that can be used to send >> MPLS packets over it. > > OK, I think I understand now. Suggest "Two routers are already "adjacent" > over an L2TPv3 tunnel established for some other reason, and wish to > exchange MPLS packets over that adjacency." That works, thanks for the suggestion. > >>> 5.1 In the Absence of IPsec >>> >>> However, when the tunnel head and the tunnel tail are not in the same >>> administrative domain, this may become difficult, and filtering based >>> on the destination address can even become impossible if the packets >>> must traverse the public Internet. >>> >>> Spencer: I'm not sure I understand the point being made here. Why does >>> traversing the public internet make this impossible, if crossing >>> administrative domain boundaries makes it difficult? >> Note that a design consideration for this section is to be inline with >> RFC4023, so there is a desire to stay consistent in this sentence. See >> second para in http://ietf-tools.sth.netnod.se/html/rfc4023#section-8.2 > > I understand the design consideration (and see that the same paragraph > appears in RFC 4023), I was saying that the text didn't explain why > destination filtering was difficult/impossible. It may be that I'm the only > person who doesn't know why - in that case, the text is fine :-) > OK, will keep the text as is. Many thanks for your review ! --Carlos. > Thanks, > > Spencer > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
