Re: Gen-ART LC Review of draft-ietf-v6ops-6to4-to-historic-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ben,

splendid comments! I've tried to incorporate all of them, and will either issue a new revision or make the changes during AUTH48 depending on other LC feedback.

cheers,
Ole

> 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-v6ops-6to4-to-historic-04
> Reviewer: Ben Campbell
> Review Date: 2011-06-17
> IETF LC End Date: 2011-06-20
> IESG Telechat date: 2011-06-23
> 
> Summary:
> 
> The draft is essentially ready for publication as an informational RFC. I have a few editorial comments that may be worth considering prior to final publication.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> -- general: 
> 
> Idnits reports some potential issues. please check.
> 
> -- abstract:
> 
> The headers say this draft obsoletes these RFCs. Does moving to historical obsolete then in that sense? Perhaps the abstract should say something like "obsoletes, and moves to historical"
> 
> -- section 1, 2nd paragraph: "...designed to help transitioning the Internet..."
> 
> Help transition, help in transitioning, or help the transition of
> 
> -- section 1, last paragraph:
> 
> Please expand 6rd on first mention. Also, Is this meant as an explicit recommendation of 6rd as an alternative?
> 
> -- section 3, third paragraph: "...same operational burden has manually configured tunnels..."
> 
> s/has/as
> 
> -- section 3, first bullet: "... and in the case the relay is overloaded packet loss."
> 
> "overloaded, packet loss."
> 
> -- section 3, third bullet: "...customer relationship or..."
> 
> "... customer relationship between the end-user and the relay operator, or..."
> 
> -- section 3, 4th bullet: "In case of the reverse path 6to4 relay and the anycast forward 6to4 relay, these have to be open for any address. Only limited by the scope of the routing advertisement. "
> 
> Awkward sentence followed by a sentence fragment. Can these be reworded?
> 
> -- section 3, 5th bullet: "black hole"
> 
> Please define "black hole" in this context, or use a more descriptive (I.e. less jargony) term.
> 
> 
> -- section 4, 2nd paragraph: "It is expected that disabling 6to4 in the IPv6 Internet will take some time."
> 
> Who expects it? The IETF? v6ops? The authors? (or can we just drop "It is expected that")
> 
> "...deploy native IPv6 service."
> 
> s/service/services
> 
> -- section 4, numbered list:
> 
> It's not clear to me why this is a numbered list rather than an ordinary paragraph
> 

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]