Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard

From: Fred Baker <[email-masked]>
Date: Tue, 27 Mar 2007 18:34:51 +0200

On Mar 25, 2007, at 11:43 AM, Brian E Carpenter wrote:
> Speaking as a long time participant in ngtrans/v6ops, I believe  
> this request should only be addressed via v6ops, which, if I recall  
> correctly, has as its established consensus to progress no more  
> IPv6 coexistence techniques.
>
> I'm not saying that consensus can't be changed, but until it is,  
> I'd be against AD sponsoring of this request (without any comment  
> on the merits of this or other proposed additional coexistence  
> techniques).

Fred, Brian, Jari, Ron:

Fred, let me start out by saying I don't want to give you a run- 
around, which I have a hunch you might feel you are getting.

IPv6 Operations' charter (http://www.ietf.org/html.charters/v6ops- 
charter.html) states that "The main focus of the v6ops WG is to look  
at the immediate deployment issues; more advanced stages of  
deployment and transition are a lower priority." My instructions from  
Ron's predecessor are that discussion of flavor-of-the-month  
transition/coexistence strategies had the effect of rat-holing all  
progress in v6ops, and "low priority" should be read "out of scope".

Ron is free to tell me that he has a different interpretation.

I think that if IPv6 Operations were to take the matter of bringing  
ISATAP to Proposed Standard up, I would want to know more than that  
"we coded it up and it seemed to mostly work", which is formally the  
requirement of RFC 2026:

    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.

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.  However, the IESG may
    waive this requirement in order to allow a specification to advance
    to the Proposed Standard state when it is considered to be useful  
and
    necessary (and timely) even with known technical omissions.

noting that ISATAP becomes a way to dynamically create topology of a  
type and becomes an interesting way to hide various things, I would  
wonder about the operational impact along the lines of the first  
paragraph above.

As a result, I would want to know who had implemented it, whether  
interoperability had been established, whether (as is routinely done  
with routing protocols) there has been field testing that establish  
the operational utility of the technology, and so on. In short, this  
is not just "an" approach to coexistence; if the IPv6 Operations  
Working Group is going to put its imprimatur on a technology, I would  
want to know that we were recommending the *right* one. Note that we  
have just gotten through saying that NAT-PT was actually *not* the  
right one although the IETF previously said it was, and Teredo has  
been given that imprimatur by someone other than this working group.

This is in the context of comments previously made to the effect that  
if ISATAP goes to Proposed Standard, then there are a list of  
protocols that want to make the same status change. From my  
perspective, I would rather say nothing than say the wrong thing. I  
don't get any more gumdrops in my Christmas stocking for producing  
Proposed Standards, but when I do I get more questions from the press  
and from customers regarding why the status is there. I need to be  
able to clearly answer the questions.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Mar 2007 15:05:09 -0700

Fred,

Responding only to this one point for now:

> In short, this  
> Working Group is going to put its imprimatur on a technology, 
> I would want to know that we were recommending the *right* one.

What ISATAP is good for is providing a link for connecting dual-
stack routers within Mobile Ad-Hoc Networks (MANETs), as well as
mechanisms for autoconfiguration and discovery of multiple Internet
gateways. It is important to note that the term "MANET" could mean
anything from mobile platforms (planes, trains and automobiles), to a
home network, to a singleton node with an aribtarily-complex network
of physical or virtual nodes within. For other examples, please see
the thread on "Real-life Deploymnet of MANETs" on the MANET mailing
list:

  http://www1.ietf.org/mail-archive/web/manet/current/msg09029.html

Informational aspects of the operation of ISATAP are documented
in "MANET Autoconfiguration"; see:

  http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-07.txt

but please note that this work (as well as ISATAP itself) derived
from an earlier work titled: "Virtual Ethernet".

Important point is that for the use-case of dual-stack routers
communicating within a MANET, ISATAP already provides a mechanism
that satisfies the needs of the IETF AUTOCONF wg and the so-called
"MANEMO" interest group. Plus, it is shipping in major vendor OS's
today.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Mar 2007 15:46:38 -0700

FWIW, please note also that I am specifically intending to
equate the terms "MANET" and "site" (see also the definition
for "MANET" in the I-D listed below).

Fred

> -----Original Message-----
> From: Templin, Fred L 
> Sent: Tuesday, March 27, 2007 3:05 PM
> To: Fred Baker; Brian E Carpenter; Ron Bonica; Jari Arkko
> Cc: [email-masked]; Lindqvist Erik Kurt
> Subject: RE: [RAM] Request to advance RFC4214 to Proposed Standard
> 
> Fred,
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Mar 2007 09:02:35 +0200

