For the record: RFC 2026 states that: The Last-Call period shall be no shorter than two weeks except in those cases where the proposed standards action was not initiated byan IETF Working Group, in which case the Last-Call period shall be no
shorter than four weeks.In other words, a sponsoring AD can take a document to PS with IESG concurrence and a four week IETF last call.
That said, I will tell you what I told Ron I think the process should be here.
First, if there is a working group whose job is to write standards in the area, I think it is the province of that working group. As I read charters, this is the province of the softwire working group. The question of whether ISATAP goes to PS should be decided there,
Second, we have (as has been observed) a list of equally-experimental transition strategies. If anyone takes this up - v6ops, Mark Townsley, or whoever - then I think we should be fairly hard-nosed about it. We need one way that is guaranteed to work, and I have that in RFCs 4213 and 4241. It is "bring up IPv6 networking and IPv6 infrastructure services (DNS etc) in parallel with IPv4 networking and infrastructure services and let end systems use whatever works". In an IPv4-only network, I need an IPv6/IPv4 tunneling strategy, and in an IPv6-only network I need an IPv4/IPv6 tunneling strategy. I'm not sure I need either of those strategies to be dynamic; I need the ability to place a tunnel where needed. So if we are going to describe a dynamic system beyond RFC 4213's version of a Dual Stack and the ability to tunnel, someone needs to decide on a set of criteria for deciding what the minimal set of "right" solutions are. I think we should then take that minimal set (including RFC 4213) to PS.
Cherry-picking any single thing and standardizing it (including Teredo IMHO) without having done that analysis does a disservice to the guy who has to implement it, in the end. He winds up having to implement every strategy that comes along.
On Mar 30, 2007, at 12:54 AM, Pekka Savola wrote:
On Thu, 29 Mar 2007, Templin, Fred L wrote:Process question - is it possible to publish as standards-track through independent submission to the RFC editor, or is that method only good for Informational/Experimental? (Please cite references if possible.)No. RFC editor cannot publish standards track RFCs, those must come from the IETF (either from a WG or through an AD).From http://www.rfc-editor.org/indsubs.html :"Independent submissions are submitted directly to the RFC Editor as Internet Drafts. Once such a Draft has been published, the author should then email its file name to rfc-editor@rfc- editor.org, requesting that the independent submission be considered for publication as an RFC in the Informational or Experimental category (please specify)."FWIW I personally haven't seen sufficient justification (e.g., the amount and the kind of deployments; the number of implementations that currently ship ISATAP as specified by the RFC; the amount of required revisions to the specification) to move ISATAP to the standards track.Even if there was a high-level decision to do so, the process should take a number of months at the very least to ensure proper review has been done.-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings