Subject: (ngtrans) Grenoble Interim NGtrans meeting and an immediate issue

From: Bob Fink <[email-masked]>
Date: Tue, 09 Feb 1999 11:42:42 -0800

NGtrans folk,

I've been slow to get to publishing results of the Grenoble ngtrans meeting
as I've been quite sick since I returned.

At an overview level, I would summarize the meeting as follows:

1. after a healthy review of all our mechanisms (Jim Bound helped a lot on
this) we came to the conclusion that we could not at this point eliminate any.

2. developed a list of characteristics of these mechanisms (for further
editing by the list and the various authors) to help us sort the mechanisms
as an aid to users for a set of documents on transition.

3. agreed to start a transition document set (only partly structured at the
moment) that would weave mechanisms and transition scenarios into a
roadmap, i.e., a useful way for use by the uninformed. I have gotten
numerous volunteers to help on this, and will circulate ideas on the
documents to list so we can all have a say in how many, what they
should/should not include, etc.

4. agreed to not use Experimental RFC, just Informational RFC, for our
transition mechanisms (other than RFC 1933 which is on Standards track).
The reason given, and discussed, is that the word Experimental has bad
connotations to the uninitiated wanting to assess where our transition
efforts are, while Informational does not have this connotation. This was
not meant to preclude more atomic subsets of these mechanisms, or other
future things, being put on Standards track.

The immediate problem I have is with 4. above, as Harald is processing the
SIIT draft through the IESG at the moment as Experimental. I've had email
from Harald and Bert with differing views of this change in processing
status. This made me realize that a wider ngtrans list discussion is
necessary to "ratify" what we said in Grenoble (or not if that be the wish
of the larger group).

So I've included their comments on this below, and would like to have
comments supporting and not supporting this as soon as possible so the IESG
know what to do to process SIIT.

Thanks,

Bob

===
>Date: Mon, 8 Feb 99 13:57:47 CET 
>From: "Bert Wijnen" <[email-masked]> 
>To: [email-masked], [email-masked] 
>cc: [email-masked], [email-masked]> 
>Subject: SIIT processing (ngtrans) - change from Experimental to 
>
>Ref:  Your note of Sun, 07 Feb 1999 00:05:58 +0100
>
>
>Subject: Re:   SIIT processing (ngtrans) - change from Experimental to
>
>
>Harald writes:
>> IMHO: THIS IS A WRONG DECISION.
>>
>> If you think transition mechanisms are ready for prime time, the right
>> disposition is PROPOSED STANDARD.
>>
>> Informational means "We think this is useful information to the community,
>> but we have no intention of endorsing it", or "We think this is good stuff,
>> but it belongs to someone else, so we can't change it".
>>
>> If we think people should use it, and it belongs to us, it belongs on
>> the standards track, and absolutely nowhere else.
>>
>> I'll be happy to argue with you on any suitable mailing list, but this
>> decision is just WRONG.
>>
>Harald, Bob stated that the WG will consider to submit some pieces
>for Proposed, so in that sense they do agree with you.
>
>
>At the other hand, the way I understand it, there are various transition
>mechanisms on the table, and some overlap each other. It depends on
>the various scenarios of transition as to which one someone will prefer.
>
>
>To me, it seems wrong to have multiple standards that partially
>overlap and some that take different approaches. So as far as I can
>determine, it the decision is OK.
>
>
>One of the things the WG wants to do is to make a grid of the various
>proposals and mapping which functionality they provide. That will
>show the overlaps and such. Once that is done, it would be good to
>check if there is a clear "winning scheme" that the WG may indeed
>want to put forward as PS.
>
>
>Also... it became clear to me once more, that it doesn't matter at
>all (as far as I can tell) what track we put RFCs on. Take a 100 people
>and they all have their own opinions... very oftend based on what suits
>them most at any particular point in time.
>
>
>> Sorry I couldn't be in Grenoble....
>>
>It would have been good to have you, your background in this area is
>much better than mine.
>
>
>Yet... I do not think the WG decided anything SERIOUSLY WRONG (IMHO).
>
>Bert

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 10 Feb 1999 17:19:08 +0900