Good to know, and certainly a good thing. Until Ron tells me  
otherwise, that's as far as I'm going in this discussion.

On Mar 28, 2007, at 12:05 AM, Templin, Fred L wrote:

>> In short, this is not just "an" approach to coexistence; if the  
>> IPv6 Operations Working Group is going to put its imprimatur on a  
>> technology, I would want to know that we were recommending the  
>> *right* one.
>
> anything from mobile platforms (planes, trains and automobiles), to  
> a home network, to a singleton node with an aribtarily-complex  
> network of physical or virtual nodes within. For other examples,  
> please see the thread on "Real-life Deploymnet of MANETs" on the  
> MANET mailing list:
>
> Informational aspects of the operation of ISATAP are documented in  
> "MANET Autoconfiguration"; see:
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Mar 2007 03:41:02 -0400

that's really kind of too bad, as only the teensy-tiny Manets built  
with 802.11 cards are limited in scope to small domains. For them to  
scale properly, one will need to route, and one routes among sites.

Fort Monmouth specifcally told me once that they considered an  
individual soldier to be a site, as a soldier will have several  
addressable devices in his PAN and they will want to route to the  
collection of devices.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2007 14:25:48 +0200

On 2007-03-28 00:05, Templin, Fred L wrote:
...

> from an earlier work titled: "Virtual Ethernet".

If that means 6over4 a.k.a. RFC 2529, I'll observe that that work
went to PS eight years ago, but has not made it into the real world
despite a couple of successful implementations at the time - largely
because it depends on deployment of IPv4 multicast. iirc, the original
motivation for ISATAP was to provide an NBMA replacement for that
multicast requirement. Is that still an accurate characterization?

     Brian

(Fred & Kurtis - pls excuse this discussion continuing. While the question
may be out of charter, I think the parties with interest and experience
are all here.)

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 07:10:30 -0700

Hi Fred, 
 
> scale properly, one will need to route, and one routes among sites.

Maybe what I said seemed too limiting, but I certainly don't
mean to restrict the ISATAP domain of applicability to only
teensy-tiny MANETs. When I say that I equate "MANET" to "site",
I left out the part that says that a site may in fact be
arbitrarily large and may contain other sites within it. In 
fact, here is how I define "MANET":

   "A MANET may be as large as an Autonomous System (AS) or as
    small as an individual site, and may also be a subnetwork of a
    larger site.  A MANET router (and its downstream-attached links)
    is a "site" unto itself, and a MANET is therefore a "site-of-
    sites"."

Does this clear up what I am intending in terms of what is
or is not in-scope for ISATAP?
 
> addressable devices in his PAN and they will want to route to the  

That is covered by my definition of MANET where I say:
"A MANET router (and its downstream-attached links) is
a "site" unto itself".

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 07:17:39 -0700

> If that means 6over4 a.k.a. RFC 2529,

Yes, I am meaning to include RFC2529 but also the Virtual Ethernet
project that came from a research lab which (I think) pre-dated
6over4. Both RFC2529 and the research work are cited in RFC4214. 

> I'll observe that that work went to PS eight years ago,

Good case in point.

> but has not made it into the real world
> multicast requirement.

Yes.

> Is that still an accurate characterization?

For the most part, yes; but we are also beginning to see
native multicasting capabilities emerging for MANETs so I
do not mean to preclude the possibility of benefitting
from such.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 07:55:26 -0700

Fred, 

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Wednesday, March 28, 2007 12:03 AM
> To: Templin, Fred L
> Cc: Brian E Carpenter; Ron Bonica; Jari Arkko; 
> [email-masked]; Lindqvist Erik Kurt
> Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard
> 

IMHO, there seems to be enough interest here such that I would
now like to formally re-open my request to advance RFC4214 as
standards-track (recall that in my 3/27/07 message to the RAM
list I said that I was suspending the request pending further
discussion).

Should we wait to see what the ADs have to say about it now?

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2007 17:34:05 +0200

Actually the VE work was directly triggered by the 6over4 draft;
it was a student of Lixia Zhang, and the 6over4 authors encouraged
him!

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 08:51:48 -0700

Brian, 

> it was a student of Lixia Zhang, and the 6over4 authors encouraged

Thanks for setting the record straight on this; another reason
to recycle RFC4214 would be to simply get our references to past
works updated accordingly.

Are there other past works we should point to?

Fred

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 Mar 2007 17:01:52 +0100

