Skip to main content

Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
draft-ietf-softwire-dual-stack-lite-11

Yes

(Jari Arkko)

No Objection

(Dan Romascanu)
(David Harrington)
(Pete Resnick)
(Peter Saint-Andre)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)

Recuse

(Ralph Droms)

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

Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2011-04-24) Unknown
Thanks for a fine and readble document.

Herewith, a few minor points you might like to look at to improve the document.

---

I was surprised that the following statements use a weak "MAY"

   The B4 element MAY use any other addresses within
   the 192.0.0.0/29 range.

   The AFTR MAY use the well-known IPv4 address 192.0.0.1 

"MAY" is usually used when there is some other more normal behavior, but
you don't say what that is.

---

7.2.  VPN

   Dual-stack lite implementations SHOULD NOT interfere with the
   functioning of IPv4 or IPv6 VPNs.

Seems a bit of an odd use of "SHOULD NOT". I'm not clear whether you
are commentng that "in your view the DS-Lite technology should not 
cause anything to break" or observing that it would be a broken 
implementation that *chose* to interfere with VPN function.

---

8.4.  Sharing global IPv4 addresses

   AFTR shares a single IP to multiple users.

s/to/address with/

---

8.5.  Port forwarding / keep alive

   Work on a control plane to the carrier-grade NAT is done in the PCP
   working group at IETF.  The PCP protocol enables 

What does the second 'P' in "PCP" stand for?
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Harrington Former IESG member
(was Discuss) No Objection
No Objection (2011-05-18) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (2011-04-26) Unknown
Consider adding a short discussion or perhaps an example of how services that sit on the Internet side of an AFTR (especially those in the same administrative domain of the AFTR) that need to know which B4 IPv4 traffic came through might get that information from the AFTR (perhaps using the information in the extended binding table described in section 6.6). Showing how a location query in a protocol like HELD (RFC5985) would be answered would be a good example.
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2011-04-22) Unknown
  Please consider the editorial comments from the Gen-ART Review by
  Roni Even on 9-Apr-2011.
Sean Turner Former IESG member
No Objection
No Objection (2011-04-26) Unknown
The reference for 1918 should be normative based on the following:

  However, it SHOULD operate its own DHCP(v4) server handing out
   [RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2011-04-26) Unknown
8.3: s/require ALG to work properly/require ALGs
to work properly/ (maybe) There are a few other English
language issues (mainly improper singluar/plurals).
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
(was Discuss) No Objection
No Objection (2011-05-17) Unknown

                            
Ralph Droms Former IESG member
Recuse
Recuse () Unknown