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

From: [email-masked]
Date: Tue, 16 Mar 2004 20:51:17 -0600

WG members,

We would like to call for consensus on the following:

Should I-D: draft-perkins-mip6-precfgKbm-00.txt "Preconfigured 
Binding Management Keys for Mobile IPv6" become a WG document
and pursued on standards track?

Please express your thoughts by Monday, March 22nd 04.

-Chairs

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Mar 2004 07:47:35 +0200

> and pursued on standards track?

Hmm... I'd like to have something resembling Charlie's
draft at least, but I wonder if we have all the options
on the table yet. Following a bit what Christian said
in his e-mail and what I also said earlier, there seems
to a bit of question marks on the scope. How about asking
this consensus question instead:

1. Should Charlie's draft become a WG document as-is?
    (With applicability etc. statements added and some
    technical issues corrected of course.)

2. Should Charlie's draft focus on home address tests
    only, and leave care-of address tests to base or
    other improvements? Note: there will be such
    improvements. Some have already been discussed in the
    WG.

3. Should Charlie's draft be combined with another
    approach that helps also with care-of address tests?

4. Should we do nothing?

If you'd ask this question, I'd have more trouble deciding
between options 1 through 3. Somehow I think the end result
should be that we have a very widely applicable mechanism
that is still not problematic wrt the care-of addresses;
this would seem to imply something 2 or 3 as the best option.
OTOH, you can perhaps go there as well, later, as an extension
of 1.

Also, I have a question to the chairs. How many alternate
security mechanisms are we allowed to adopt as WG items?
If it is just one, then we should be really careful what to
choose here. Probably something else would take priority over
Charlie's draft. If more than one, then its less of an issue.
One or more than one per home/care-of test improvement? But
there might be somewhat differently applicable methods on
this too.

(In the interest of full disclosure: I have a draft
in the works that improves home address test performance
without requiring preconfiguration.)

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 17 Mar 2004 09:15:23 -0800

I believe the document should become a WG item. It fits into our charter
item for alternative route optimization security mechanisms. The document
needs some work yet, along the lines of the discussion that has been
happening, but that's OK.

            jak

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 16, 2004 6:51 PM
Subject: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt

WG members,

-Chairs

---

From: "James Kempf" <[email-masked]>
Date: Wed, 17 Mar 2004 09:49:57 -0800

Jari,

The WG charter explicitly mentions improving RR by using a shared key, so
this draft is right on target as far as charter items go (item 3, bullet 4).
The charter says nothing explicit about improvements to RR such as
draft-vogt-mip6-early-binding-updates-00.txt or
draft-haddad-mipv6-bub-01.txt would introduce, though I suppose item 1 could
be interpreted broadly enough to include such improvements.

For this reason, I believe we ought to keep these two items separate, namely
have one draft that explicitly addresses item 3, bullet 4 and another that
looks at other RR improvements. draft-perkins-mip6-precfgKbm-00.txt looks
like a good start on the former, though as I mentioned in a previous email
message, it needs improvments along the lines that have been discussed on
this list.

My only concern would be whether the current editor of
draft-perkins-mip6-precfgKbm-00.txt would have enough time to devote to it,
and getting sufficient technical resources devoted to buffing up the design.
Perhaps a dedicated design team might be appropriate?

            jak

---

From: Alpesh <[email-masked]>
Date: Wed, 17 Mar 2004 10:07:40 -0800

Raj -

I have no problem in it becoming a WG item. Just think that some more
work is needed.

With static keys between MN and CN, now HA has no control.
With MIP, HA is still the anchor and I think it should have some
control on what the MN can and cannot do. With direct communication 
between MN and
CN, are we permiting communication without any control by HA? Am not 
sure if it
blends well in certain scenarios.

Alpesh

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Mar 2004 10:59:55 -0800

James Kempf wrote:
> looks at other RR improvements. 

I agree.

> Perhaps a dedicated design team might be appropriate?

a design team is too heavy a solution. I thought a design
team is needed when there are a lot of issues, no concensus
at all and a lot of missing things. this is not the case
with this document.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 17 Mar 2004 11:15:35 -0800

> at all and a lot of missing things. this is not the case

I didn't think we had that many issues nor lack of concensus on the
bootstrapping problem statement document, yet we have a design team there.
The criteria for a design team are not so clear cut I think.

Anyway, I'm happy with making it a WG draft, so long as the issues that were
brought up are addressed in some manner.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Mar 2004 18:29:45 +0200

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...

--Jari

---

From: Charlie P <[email-masked]>
Date: Wed, 17 Mar 2004 08:15:29 -0800

Hello Jari,

I am of course amenable to adding features to the draft
according to working group direction.  Adding the care-of
address as a feature would of course expand applicability,
and I agree with the usefulness of that specification.

However, I am reluctant to take up the work of doing
that if the document were still not interesting to the
working group.  I am also, as you know, quite happy
to explicitly delineate the appropriate applicability of
the protocol in both cases -- namely, with and without
the CoTI/CoT exchange.  It is my belief that this will
not present any major new specification difficulties,
given that CoTI/CoT is already specified in the base
document.

I never expected that the draft would be published
by the working group as is!

Regards,
Charlie P.