> works updated accordingly.

The reason we didn't use ISATAP in early deployment phases here is that
we simply didn't want arbitrary automatic tunnelling between links 
within our site.   We have a preference to manage and structure the
connectivity.    If the auto-tunnelling were all on one link, then we
may as well use native IPv6.    Instead we managed the connectivity between
the early adopter links.    We wouldn't use 6over4 in our environment for
the same reason, although IPv4 multicast is available.

That said, I can see how there may be a useful application of ISATAP
for manets, and would be interested in seeing an example deployment plan
or scenario.

-- 
Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 09:06:42 -0700

> for manets, and would be interested in seeing an example 
> deployment plan or scenario.

Arbitrarily-complex home networks behind NATs are one deployment
scenario; it doesn't have to be highly mobile or even wireless to
meet the criterion of a MANET. See:

http://www1.ietf.org/mail-archive/web/manet/current/msg09032.html

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 16:32:11 -0700

FYI, RFC4214(bis) has been sent to [email-masked]
and is available here until it shows up in the I-D repository:

  http://www.geocities.com/osprey67/isatap/isatap-bis-00.txt

Workgroup item?

Fred

> Sent: Wednesday, March 28, 2007 7:55 AM
> To: Fred Baker
> [email-masked]; [email-masked]; Lindqvist Erik Kurt

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Mar 2007 01:17:38 -0400

You're not listening.

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Mar 2007 08:34:32 -0400

Fred:

What is the status of ISATAP in softwire? I understand that softwire  
is chartered to specify "the standardization of discovery, control  
and encapsulation methods for connecting IPv4 networks across IPv6  
networks and IPv6 networks across IPv4 networks in a way that will  
encourage multiple, inter-operable implementations." I also  
understand that ISATAP was considered there?

http://www.ietf.org/html.charters/softwire-charter.html

---

From: "Durand, Alain" <[email-masked]>
Date: Thu, 29 Mar 2007 09:13:05 -0400

Fred,

The softwires wg is looking at two frameworks, of for the "Hub and
Spoke" case
and the "Mesh" case, as described in the softwire problem statement:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-problem-statemen
t-03.txt
Isatap was briefly considered but does not fit any of those two cases.
The softwires wg chose L2TP for "Hub and Spoke" and
a BGP extension (tunnel safi) for "Mesh".

   - Alain, softwire co-chair.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Thursday, March 29, 2007 8:35 AM
> To: Templin, Fred L
> Cc: Brian E Carpenter; Ron Bonica; Jari Arkko; Mark Townsley; 
> Subject: Re: RFC4214(bis)
> 
> Fred:
> 
> What is the status of ISATAP in softwire? I understand that 
> softwire is chartered to specify "the standardization of 
> discovery, control and encapsulation methods for connecting 
> IPv4 networks across IPv6 networks and IPv6 networks across 
> IPv4 networks in a way that will encourage multiple, 
> inter-operable implementations." I also understand that 
> ISATAP was considered there?
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 10:00:55 -0700

This whole exercise reminds me of what volleyball players
call a "campfire defense" - everyone stands around in a
circle and the ball drops to the floor in the middle...

Just to sum up, this discussion got started on the 'ram'
mailing list and then moved over to 'v6ops' where the bulk
of the discussion took place (hence I am posting only to
'v6ops'). Meanwhile, discussion on the 'ipv6' list turned
up some points for clarification that could potentially
be addressed in an rfc4214(bis) document. Finally, there
was some brief mention of the 'softwire' wg, but there
seems to be no clear way forward for wg adoption.

So, I seem to be left with the decision of just letting
it go or seeking publication as an individual submission
through AD sponsorship as outlined in "ION: Guidance on
Area Director Sponsoring of Documents". By my own judgement,
there seems to be sufficient interest on the various mailing
lists such that the latter option would seem to be in the
best interest of the community so I would like to now
request advancement of rfc4214(bis) to standards-track
through AD sponsorship.

Perhaps someone can correct me if I'm wrong, but the "ION:
Guidance..." document seems to leave it up to the individual
as to which AD to select as sponsor. That being the case, I
have to look at the past history of rfc4214 and note that it
was published through AD sponsorship by an operations area
AD. So, I would like to request that Ron Bonica from the
operations area take on advancement of this document
as the sponsoring AD.

If for some reason Ron must decline, I would then ask that
Mark Townsley from the Internet area take on the sponsorship
responsibility since a good bit of the discussion and technical
input have come from the Internet area. Please note that the
selection of Ron and Mark was that (again, by my own judgement)
they seem to have the most experience with tunneling mechanisms
based on their RFC publication record; it was not intended as
a snub to the other ADs.

