I am the assigned Gen-ART reviewer for
this document. For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please consider these comments along with any other Last Call comments
you may receive, and ask your AD for advice on how to deal with them.
Document: draft-ietf-l3vpn-bgpvpn-auto-07
Reviewer: Harald Alvestrand
Date: August 9, 2006
Summary: Ready, a few nits
This document makes me believe that someone who is expert in BGP and
VPNs would understand it. I don't claim to understand it in detail, but
what I do understand looks reasonable.
A few nits...
The "updates" section in the abstract is not marked "delete this when it
becomes an RFC".
A terminology issue: The abstract and introduction uses the term "VPN
member", which looks like it means something that is a member of a VPN.
However, closer investigation reveals that the term means "VPN which is
a member of <I'm not sure what>".
In particular, the sentence "the remote PEs will then identify the list
of VPN members they have in common with the advertising PE" is hard to
parse.
Consider using the term "member VPN" or simply "VPN" instead.
Tha IANA section actually doesn't say that IANA should assign these
values - it just mentions the things that IANA should assign. The
section will require rewriting to make sense when values are assigned
and the RFC is published - consider using the format
IANA has assigned extended community <TBD by IANA> used for Topology
values for VR-based
L3VPN solution
which makes it easier for the RFC Editor to make this section readable.
Otherwise, looks good to me.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
