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

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

I just sent it.  The number of changes is not the issue but the content
of those changes is my point.  Nothing was changed that should preclude
DS is my position.

/jim

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2003 12:27 PM
> To: Bound, Jim
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt
> 
> 
> On Thu, 6 Nov 2003, Bound, Jim wrote:
> > 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: "Bound, Jim" <[email-masked]>
Date: Fri, 7 Nov 2003 00:47:32 -0500

good point I agree. so I want to restate my view.  why not go to DS?
Ask for implementation reports too.  I think we can support our ADs at
the IESG layer too this is valid.  It also would be great for v6ops
morale :--)

/jim

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alain Durand
> Sent: Thursday, November 06, 2003 7:02 PM
> To: Pekka Savola
> Cc: Randy Bush; [email-masked]
> Subject: Re: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt
> 
> 
> 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.
> 
> 
> 
> >
> >   -    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.
> 
> 
>