Wireline Incremental IPv6
RFC 6782

Note: This ballot was opened for revision 05 and is now closed.

(Ron Bonica) Yes

(Ralph Droms) (was Discuss) No Objection

Comment (2012-09-11)
No email
send info
I've cleared my Discuss and Comments.  Thanks for addressing my issues.

Nit: in section 5.4, s/it's/its/

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-08-29 for -05)
No email
send info
I have no objection to the publication of this document.

Some small thoughts...

---

Section 2

      - The operator will want to minimize the level of disruption to
      the existing and new subscribers by minimizing the number of
      technologies and functions that are needed to mediate any given
      set of subscribers flows (overall preference for Native IP flows)

I can believe that "The operator will want to minimize the level of 
disruption to the existing and new subscribers" and I can believe that
the operator will want to minimize "the number of technologies and 
functions that are needed to mediate any given set of subscribers flows"
but I don't see the linkage between these two points. It does not follow
to me that reducing the number of technologies necessarily reduces the
disruption: indeed it could be the reverse. How about making these two
issues into separate assumptions?

---
                                            
Section 3 (petty nit)

   When faced with the challenges described in the introduction,
   operators may need to consider a phased approach when adding IPv6 to
   an existing subscriber base.

s/need/want/

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

Comment (2012-08-28 for -05)
No email
send info
I have no problems with the publication of this document, but have a few non-blocking comments/questions...

1. I was surprised to not find any mention of an analysis of hardware capabilities in the Phase 0 discussion in Section 5.  It seems to me like it would be useful to have a good understanding of what capabilities key devices have in my network.  It would have a direct impact on an IPv6 roll-out plan if a software or hardware upgrade would be needed.

2. The order of transition technologies in section 4 seemed haphazard.  It may be cleaner to group the technologies (e.g., early IPv6 deployment, IPv4 life support mechanisms, etc.).

3. Was any consideration given to including a discussion on the potential impact of IPv6 on the overall network architecture?  For example, what if I wanted to use SLAAC + stateless DHCPv6 to configure my hosts?  I may want to consider topology changes from my current IPv4 architecture to increase reachability to DHCPv6 servers.

(Russ Housley) No Objection

Comment (2012-08-29 for -05)
No email
send info
  Please consider the editorial comments from the Gen-ART Review by
  Pete McCann on 27-Aug-2012.  You can find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07716.html

Barry Leiba No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection