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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Nov 2003 11:13:21 -0500

I do not support this going to PS only DS.  I will appeal most likely.

regards,
/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 19:26:35 +0200 (EET)

> I do not support this going to PS only DS.  I will appeal most likely.

First, it would be nice if you explained why only DS is acceptable.

Note that there have been a large number of updates since the original
transmech.  I'd find it difficult to justify that we could go to DS
straight away. I'd personally really like to go to DS straight away, but
it doesn't seem like a possibility with the revisions the document has
undergone.  But if e.g. our AD/IESG says DS is fine, then it's fine with
me as well.

But if you do appeal, please try to be as clear about the grounds for
appeal as possible, and what action you seek (as stated in section 6.5 of
RFC 2026).

-- 
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: Randy Bush <[email-masked]>
Date: Thu, 6 Nov 2003 10:05:33 -0800

> transmech.

perhaps a small enumeration of the technical changes of substance
would help us decide if this needs to recycle at ps.

randy

---

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

> would help us decide if this needs to recycle at ps.

These are available in the draft, in "Changes from RFC 2893" section.  

I think the most major ones, in addition to removing automatic tunneling,
have been the changes in the MTU parts of the spec.  I believe that
ingress-filtering has also changed.  I don't think many (or close to any)  
implementations conform to the spec out of the box, which is why I was 
edging towards PS myself.  But I'd be happy to be convinced otherwise!

I'll copy it below (minus the ones that seem mostly only editorial):

   -    Removed automatic tunneling and use of IPv4-compatible
        addresses.

   -    Removed default Configured Tunnel using IPv4 "Anycast Address"

   -    Dropped "or equal" in if (IPv4 path MTU - 20) is less than or
        equal to 1280

   -    Clarified that the dynamic path MTU mechanism in section 3.2 is
        OPTIONAL but if it is implemented it should follow the rules in
        section 3.2.

   -    Stated that when the dynamic PMTU is not implemented the sender
        MUST NOT by default send IPv6 packets larger than 1280 into the
        tunnel.

   -    Stated that implementations MAY have a knob by which the MTU can
        be set to larger values on a tunnel by tunnel basis, but that
        the default MUST be 1280 and that decapsulators need to be
        configured to match the encapsulator's MTU.

   -    Clarified text about ingress filtering e.g. that it applies to
        packet delivered to transport protocols on the decapsulator as
        well as packets being forwarded by the decapsulator, and how the
        decapsulator's checks help when IPv4 and IPv6 ingress filtering
        is in place.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 7 Nov 2003 05:06:03 +0900 (JST)

> I do not support this going to PS only DS.  I will appeal most likely.

	we are not going to DS this time, am i right?

itojun

---

From: Fred Templin <[email-masked]>
Date: Thu, 06 Nov 2003 12:26:25 -0800

Maybe I'm missing something obvious, but perhaps one
(or more) of you could explain why the disposition of
DS vs. PS even matters in this case?

Thanks - Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Thu, 06 Nov 2003 16:02:00 -0800

I do not see anything here that is fundamentally incompatible with the 
previous version
that will create interoperability issues.

I support this going to DS.

	- Alain.