From: Bob Fink <[email-masked]>
Subject: (ngtrans) Grenoble Interim NGtrans meeting and an immediate issue
Date: Tue, 09 Feb 1999 11:42:42 -0800

> know what to do to process SIIT.

The newest SIIT draft doesn't provide any solutions against the
problems we pointed out. Unless they are resolved, I don't support to
process the draft to any kind of RFC.

--Kazu

Subject: (ngtrans) comments on SIIT 04
From: Kazu Yamamoto (山本和彦) <[email-masked]>
To: [email-masked]
Date: Wed, 20 Jan 1999 22:34:19 +0900

Here are our (Kazu and Sumikawa) comments on SIIT 04:

(1) Is IPv4-translated address routable in an IPv6 site?

If there is only one IPv6 subnet in an IPv6 site, IPv4-translated
address can be routable to the subnet.

However, IPv4-translated addresses shares just one prefix
(::ffff:0000:0000:0000/96). If there are multiple IPv6 subnets, how
can IPv4-translated addresses be forwarded? It seems that only one
subnet can exist if we use SIIT.

(2) UDP checksum

The memo says that no cheksum update is necessary for UDP. But we
think this is not ture. There is one exception.

If a UDP/IPv4 packet whose checksum is 0(ie. not calculated), SIIT
have to calculate checksum for a new UDP/IPv6 packet.

Worse, if UDP/IPv4 fragment packets whose checksum is 0, SIIT have to
reassemble them to calculate checksum. So, all fragments must be
stored (cannot just be forwarded) in SIIT due to reassemble. This
means that one site can install only one SIIT so that all fragments go
through the same SIIT.

Please clarify this case.

We thus think SIIT is not really stateless.

(3) impact to application

Section 1.2 says that "There are no extra changes needed to
applications to operate through a translator". This leads readers
misunderstand.

Applications cooperating with SIIT, such as FTP, must be *SIIT-ready*. 
For example, if an FTP/IPv6 client receives a PORT command, the client
add the IPv4-translated prefix to the IPv4 address specified byt PORT.

We would like to ask to change the sentence above to be more
appropriate.

--Kazu & Sumikawa

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 10 Feb 1999 17:15:38 +0900

> should/should not include, etc.

Does this mean that you will throw away all documents that we wrote so
far?

--Kazu

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Feb 1999 11:24:55 +0000

> as I've been quite sick since I returned.

We all hope you are better now.

...
> future things, being put on Standards track.

I'd observe that 6over4, which is de facto a transition mechanism,
has just been approved as Proposed Standard (RFC # pending).
Where we are sure of ourselves, I thing going straight to the
standards track is a Good Thing.

There is some argument for making SIIT experimental, which I gave
in RFC 1671 :-) But if we think it works, why not go for Proposed?

    Brian

---

From: Jim Bound <[email-masked]>
Date: Wed, 10 Feb 1999 10:01:12 -0500

Folks,

You can get my updated Taxonomy slides at:

sipper.zk3-x.dec.com (v4) or sippre.ipv6.zk3.dec.com (v6) anon ftp and
cd to /pub dir.  File is : taxonomy_trans_ipv6.ppt.

I added one slide for other mechanisms that I need to add to the
taxonomy per the meeting.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 10 Feb 1999 10:57:37 -0500

Brian,

>standards track is a Good Thing.

I think 6over4 is a different case than the other mechanisms and why it
was worked on and moved to standards track in ipng not ngtrans.  

I do think the Transition Mechanism base spec should move along the
standards track from RFC 1933.

The effort to make many of the proposals Standards will be great
controversy in many cases at best.  We cannot wait for that process for
the market as the IETF is too slow and too big and too many opinions for
the mechanisms.  Making them experimental is sending the wrong message
to the market.  In addition most of them are not "protocol" work but
ways to use and adjust existing mechanisms for IPv6 and IPv4.  They mess
with everything from DHCP(v4 and v6) to DNS.  Why is such work an IETF
matter.  Most of them are work for "systems" engineers and systems
integrators not pure IP stack engineers or product work in the same
light.

