On 12/11/14 8:02 PM, "Dave Crocker" <dhc@xxxxxxxxxxxx> 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