Subject: [Mip6] draft-perkins-mip6-precfgKbm-00.txt

From: [email-masked]
Date: Thu, 25 Mar 2004 15:03:55 -0600

There is consensus in the WG to make I-D :
draft-perkins-mip6-precfgKbm-00.txt a WG document.

However a couple of improvements have been suggested to the
draft. These enhancements can be discussed on the ML and incorporated
if there is agreement. 

The I-D will be published as a WG I-D shortly.

-Chairs

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: "S. Daniel Park" <[email-masked]>
Date: Fri, 26 Mar 2004 09:55:27 +0900

not sure because I didn't follow up this thread fully but
this is my personal concern.

If this draft would be a RFC as standard track, I guess
current RR in 24version will not be used for Mobile IPv6
with the implementation aspect. Is there any consideration 
or requirement ? I hope to see more improved and clarified 
something in this draft. 

Regards.

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, March 26, 2004 6:04 AM
> To: [email-masked]
> Subject: [Mip6] draft-perkins-mip6-precfgKbm-00.txt
> 
> 
> 
> draft. These enhancements can be discussed on the ML and 
> incorporated if there is agreement. 
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Mar 2004 12:49:04 +0300

Hi,

> draft-perkins-mip6-precfgKbm-00.txt a WG document.

I'm not opposed to making this document a WG item, but
I was kind of hoping to get an answer to some of my
questions from the chairs before we make a decision.
Here are the questions from my March 22nd e-mail
to you and James Kempf:

> Re: charter. The draft does fall within the charter,
> and I think we should do it (perhaps with some
> agreement first on how ambitious scope it should have).
> But I believe we have also other issues that we should
> take care of in the RO space, perhaps even higher priority
> issues. So I'd really like to ensure that we can actually
> do more than Charlie's draft. This brings me to ...
> 
> Raj: You didn't answer my question on whether
> more than one improvement can be adopted by the
> WG. My reading of the charter item:
> 
>     - Route optimization will require security mechanisms for
>       trusting and updating the binding information.Return-routability
>       is the basic mechanism for route-optimization. Mechanisms using
>       a shared secret Key/Security Association will be considered.
>       Methods for establishing a security association between the
>       mobile node and the correspondent node are out of the scope
>       of the WG.
> 
> is that shared secrets are just one example and other
> mechanisms can be considered. If that's your interpretation
> as well, then I don't need to worry that we are preventing
> other necessary work to take place.
> 
> Also, I have a question about the charter It says:
> 
>   It should be noted that there are potential optimizations
>   that might make mobile IP more attractive for use by certain
>   applications (e.g., making handovers "faster"). The latter
>   category of optimizations is explicitly out-of-scope at this
>   time; this WG will focus on issues for which there is strong
>   consensus that the work is needed to get basic mobility
>   deployable on a large scale.
> 
> What does this mean, exactly? Why does it not apply to
> the kbm draft, as its main purpose (I think) is to have
> less signaling and delay? Would it apply other alternatives
> to RR? Or is this paragraph in the charter to avoid collision
> with MIPSHOP? That's my interpretation, but I'm not sure
> this is the way others read it...

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Mar 2004 12:59:28 +0300

> or requirement ? I hope to see more improved and clarified 

I may have misunderstood the question, but the proposed
mechanism is an alternative and optional scheme for
authorizing BUs related to route optimization.

As such, the base RR mechanism is used by default
unless this specific scheme is implemented and
configured on. The proposed mechanism is applicable
only to a certain (limited) class of situations, so
you would not always have such a configuration available.

Or perhaps you are asking whether the mechanism is used
in addition to RR? I think the authors have inteded the
mechanim to be used as a replacement (for the situations
that it applies to) rather than as an add-on. There has
also been some discussion on the list about whether the
proposed mechanism should be merged with care of address
testing from the base RFC or possibly some improvement of
that, such as CBA/EBU. I personally think that something
along those lines might be fruitful and would make the
mechanism more widely applicable, though it may be too
early to tell yet.

--Jari