Skip to main content

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
Reference
   [BCP38UPD]      F. Baker, P. Savola "Ingress Filtering for
                   Multihomed Networks"
                   Work in progress
Should be updated to point to RFC 3704 (BCP84)
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.