RE: Request to advance rfc4214(bis) to standards-track through ADsponsorship

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Fred,

OK, I'm back from my side-trip to the RFC Editor with tail
between legs. I was informed (but not by the RFC-Editor)
that 'draft-iab-rfc-independent' is now the normative text,
and Section 4.2 of that document lists only Informational or
Experimental (and no other categories) as candidates for
independent submission.

So, let's go into the details of what Fred is saying and see
how we can proceed from here: 
 
> 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 by
>     an 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.

Given that, I would be OK if we could simply come to agreement
on a plan of action for the time being - hopefully one which
would put us on a track such as you outlined above.

> 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,

Reading the "softwire" charter, I see one aspect that may
be a matter for concern:

  "In the softwire set-up phase, the initiator and the ISP
   negotiate the parameters necessary to establish the
   softwire."

At first glance, this does not resemble the model I had
in mind for ISATAP; instead, I want that the ISATAP nodes
should be able to decide for themselves the set-up
parameters. Or, maybe I am not clearly understanding what
is meant by "initiator and the ISP negotiate the parameters"? 
 
> 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.

I read RFC4241, and I see limitations:

  1) This seems to be a provider-aggregated mechanism.
  2) I see no provisions for site multihoming.
  3) I see no provisions for mobility management.
  4) The model is predicated on a trusted point-to-point
     link between the PE and CPE.

I want mechanisms that enable provider-independent addressing
and site multihoming as a natural consequence of the architecture,
and the basic ISATAP mechanisms (plus extensions) already support
this. ISATAP also allows mobile nodes with their own provider-
independent prefixes to join and leave the link (i.e., in MANET
fashion) as they travel around.

I also want a model where I can take my Boeing laptop, drop
it down in an untrusted network such as a Cisco campus, and
everything just works with no threats to either Boeing's or
Cisco's assets. In other words, my laptop should be able to
visit an untrusted network and function just as if it were
attached to its home network, i.e., without having to manually
configure VPNs. But, it should also be able to access Internet
services and local services for which it is authorized in the
visited network, too.

> 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.

My proposal for the minimal set is rfc4213 plus rfc4214(bis)
plus 'draft-templin-autoconf-dhcp' (which was presented in
the AUTOCONF wg at IETF68).

> 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.

This still leaves us with where do we go from here. I
believe that what we need is rfc4214(bis) as standards-
track and 'draft-templin-autoconf-dhcp' progressed either
through the AUTOCONF wg or through some other venue.

You mentioned 'softwire' as a candiate work-group for the
rfc4214(bis), but I have some concern for the charter. Since
Mark Townsley is the Intenet Area Advisor, I would like to
ask Mark to either sponsor the rfc4214(bis) as a shepherding
AD or advise as to how this work can be brought into the
softwire wg.

Thanks - Fred
fred.l.templin@boeing.com

> 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
>