Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Nov 2003 12:24:55 -0500

Folks,

To make it very clear and sorry about that on why I think it should stay
DS.

My appeal would be based on Section 9 changes since RFC 2893 as
overview.

There is no architectural change to the specification for
implementations.

The changes that remove features were not used widely in the wide
implementation of this mechanism in the deployment market sector at all.

The changes do not affect current deployment at all.  A6, Automatic
Tunnels, et al are not widely deployed by any environment that tested
them.  So the deployment operational community in the market was ahead
of this spec and I would argue directly caused these clarifcations.

This is IPv6 core base transition spec for operators and widely
understood and used. Nothing in this update adds any value to the
mechanism as far as new features.

Given that we have so much work to do and given the IETF does agree we
have a time-to-market or get the spec done problem it is a backward step
to go to PS and we should remain DS.

I also think the working group should first go for DS and if the IESG
wants to push back lets have that discussion then and let the IESG do
there job.  Lets not jump the fence here if we can just open a gate.  

There is nothing technically complex changed or even required to change
in implementation.

/jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Pekka Savola
> Sent: Monday, November 03, 2003 8:03 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt
> 
> 
> Hi all,
> 
> This is a WG Last Call for comments on sending 
> draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms 
> for IPv6 Hosts and Routers", to the IESG for consideration as 
> Proposed Standard:
> 
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt

(We're hoping to recycle to Draft Standard soon afterwards.)

Please review these documents carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this
document is ready to go to the IESG.  Silence does NOT indicate consent.
Unless sufficient support is demonstrated on the list, the documents
will not be sent to the IESG.

The last call will end in about 3 weeks, on 25th November.

Pekka, Jonne & Bob

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Nov 2003 20:40:30 +0200 (EET)

> to go to PS and we should remain DS.

I'm not sure what you mean with "remain DS".

Do you mean, "go from PS to DS, as planned previously" ?

Or, "remain at the DS level" (taken literally) -- which would be factually
incorrect, because RFC2893 is only PS.  (If RFC2893 was DS, I'd certainly
agree.)

> There is nothing technically complex changed or even required to change

I think the MTU sections, at least, have seen some rather extensive
changes.  (Of course, the amount of editorial corrections and
clarifications is also large.)  I'm not sure if we could find many
conformant implementations out of the box (not sure if that'd be required,
of course).

Some further modifications based on LC comments are also very likely.  
What is the amount (and scope) of those changes is of course still a 
question mark.

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