Please advise as to next-steps,

Fred L. Templin

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Mar 2007 20:24:12 +0300 (EEST)

On Thu, 29 Mar 2007, Templin, Fred L wrote:
> That being the case, I have to look at the past history of rfc4214 
> and note that it was published through AD sponsorship by an 
> operations area AD. So, I would like to request that Ron Bonica from 
> the operations area take on advancement of this document as the 
> sponsoring AD.

Correction.  RFC 4214 is not an IETF RFC.  It was published through 
the RFC editor's "Independent Submissions" process.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 11:10:45 -0700

Ron,

Thanks for the reply. I am sorry I didn't specify a timeframe,
but I was hoping to have some guidance yet this week (by 3/30)
and yet today if possible. If your plate is full, perhaps we
can ask Mark; Mark, would you have time to look into it this
week?

If Mark is also busy we could ask the other ADs, but I
suppose another option would be to just put it as an
independent submission to the RFC editor?

Thanks - Fred

> From: Ron Bonica [mailto:[email-masked]] 
> Sent: Thursday, March 29, 2007 10:46 AM
> To: Templin, Fred L
> Cc: Mark Townsley; [email-masked]; Jari Arkko; Lindqvist 
> Erik Kurt; Fred Baker; David Ward; Durand, Alain; Bob Hinden; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Request to advance rfc4214(bis) to 
> standards-track through ADsponsorship
> 
> 
> 
> Templin, Fred L wrote:
> 
> Within the next week or so I will review the document and the
> surrounding situation and get back to you with a decision.
> 
>                               Ron
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 13:47:30 -0700

Ron,

> Is there some urgency to get it through this week?

All I have to go on is my gut instincts, but I would
have to say emphatically yes.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 13:47:10 -0700

> That's always an option.

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

Thanks - Fred

---

From: David Meyer <[email-masked]>
Date: Thu, 29 Mar 2007 13:23:31 -0800

> have to say emphatically yes.

	Can you tell us why?

	--dmm

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Mar 2007 15:33:40 -0700

Ron,

> Actually, I would like an opportunity to review this 
> situation.

In "ION: Guidance on Area Director Sponsoring of Documents"
it is IMHO not at all clear how the author of an individual
submission is to select a sponsoring AD, and so I have no way
of knowing who is the right person or persons to work with.
Not intending any disrespect, but it was just a random
coin-toss that led me to you.

In "Independent Submissions to the RFC Editor", however, I am
seeing what looks like a more structured process that takes
the decision making out of the author's hands to a certain
extent and places it with an authority who presumably has
much more of a clue than me.

So, let's give that a try and see what the RFC editor says.
Maybe I'm wrong, and maybe I'll have to come back to you
again with egg on my face. But, that's why we have humility
and forgiveness.

Thanks for your time,

Fred

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Mar 2007 07:54:33 +0300 (EEST)

> method only good for Informational/Experimental? (Please cite

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 [email-masked], 
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.

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Fri, 30 Mar 2007 09:53:40 +0300

Pekka,

On 3/30/07 7:54 AM, "ext Pekka Savola" <[email-masked]> wrote:

[snip]
> revisions to the specification) to move ISATAP to the standards track.

I have to say I don't really agree with you. ISATAP is implemented in
multiple instances (Windows, routers, etc.). Thus, I would say there should
be enough support to make the document Proposed Standard.

I think the question is if it is worth the trouble at this point. And is
there some protocol evolution needed based on the practical experiences with
the protocol. You and me cannot answer that. I think the people shipping the
products can. 

I also would like to know is the "ISATAP" in the products the same as the
"ISATAP" in RFC4214? If ISATAP != ISATAP it would really be worth while
updating the document and bring the deployed ISATAP to PS.

> take a number of months at the very least to ensure proper review has

Perhaps "number of months" sounds a bit harsh - however, even with a
sponsoring AD there needs to be community review of the document.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Mar 2007 05:39:02 -0400

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.

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:
> No.  RFC editor cannot publish standards track RFCs, those must  
> come from the IETF (either from a WG or through an AD).
>
> "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)."
>
> 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.
>
> --

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 08:29:28 -0700

> > have to say emphatically yes.

Customer requirements - it's what drives us all, right?

Fred

---

From: David Meyer <[email-masked]>
Date: Fri, 30 Mar 2007 08:07:09 -0800

