On 12/11/14 8:02 PM, "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net> wrote:
On 12/11/2014 2:11 PM, Lee Howard wrote:
The goal isn't IPv6, though?the goal is a functioning, interoperable
Internet. I believe we have consensus that IPv6 is the best mechanism to
achieve that. I think I see consensus that some transition tools are
temporarily useful as people wait for others to deploy. Do we need a
Proposed Standard for those temporary transition tools?
The goal isn't Proposed Standard for temporary transition tools. The
goal is a functioning, interoperable Internet.
Agreed!
Standardization is a means of providing common, interoperable
capabilities. If a tool will facilitate interoperability, then
standardizing it can facilitate its adoption.
By definition of "Proposed Standard," yes.
When pursuing transitions in open, diverse environments, calling a tool
'temporary' is mostly a political statement that seeks to marginalize
the tool, since transition on the Internet is often measured in decades.
I see your point, but it wasn't really my intent; if it was considered a
temporary workaround, it would seem weird to advance it.
The point here is whether RFC 6346 can be moved to Proposed Standard.
Others have already pointed out problematic text, so we need a new draft
to evaluate.
The other gates to Proposed Standard (RFC2026):
* A Proposed Standard specification is generally stable,
* has resolved known design choices,
* is believed to be well-understood,
* has received significant community review, and
* appears to enjoy enough community interest to be considered valuable.
Are we arguing about "enough community interest"?
Also:
* The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.
I think this qualifies under that sentence. There is probably real
operational experience, and I think it is reasonable for the IESG to
require that some of it be documented (in the document to be moved) before
advancing.
Other text changes:
* Update discussions of the status of transition
* Update references to current versions of documents (e.g., PCP,
stateless-4v6, everything that was "Work in Progress" when the doc was
originally written)
* Mention other port-allocation methods and considerations, e.g.,
draft-chen-sunset4-cgn-port-allocation-05 and the RFCs listed in its
Security Considerations document, draft-donley-behave-deterministic-cgn,
* Update the Security Considerations section (as in the previous point)
* Add more logging discussion, as documented in the above docs and
elsewhere
* Replace "Double-NAT" with NAT444 and refer to documents discussing it
* Redefine "CPE" to refer to a layer 3 device, not a layer 2 device
* A previous comment indicated that ports 0-1024 are usually reserved;
further discussion (and maybe update the examples to exclude them)
* Additional discussion of PCP experience relevant to A+P
* ICMP handling says "gateway device must rewrite the "Identifier" and
perhaps "Sequence
Number" fields" and I would like to see more detail/experience under
that "perhaps."
Until at least these items are addressed, I oppose moving this document to
Proposed Standard.
I suppose the other approach we can take is to say that we will ignore
95% of Google's users, until they adopt IPv6. That seems to be the
implication of refusing to pursue IPv4-based tools in the IETF.
This sounds like "mostly a political statement." Trying to get this back
onto the specific question here, rather than another round of ranting
about the IPv4-IPv6 transition in general.
Lee