Subject: RE: [mobile-ip] Piggybacking - DT recommendation

From: [email-masked]
Date: Thu, 14 Feb 2002 12:56:05 -0600

>Jim,
>
>> If changes are required in IPsec, then I think we ought
>> to ask for them.
>

We can ask for whatever we want, but at the expense of having a
dependency on getting the MIPv6 spec, which could then be stretched out
for a much longer time.

>How long do you suggest we should delay MIPv6 while waiting for such changes
>to IPsec specifications?

I think we (thanks to the DT efforts) have a very good possibility of
geting the MIPv6 spec done by the next IETF (optimistically :)
Hence I would be very much opposed to asking the IPsec WG to make
changes to the specs.

>
>I think Jeff Schiller already pointed out (but I could misremember)
>that MIPv6 BUs don't fit with the available IPsec selectors which would seem
>like a hint that we shouldn't expect IPsec to change.
>So I'm having a hard time seeing how to move forward at the moment.
>

I remember similar suggestions from Jeff. I do believe that one of the
ground rules we set forth for the DT was to not expect IPsec to make
changes. 

-Basavaraj

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Feb 2002 11:36:22 -0800

Hi Raj,

> dependency on getting the MIPv6 spec, which could then be stretched
out

Would it not be possible to put some MUSTs in the RFC stating
how piggybacking should be used and how not?

> Hence I would be very much opposed to asking the IPsec WG to make

I certainly agree, and I'm sorry if Erik and others felt I was making a
religious
argument, I wasn't trying to. I feel the design team has done an
excellent
job with a hard topic, and I have been most encouraged about the
quality of the technical discussion. I really wish we could get that
quality on other mailing lists that I'm on. And, I was not proposing
that we wait on the IPSec WG to complete their work.

> ground rules we set forth for the DT was to not expect IPsec to make

Ever? Or just prior to taking MIPv6 to RFC? Would Jeff be open to
explicit MUSTs and MUST NOTs that limited how piggybacking
could be used with IPSec, until a better solution can be worked out?

                jak