Skip to main content

Wireline Incremental IPv6
draft-ietf-v6ops-wireline-incremental-ipv6-06

Yes

(Ron Bonica)

No Objection

(Barry Leiba)
(Robert Sparks)
(Sean Turner)
(Stephen Farrell)
(Wesley Eddy)

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

Ron Bonica Former IESG member
Yes
Yes (for -05) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-08-29 for -05) Unknown
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/
Barry Leiba Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2012-08-28 for -05) Unknown
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.
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2012-09-11) Unknown
I've cleared my Discuss and Comments.  Thanks for addressing my issues.

Nit: in section 5.4, s/it's/its/
Robert Sparks Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2012-08-29 for -05) Unknown
  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
Sean Turner Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -05) Unknown