Subject: (ngtrans) Trans Additional Mechanisms : Proposal, BCP, or Standards

From: Jim Bound <[email-masked]>
Date: Fri, 12 Feb 1999 23:31:40 -0500

Harald,

I reread your mail and then saw Steve's mail.  

If you could pull over my Taxonomy slides from Grenoble and check out
the areas of similarity to the ones I report on in this set.  Most of
the parts are not protocol work at all.  They are system integration
methods to assist with transition.  So they are not even the traditional
engineering we do around here in the IETF but systems engineering.

Also one could ask why do this in the IETF or even a consortia to
standardize this integration.  The reason is that is exactly what Phase
V did not do and it failed, a lot because there was no way to transition
users to OSI cleanly until it was too late.  We are ahead of that fiasco
by just having our basic RFC 1933 spec (which should be standardized)
and our Base API and a method to deploy DNS for IPv6.

But we need more.

I will pick on my proposal AIIH.  

One of the hardest things about AIIH is how does DHCPv6 and DNS exist in
the network and communicate even if they are co-located on the same
server.  There is no way we want to try to standardize that other than
say each implementation should figure that out.  It would take forever.
It should not be experimental as the whole point of any transtion
mechanism is to deploy it.

Or do we want to define how an "address mapper" should be done as in the
BIS dual stack host proposal from Itojun.  I don't think so we all will
build the address mapper ourselves as "engineers".  This is not the
IETF's business or their expertise as an entity (some that come here do
know how to build this stuff for sure but that is not the point).

What I am trying to advocate and I think others are too is that we need
a forum where the researchers and vendors can work together to discuss
mechanisms to assist IPv6 deployment.  From this we will develop some
standards and some that are not standards like "protocols" but parts to
put together to create a means to solve a problem.  I think NAT is doing
this over in the Transport Area to some degree.

I think when the WG things the basic work is done they should go for
Informational RFC not experimental RFC.  

Right now I am working on a way to make tcp and udp accept addresses on
the fly in an IP stack and change them and inform the application.  If I
brought this to the IETF right now and folks said OK lets go and there
were no implementation then I think that clearly should be an
experimental RFC.  

But not if Experimental is perceived no one implements it.  No engineers
work deserves that to happen.  If this is true nothing should be made
experimental in the IETF.  As a product engineer I know I would not have
time to implement "Experimental" type things or be able to justify it.`

OK I will shut up again,
/jim

---

From: Randy Bush <[email-masked]>
Date: Sat, 13 Feb 1999 12:19:59 -0800 (PST)

Jim:
> time to implement "Experimental" type things or be able to justify it.

if you were a product engineer in a company which actually believes in a
particular product direction, and the experimental rfc were the agreed only
path, then you would be pretty silly not to implement it according to the
experimental rfc.  as you frequently claim immense customer pressure to
implement and deploy, i presume you are not allowing misinterpretable labels
to deter you.  similarly, i suspect that others will either feel customer
pressure to implement or not, and their decisions will not be affected by
labels on an rfc.  if they are, then they could not have been very serious,
eh?

i suspect that the root problem here is that you are not comfortable with
the label experimental being applied to ipv6 transition.  as my altzheimers
device has blocked memories of previous ipv4-ipv6 transitions, i am less
disturbed by the label than i am by all the fuss about it becoming a red
herring and distracting from planning and testing the actual work.

the informaional and experimental label issues are being revived in poised,
which seems the appropriate place to do so.

just another idiot's opinion.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 16 Feb 1999 10:50:24 -0800 (PST)

> But thus far I know of no experimental RFC that has had this happen too?
> WHere customers have requested on a large scale.

dnsind is moving rfc1712 from experimental to standards track because it
seems to be deployed.

randy

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Feb 1999 14:22:16 -0500

> > WHere customers have requested on a large scale.

RFC 2052 (SRV RRs) is moving from experimental to standards track.

Protocol Independent Multicasting (PIM (RFC 2362) is moving from
experimental to standards track.

Thomas

---

From: Jim Bound <[email-masked]>
Date: Tue, 16 Feb 1999 09:01:28 -0500

>labels on an rfc.  if they are, then they could not have been very serious,

It is true the label is in the way.  But if I were to implement it, I
might as well get other vendors to work with me as for networking stuff
its not much good if I am the only one who implemented it as most
customers don't buy from a "single" vendor but multiple vendors.  So if
it was experiemental I would start a consortia and fix it up with
multiple vendors if the customer demand was that great.

/jim

randy

---

From: Jim Bound <[email-masked]>
Date: Tue, 16 Feb 1999 16:24:27 -0500

>experimental to standards track.

That is good.  SRV RRs should have been a standard right away.  Same
with PIM I would argue.

I am still not convinced our other mechanisms can go to experimental.

But hell I am just one voice.  The WG should do what they want to do.

I think Informational is the correct choice.  

thanks for taking the time to note this, (you too Randy)
/jim

---

From: Randy Bush <[email-masked]>
Date: Tue, 16 Feb 1999 14:00:54 -0800 (PST)

Hey Jim,

I am not big on naming, so please take this with a pillar of salt, well a
lot of it.  :-)

I think the bottom line will be successful deployment.  The folk that
believe in v6 will not let a label stop them, and those that don't will
not be attracted by the juciest of labels.  And the sweetest revenge is
success.

It ain't the height of the fence that keeps the cows in the pasture, it's
the quality of the grass.

So I am far more interested in fully understanding the consequences of
Alain Durand's comments on 6to4, for example.

randy

---

From: Jim Bound <[email-masked]>
Date: Tue, 16 Feb 1999 17:29:46 -0500

Randy,

Thanks I actually agree with you deep down.

But here is what is happening too and it has happened a lot around IPv6
work in this community.

We are in a urinary contest to some extent.  What I don't like is a
bunch of ADs telling us worker bees and in this case the Chairs too (who
are also worker bees in this WG) "we don't have a clue" because they no 
better,  Cocky puck.  Or more succinctly bullshit.  And I for one am 
frustrated with the bullshit rules this place is using.  But I admit I
hate rules and avoid them when ever I can.  They just slow progress in
life down protecting things that cannot be protected really.  Life is
not safe, its full of risk and anyone could drop dead any second.  Life
is too short and so it the time get transition figured out for IPv6.

Plus we have just wasted an entire week and almost two weeks now which
is 1/2 of a month and 1/24th of the year to discuss what we do with our
documents and our work.  Something about this just stinks to high
heaven.  It is ridiculous and proves my point we can't get the
additional transition mechanisms done in the IETF ready for this year
and we need to go take it and get it done out of the IETF.  After this
debate there will be another one on something else supporting some other
rule.  And we will loose another 1/24th of a year.

Valid arguments have been presented to not use experiemental.  
Lets make a decision one way or the other for gods sake.  What we do
after that will be better than more discussion.

/jim