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.
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.
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."
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 :-)
Thanks,
Spencer
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
