Scenarios and Analysis for Introducing IPv6 into ISP Networks
draft-ietf-v6ops-isp-scenarios-analysis-03
Yes
(David Kessens)
No Objection
(Allison Mankin)
(Margaret Cullen)
(Scott Hollenbeck)
(Ted Hardie)
Note: This ballot was opened for revision 03 and is now closed.
David Kessens Former IESG member
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
(2004-05-27)
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2004-05-26)
Unknown
Reviewed by Mark Allman, Gen-ART This document is mostly fine to publish as an informational RFC. + It could really use a pass to get rid of alot of "this", "these" and "its". In some places it is very confusing what the author is actually referring to. + More references to various bits of the technology would be nice (e.g., to Teredo (among others); although maybe I just missed this one). + Some statements could be shored up a bit. E.g., on page 10 it is noted that "RIPng is not appropriate in most contexts". It'd be nice if there was a small bit of explanation or a reference here. The document doesn't hurt. I am not sure how much I thought it would help -- everything seems pretty straightforward. And, it is not clear that this is really an "experience" piece. That said, there is some decent stuff in here, too.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2004-05-26)
Unknown
In section 1.1: s/present document/document/ Please expand "IX", "DS", and "ACLs" the first time they are used. I do not understand the dotted line between the Network and Service Operation box and the Customer Connection 1 box on Figure 1. There is no discussion that provides insight. There is also no discussion of the Peering postion of the figure. In section 4.1.1: s/1) and 2)/Approaches 1) and 2)/ s/However, 1)/However, approach 1)/ s/2) may not be possible/Approach 2) may not be possible/ s/equivalent to 4)/equivalent to approach 4)/ In section 4.3: s/IPv4 or IPv6 only/IPv4- or IPv6-only/ In section 5.2: s/Radius traffic/RADIUS traffic/ An informational reference for RADIUS is needed.
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Steven Bellovin Former IESG member
(was Discuss)
No Objection
No Objection
(2004-05-25)
Unknown
The document doesn't discuss provisioning at all. I'm willing to be told that that's out of scope, but billing and accounting are mentioned. More generally, all of these are operations support systems, and most of these tend to have v4-specific assumptions built in. The relative scarcity of v6-capable firewalls is an obstacle to many managed services.
Ted Hardie Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Thomas Narten Former IESG member
(was Discuss, No Objection, Discuss)
No Objection
No Objection
(2004-05-27)
Unknown
> Large end sites are usually running managed network. doesn't parse. > Even though the RIR policies on getting IPv6 prefixes require the > assignment of at least 200 /48 prefixes to the customers, this type > of transit provider obtains an allocation nonetheless, as the number > of customers their customers serve is significant. The whole backbone This isn't entirely true, and has been changing. Best not to include details of the RIR requirement, since its not critical to this document.