Public IPv4-over-IPv6 Access Network
draft-ietf-softwire-public-4over6-10

[Ballot comment]
I am not convinced that it is wise for a WG to publish an Informational RFC describing a solution that has been deployed, but is not recommended for further deployment, ahead of that WG publishing the RFC that describes its recommended solution. However, I am persuaded that in this particular case in not harmful, and hence I abstain.

[Ballot discuss]
I have re-read the text and I still have some issues that I would like to discuss:

The text says:

"Public 4over6 was developed in
the IETF and is in use in some existing deployments, but is not
recommended for new deployments.  Future deployments of similar
scenarios should use Lightweight 4over6.  "

In other words: "we designed this and tried it in the field, but we do not recommend further deployment"

Why is this not documented as historic?

This was the approach taken with RFC5143 which was written in similar circumstances.

In my original discuss I stated:

"Additionally we normally insist that this relative status is reflected in the title and abstract, again to avoid any ambiguity on the matter."

I see that the abstract now reflects the status, but still not the title.

As originally noted it is better to have this sequenced behind the recommended protocol because as an informational there is a danger that readers will say "this informational seems to work and the ST RFC is not available so we might as well use this" thereby perpetuation a design that the IETF is deprecating.

By either publishing as Historic and/or sequencing publication the IETF's message to the reader not to deploy this is much clearer.

[Ballot comment]
What does it mean for the IETF to publish a WG consensus-based, Informational document that describes how some entity deployed a service?  Why is such a publication not being vectored to the ISE?  This is especially relevant given that this document essentially competes with an active softwire WG document (draft-ietf-softwire-unified-cpe) targeted for PS.

[Ballot comment]

title: it does seem like a good idea  to rename this
to be the "CNGI/CERNNET2 Public IPv4 over IPv6 Access
Network" or something similar. So I agree with the
other disucsses/comments on this point.

abstract: end uses don't really care about IPv4 but do
care about Internet connectivity.

abstract: ICP - unexpanded acronyms in the abstract
aren't a good idea reslly

section 1: "Full IPv4 addresses" is not clear to
me, it could mean public/non-bogon addresses or e.g.
a Class C.

section 10: I'm not clear on the consequences
of filtering in the BR based on source IPv6 address.
Wouldn't that possibly cause problems with
multi-homing etc?

[Ballot comment]
Elwyn Davies' brought up what I thought was an important question that deserves some discussion. Section 3 mentions DS-Lite. I think it would be useful to clarify the relationship of this work to DS-Lite.

I agree with Stewart Bryant's suggestion on editing document abstract/title. Similar issue was brought up by Elwyn. However, I do think that publishing this document is very useful, as long as the status of the mechanism is clear from at least the abstract.

I can also highly recommend other parts of Elwyn Davies' Gen-ART review from May 25th as something that the authors should take into account.

[Ballot discuss]
This draft describes an alternative to an active WG standards track draft which was developed and deployed in CERNET2.

A common practice is to hold such drafts behind the WG standards track work, so that it is clear to the reader which is the IETF preferred approach, and which is documenting an alternative approach proposed by another group of workers. Additionally we normally insist that this relative status is reflected in the title and abstract, again to avoid any ambiguity on the matter.

My preferred approach would be to modify the title and abstract to reflect the relative status, include a normative reference to draft-ietf-softwire-unified-cpe and put the draft on hold until draft-ietf-softwire-unified-cpe is sent to the RFCeditor, but we could let it simply sit in the RFCeditor's queue pending the normative reference.

[Ballot comment]
If this had come from v6ops I'd ask the question of whether it was competing with work from softwire. It clearly isn't or at least not in the sense that it's a submarine.

I am ok with the working group putting it's stamp on one thing a way to deploy something while expressing a preference for another in a seperate document

[Ballot discuss]
0) s1: If you're just documenting what was done, then why is it "is expected."  Shouldn't it be:

  In some cases, the 4over6 BR implemented methods to
  limit service only to registered customers.

This makes me wonder whether you're just documenting what was done or whether you think this is going to continue to be evolved (and then we're back at Brian's point)?

1) The discussion about validation confuses me a bit.  DHCP uses the word "validation" in the context of authentication and it uses a MAC, but it's not the MAC address it is a Message Authentication Code.  Is this sentence talking about filtering based on MAC addresses or is it about the DHCP authentication mechanism?

[Ballot comment]
0) I sympathize with Brian's discuss position, but I think it could be cleared up by clearing indicating in the title and abstract that the mechanism is as implemented in CNGI-CERTNET2.  I'll leave it to Ted/Brian to argue out whether the final boiler plate should also be changed.

Might I suggest the following changes:

Title:

OLD:

  Public IPv4 over IPv6 Access Network

NEW:

China Next Generation Internet (CNGI) -
China Education and Research Network 2 (CERNET2) Mechanism for
Public IPv4 over IPv6 Access Network

abstract:

OLD:

This document describes a
mechanism for hosts or customer networks in IPv6 access network to
build bidirectional IPv4 communication with the IPv4 Internet.

NEW:

This document describes how China Next Generation Internet (CNGI) -
China Education and Research Network 2 (CERNET2) implemented a
mechanism for hosts or customer networks in IPv6 access network to
build bidirectional IPv4 communication with the IPv4 Internet.

1) nits:

s3:

r/If the ISP does not have so much IPv4 addresses/
/If the ISP does not have enough IPv4 addresses ?

expand CGN & ICP

s10:

r/As to data packets,/For data packets,

[Ballot comment]
I have no objection to the publication of this document although I am not overly enthusiastic. I would like to hear the discussion of Brian's Discuss.

I think section 12 is probably "Contributors"

[Ballot discuss]
This is a "let's discuss" DISCUSS for my IESG colleagues...

What does it mean for the IETF to publish a WG consensus-based, Informational document that describes how some entity deployed a service?  Why is such a publication not being vectored to the ISE?  This is especially relevant given that this document essentially competes with an active softwire WG document (draft-ietf-softwire-unified-cpe) targeted for PS.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-softwire-public-4over6-09.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Public IPv4 over IPv6 Access Network) to Informational RFC


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'Public IPv4 over IPv6 Access Network'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  When the service provider networks are upgraded to IPv6, end users
  will continue to demand IPv4 connectivity.  This document describes a
  mechanism for hosts or customer networks in IPv6 access network to
  build bidirectional IPv4 communication with the IPv4 Internet.  The
  mechanism follows the hub and spokes softwire model, and uses IPv4-
  over-IPv6 tunnel as basic method to traverse IPv6 network.  The bi-
  directionality of this IPv4 communication is achieved by explicitly
  allocating public IPv4 addresses to end users, as well as maintaining
  IPv4-IPv6 address binding on the border relay.  This mechanism
  features the allocation of full IPv4 address over IPv6 network, and
  has been used in production for high-end IPv4 users, IPv6 transition
  of ICPs, etc.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ballot/


No IPR declarations have been submitted directly on this I-D.