I strongly urge that we track other mechanisms specs to Informational RFC 
and request that the authors ask for them to be moved in that direction for 
now.  

The IETF in this space cannot solve the problem.  But the authors of the
specs and participants of those specs can and then real implementation
and deployment will test it in the market.  

We could not even get a "grid" done at the Grenbole meeting for
mechanisms which I will have a lot to say on as that discussion begats.
I for one will move that discussion in parallel to the v6 deployment
non-IETF work and work with the vendors to pick a few to agree to deploy
in the next year.  It could take the IETF process a year to even figure
out a matrix.  That is unacceptable to us building real IPv6 products
who need to ship in the next 12-18 months.  Let alone for our customers.
I am sorry but I think this needs to be taken out of the IETF's hands
and given to folks who don't have all the overhead of "abstraction" and
"discussing" things to death.

I would love to be convinced otherwise of course.

>in RFC 1671 :-) But if we think it works, why not go for Proposed?

I think it should be informational and "the" translation mechanism first
released in Host vendor IPv6 products.  So I feel it is worthy of a bit
more than experimental, as are the other proposals.  By making them
informational they are at least put in the public domain.

I hate to see a deployment vs IETF schism develop but transition
mechanisms are too close to the success and bread and butter for IPv6 to
be successful and for vendors to finally ship it to users.  We cannot
and should not wait on the IETF process here.  The compromise is to
proceed with the work in ngtrans and move them to Informational RFC as
they are fine tuned by this working group is my input to this working
group.  If not then non-IETF direction is the only course.

Sincerely,
/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 10 Feb 1999 11:16:50 -0500

Kazu,

>Does this mean that you will throw away all documents that we wrote so

Absolutely not.  The idea is to develop a roadmap for users who want to
deploy IPv6 and for implementors building IPv6 of the various
mechanisms (kind of like the IPsec roadmap).  What we started in Grenoble 
using my Taxonomy presentation as a start was to try and determine all 
the parts of the transition into 2x2 matrices.  The Rows in the Matrix would 
be the transition functions or dependencies and the Columns in the Matrix 
would be the different Transition proposals.

Each cell in each Matrix would be a tell-tale sign of what the mechanism
would do or not do for IPv6 Transition and also depict its limitations.