> Customer requirements - it's what drives us all, right?

	I won't comment on the latter, but I really don't see
	what the former (customer requirements) that has to do
	with the rush to PS. Either PS means something, in which
	case there is no rush, or it doesn't (in which case there
	is also no rush).

	--dmm

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 30 Mar 2007 19:26:43 +0300

Hei,

Inline.

Le vendredi 30 mars 2007 09:53, Soininen Jonne (Nokia-NET/Espoo) a 
écrit :
> I think the question is if it is worth the trouble at this point. And
> is there some protocol evolution needed based on the practical
> experiences with the protocol. You and me cannot answer that. I think
> the people shipping the products can.
>
> I also would like to know is the "ISATAP" in the products the same as
> the "ISATAP" in RFC4214? If ISATAP != ISATAP it would really be worth
> while updating the document and bring the deployed ISATAP to PS.

Interestingly, TEREDO PS is not quite TEREDO deployed - did not seem to 
bother, though I dunno which place if any would be right to discuss 
that.

(This is just a side not. I am hereby not advocating anything on ISATAP 
or TEREDO.)

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 09:36:19 -0700

>     Either PS means something, in which

I can't say more about my customer or their use case, but
from my vantage point I have to respectfully disagree.

Thanks - Fred

---

From: David Meyer <[email-masked]>
Date: Fri, 30 Mar 2007 08:59:22 -0800

> from my vantage point I have to respectfully disagree.

	While I understand that there and will continue to be
	proprietary use cases, but such use cases seem a
	particularly opaque reason for rushing to PS status
	(especially given the somewhat dubious value of the PS
	designation itself). 

	Not to put to fine a point on it, but IMO the IETF needs
	more transparency (at every level), not less. 

	--dmm

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 10:02:03 -0700

> 	more transparency (at every level), not less.

Exactly why IMHO we should be going to PS!

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 13:26:31 -0700

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

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

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

> 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

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Mar 2007 12:02:06 -0700

> [email-masked]

With all due respect to your customer (I suspect I have an idea who  
it might be in general terms and had similar conversations on  
different specific topics over the past couple of days), RFC 2026  
doesn't mention "the customer wants it" as a reason to take a  
document to PS, not does it mention announcing a need for it to be PS  
"as of today" as a reason that the IETF should jump through hoops. I  
would suggest that you consider following the procedures laid out there.

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Mar 2007 14:21:46 -0700

On Mar 30, 2007, at 1:26 PM, Templin, Fred L wrote:
> 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.

then it is somewhere between you, Mark, Ron, and Dave. One could  
argue, for example, that ISP-and-residential-customer doesn't  
describe the whole Internet, and the softwire working group should  
expand its scope to cover non-ISP models. I'll leave that to the four  
of you.

Bottom line, I personally do *not* believe that cherry-picking  
mechanisms and taking them to PS by a bypass process is very smart. I  
would really prefer to see evidence of focused thought that results  
in "PS" meaning "IETF thinks it's an actively good idea". Maybe  
that's just me. But Teredo went to PS bypassing a working group that  
was then in formation, and this bypasses the question for several  
other proposals. I'll leave the analysis of the proposals to someone  
else - that's not my point. My point is that the process by which  
Teredo went to PS was broken, especially given that what shipped with  
Vista is said to be different than that which was standardized, and  
bypassing rational discussion in this case has the same issue,  
especially if what is standardized differs from the several  
implementations that are in the field.

Rather than saying "it's this RFC plus that draft plus a little bit  
of powerpoint", I would prefer to see a single draft that describes  
ISATAP-as-deployed, and if it differs from as-deployed, demonstrates  
agreement from the various implementors to shift their code to  
conform. I think softwires is chartered to do that. If Ron wants it  
done in this WG, he hasn't said as much to me.

---

From: "Durand, Alain" <[email-masked]>
Date: Fri, 30 Mar 2007 17:51:35 -0400

> > (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 
> then it is somewhere between you, Mark, Ron, and Dave. One 
> could argue, for example, that ISP-and-residential-customer 
> doesn't describe the whole Internet, and the softwire working 
> group should expand its scope to cover non-ISP models. I'll 
> leave that to the four of you.

The Softwire wg made a huge effort to winnow down the solutions
it was considering to standardize for both the Hub&Spoke and
the Mesh solution. We now have one single solution for each
case, and I consider this a great success, as we were not
running out of smart candidates.

I think it will be unwise to re-open this discussion now,
especially for a transition mechanism that does not fit
in the softwire problem statement:
draft-ietf-softwire-problem-statement-03.txt

Sometime less is more.

  - Alain.