Hi, Brian,

I would say "good to go" on this draft, with the editorial changes I
have discussed with Carlos.

Thanks,

Spencer

On 9/25/06, Carlos Pignataro <cpignata@cisco.com> wrote:
> 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
> Gen-art@ietf.org
> https://www1.ietf.org/mailman/listinfo/gen-art
>

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art