I proposed a very simple Taxonomy (you can get the slides I sent out)
which could be used to begat the matrices (or maybe one matrix), but in
the meeting all the typical academic abstractions appeared IMO and it
turned from solving a very simple problem (who does what in which
proposal) to working on the PHD Thesis of Transition mechanism IMO.
Folks started debating about a freakin "cell" in the matrix and what it
"mean't" (this is what causes all the work in the IETF of late and for
some cases it is valid but I don't believe in this case) as opposed to
what the mechanism "will or will not do".  The end result was a
communications bottleneck with all getting frustrated and moving to a
different topic.  So we need to now build that matrix or set of matrices
here.  From that I think we will see a Roadmap Document for Transition
Mechanisms which would be a useful product from this working group.

How long it takes and how we get there is the issue.  I think I got us
started but the chairs disagreed and proceeded down a different path
which I found insulting in addition to the end result which was
frustration and building more bulleted lists instead of paragraphs which
was the essence of my taxonomy.  We don't need lists we need solutions
and then very simple contrast and compare.  To contrast/compare we need
to agree on the assumptions we all have for transition.  Until we do
that other discussions will be perplexed with confusion and that is what
I tried to avoid to no avail thus far.  I hope we can have a healthy
discussion of our assumptions and it could be that two proposals
completely different are valuable as they support certain assumptions.

I think "assumptions" need to be part of the matrix and it is 3
dimensional not 2.

Also as I said in my other mail unless we can do this expediently I
suggest WIDE and other good IPv6 workers take figuring this out offline
of the IETF so we can get it done.  But lets see where we can get on the
list.

/jim

---

From: Bob Fink <[email-masked]>
Date: Wed, 10 Feb 1999 09:56:59 -0800

Kazu,

>Does this mean that you will throw away all documents that we wrote so

Absolutely not!  If anything, our Grenoble meeting enforced the importance
of keeping all the existing transition mechanisms.

The document set is overview guidance about how to understand all the
various documents we have and how you might use them (as Jim also described
in his response to you). In fact, I want to enlist you and your WIDE
colleagues help in writing these overview documents (along with several
other folk that have offerred as well). But more on that as I try to
organize this activity over the next week or so.

Jim spent a lot of effort in talking about his Taxonomy (which he put a lot
of work on... thanks Jim). I want to note that the real purpose of Jim's
effort was intended to lead a discussion at the meeting of how we would
categorize the various drafts for pruning off many or most of them. It
became abundantly clear (thanks to Jim's help and other discussion) that we
couldn't do this as there were potential places for all of the
ideas/mechanisms.

Thus an attempt on a matrix was a new effort to use as a table of
classification in the documents helping to give users guidance of what
feature they had in each mechanism. For this purpose it needs to be a
little different than what Jim wants, but we can wait and see how the
discussin flows on this.

Where I will agree with Jim is the need to get the mechanisms and overview
documents into the public domain as soon as reasonably possible. To get
IPv6 deployed, much work needs to be done, and we should all be willing to
do the various parts of it in the most effecive and appropriate places.

Thanks,

Bob

---

From: Bob Fink <[email-masked]>
Date: Wed, 10 Feb 1999 10:31:28 -0800

Brian,

>in RFC 1671 :-) But if we think it works, why not go for Proposed?

We were pretty clear on this at Grenoble (and Jim has spoken on that in his
reply to you).

I do believe that a 6over4 is very different and needs to be standards
track to make it most likely it will be around to use. SIIT and the others
folks are still not at all clear about, nor do they want to have to resolve
overlaps.

So I'm just going to wait for a bit more comment from others, then continue
to move these all to informational.

Bob

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 12 Feb 1999 01:32:30 +0100

>integrators not pure IP stack engineers or product work in the same

Jim,
duck test for protocols:
if 2 ends need to cooperate to achieve a result, it's a protocol.
If 2 ends from different implementors need to cooperate to achieve
a result, it's not a proprietary protocol.

Non-proprietary protocols that get into RFCs are 3 kinds:
- IETF-controlled, IETF feels good about them: Standards track.
- IETF-controlled, IETF feels more work is needed: Experimental
- Non-IETF-controlled, publication needed: Informational.

>and request that the authors ask for them to be moved in that direction for 

I disagree.

>and deployment will test it in the market.  

If you want to move some of these protocols from IETF-controlled to
non-IETF-controlled, there is nothing I can do to stop you.
However, I think it is not a Good Move.

>"discussing" things to death.

The declaration of rough consensus is the work of the WG chair.
The achievement of rough consensus is the work of the WG.
If we're too slow at achieving rough consensus, something needs to change.

What?

>informational they are at least put in the public domain.

Informational is not more than experimental. Only different.
To my mind, it is sometimes less; it says that the IETF is NOT encouraging
experimentation and further evolution; it's "what it is".

>group.  If not then non-IETF direction is the only course.

The Right Thing is to achieve rough consensus on Proposed Standard.

                Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Fri, 12 Feb 1999 16:00:05 -0500

Harald,

I am not going to debate or defend my points.  I think I write well
enough for all to see this is not negotiable with me and I am very clear
on the rules here, the issue, and what will or will not change my
position.

I have influence in the industry and with leading vendors and I will use
that as I have in the past.

I have no choice but to OBEY the very bad folkway that the WG chair defines
consensus in this community, which I have seen abused more than not, and
thus find it wrong and unjust and filled with politics for the most
part.  But I make no attempt at changing it but live with it for the
most part.  But for these secondary transition mechanisms  I WON"T PLAY
THE GAME.  But I WILL LISTEN to my colleagues in this Working Group who
want to convince me.  I will not be convinced because an AD or Chair
tells me I should be and that is the rule.  NO.

I think you folks that are ADs forget something.  We are volunteers
here.  You don't pay our check, our travel, or nothing.  Telling you NO
is something we should all do more often on issues like the one we are
discussing.  

Look I don't want to make a big deal about this and I am listening now
on the list.  I heard what you said and it did not affect my view and
I think these should become informational.

In fact Harald:

I "think????" the chairs want these to be informational.
I "think" the authors want these to be informational.
I "think" the WG members want these to be informational.

Now that is the folks working on it.  Now if the ADs want to play the
dictator role cause they know better than all of the above, or the
IESG, because of some "rule" then it is time to change the freaking
rule.  The rule is wrong Harald.  And don't tell me to go to POISE that
is a kangaroo court.

Or is it the ADs personal opinion.  Well clearly that is not enough as I
would claim the ADs are not as educated as the ones above to overule
this want based on their personal opinion.  Which is just one more
opinion and maybe in this case the "minority" view.

Chairs and ADs are given their role to help "manage" and "lead" not
dictate.  I say the same for the IESG too.

But if we can't get what this WG wants for these mechanisms you can go
put money in the bank I will get it done outside the IETF, build it,
ship it and it will interoperate across the vendors.  And then make sure
the press knows why we did it.

/jim

---

From: Steve Deering <[email-masked]>
Date: Fri, 12 Feb 1999 15:09:14 -0800

Harald,

I think things are not quite as clear-cut as you present them.  Just
yesterday, another IESG member said in a meeting, "When we publish
something as Experimental, we are telling folks 'Don't implement this!'"
That's not what we want to tell folks in this case.

In the case of many of the IPv6 transition mechanism documents, they
document useful transition/interoperation techniques that we will
probably never standardize, but which we think people should feel
fine about going ahead and using in their own environments, to the
degree that they fit.  In fact, they are more like context-specific
BCPs than experimental or standard protocols.

Steve

---

From: Thomas Narten <[email-masked]>
Date: Sat, 13 Feb 1999 16:44:31 -0500

> That's not what we want to tell folks in this case.

The above comment can be interpreted in many ways. One thing that I
think is true is that the bar for Experimental documents is lower than
that for Standards Track documents. That often means the IESG will
publish something as experimental, but will require more work in order
for the same document to be put on standards track. So, yes,
experimental can be a way of saying this is less baked than something
on standards track. Documents the IESG views as "Don't implement
this", however, typically get an IESG note attached to them with a
suitable disclaimer. So I don't think Experimental == don't implement.

One of the reasons for switching from experimental to informational
that was raised last week that I object to is the argument that the
Informational label is better than the Experimental label for
marketing. By that logic, we shouldn't have experimental protocols,
since most everyone would want the "better" label. As Harald points
out, there is currently a pretty good way of categorizing documents
that works in most cases.

IMO, if we are talking about protocols, and they are baked, they
should go on Standards Track. My recollection was that one of the
reasons that hadn't been done was that there were several ways of
doing the transition, and we didn't want multiple things on Standards
Track. However, the interim meeting reaffirmed that all of the
mechanisms have their place. IMO, putting them all on standards track
would be fine, so long as there was a clear applicability statement
indicating the environment in which a particular mechanism is to be
used. Standards Track is for protocols that solve a particular
problem, where one of the messages is that this is the recomended way
of solving a particular problem. Saying there is only one way to
transition is silly. Saying there are N different transition scenarios
with a recommended transition mechanism for each scenario strikes me a
being quite OK for standards track.

> BCPs than experimental or standard protocols.

Why would a mechanism not be standardized? If it's because it is not a
protocol, than informational sounds fine. But if it is a protocol,
context-specific standards should be OK.

Thomas

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 14 Feb 1999 07:11:02 +0100

>BCPs than experimental or standard protocols.

In a world where we standardize RIP-2 and the DHCP option for finding
your Novell Netware server, I don't see it logical not to standardize
the techniques for transition/interoperation that we think will work and
don't bias the operation of the whole network.

I've yammered about this earlier; when something CAN be used in a "corner"
of the Internet, and is genuinely useful, with no "known technical
deficencies"
in its intended scope (we all know where RIP-2 doesn't work), I don't see
the sense of not standardizing it.

I agree that we need to change policy. But the change to Info is NOT the
Right Thing for the IETF, IMHO.

                  Harald