Subject: [netlmm] Draft Agenda for NETLMM at IETF68

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Mar 2007 13:50:57 -0800

Draft agenda

Network-based Local Mobility Management (NetLMM)

TUESDAY, March 20, 2007
0900-1130 Morning Session

Chairs: Phil Roberts <[email-masked]>; Vidya Narayanan
<[email-masked]>

---------------------------------------------------------

1. Agenda review, Blue sheets and volunteers for taking notes and Jabber
scribe (5 Mins)

2. WG status (5 Mins)

3. draft-singh-netlmm-protocol - (Ajoy - 15 mins)

4. draft-sgundave-mip6-proxymip6 - (Sri - 15mins)

4. MN-AR interface draft (Julien - 10 mins)

5. PMIPv6-MIPv6 Interactions	(Gerardo - 30 mins) (Presentation:
5-10mins; Discussion: 20 mins)

6. IPv6 support - summary of link local and global addressing support
(TBD - 15 mins) (Presentation: 5 mins; Discussion: 10 mins)

7. IPv4 support in PMIPv6   (Raj - 30 mins) (Presentation: 5-10mins;
Discussion: 20 mins)

8. MN ID requirements for PMIPv6 (TBD - 15 mins)

9. Next Steps

---------------------------------------------------------------

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Mar 2007 15:26:35 -0800

> 8. MN ID requirements for PMIPv6 (TBD - 15 mins)

Isn't RFC 4283 sufficient for MN identifier? What are
we going to discuss in this slot?

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Tue, 6 Mar 2007 09:20:04 +0100

Folks, 

There hasn't been any progress on the MN-AR interface 
draft since last meetings. Also, the interface will be 
impacted by support (or not) of shared link on last 
hop (as I underlined in a previous note), and I think 
this is to be discussed under item 6 of the agenda. 
The current MN-AR interface also uses a SEND public 
key as a MN ID so that is also related to item 8 of 
the agenda.

For all of these reasons, I was thinking it might make 
sense not to discuss specifically the MN-AR draft 
(i.e. remove item 4), and use that time to discuss 
other topics such as item 6 and 8, or something else.

What do you think?

--julien

On Monday 05 March 2007 22:50, Narayanan, Vidya wrote:
> Chairs: Phil Roberts <[email-masked]>;
> Vidya Narayanan <[email-masked]>
>
> 1. Agenda review, Blue sheets and volunteers for
> taking notes and Jabber scribe (5 Mins)
>
> 2. WG status (5 Mins)
>
> 5. PMIPv6-MIPv6 Interactions	(Gerardo - 30 mins)
> (Presentation: 5-10mins; Discussion: 20 mins)
>
> 6. IPv6 support - summary of link local and global
> addressing support (TBD - 15 mins) (Presentation: 5
> mins; Discussion: 10 mins)
>
> 7. IPv4 support in PMIPv6   (Raj - 30 mins)
> (Presentation: 5-10mins; Discussion: 20 mins)
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Mar 2007 12:59:16 -0800

Hi Vijay,
RFC4283 is certainly good enough as the format for carrying this
information. However, in the case of MIP6, the MN gets to put the ID in
the option and hence, that works fine. In the case of PMIPv6, there must
either be a way to obtain an ID of the MN from the MN-AR interface
procedures or by some out-of-scope means. Some technologies may make the
assumption that the MN ID is available from authentication, which is not
always true - certainly not the case when the authentication method used
provides for ID privacy and in open networks. There has also been the
question of whether there needs to be a mechanism to generate a random
unique ID the first time the MN shows up in a PMIP domain. In general,
we need to decide what various types of IDs are supported, how are these
obtained by a MAG, and whether there are any collision concerns if
different MNs in the same domain used different types of IDs. 

Additionally, there was a question on whether we need to tie the ID used
to some kind of authorization (for e.g., when this ID is the CGA public
key of the MN, there is explicit authorization for that IP address) -
during discussions at the NETLMM interim meeting last year, we briefly
discussed whether some AAA-based authorized ID is needed for the MNs,
but, there was no conclusion. 

Vidya

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, March 05, 2007 3:27 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [netlmm] Draft Agenda for NETLMM at IETF68
> 
> Narayanan, Vidya wrote:
> 
> Isn't RFC 4283 sufficient for MN identifier? What are we 
> going to discuss in this slot?
> 
> Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Mar 2007 21:51:20 -0800

Narayanan, Vidya wrote:
> procedures or by some out-of-scope means. 

The current assumption is that the MAG obtains MN's
identifier from the MN-AR interface procedures,
typically access authentication.

Some technologies may make the
> provides for ID privacy and in open networks. 

If the MN used a pseudo-identity with the MAG, then
the MN does not want the MAG to know its identity.
The LMA however can obtain the true identity from the
AAA infrastructure.

> There has also been the

Why would this be specific to PMIPv6?

> but, there was no conclusion. 

A mobile node can have a valid identity *and* use CGA based
addresses at the same time. draft-sgundave-mip6-proxymip6-02
enables the use of CGA based address for the mobile node.
Anyway lets have this discussion to figure out if there is
an issue that needs to be addressed.

Vijay

---

From: qinxia <[email-masked]>
Date: Fri, 09 Mar 2007 17:04:06 +0800

Hello All,
       My new draft is available, please review it,
http://tools.ietf.org/wg/mipshop/draft-qin-mipshop-pmipro-00.txt

   This document defines route optimization protocol for Proxy Mobile     
   IPv6.  Proxy home test, concurrent proxy care-of test and handover     
   procedures are explained.  Proxy mobile agent uses cryptographically   
   generated home addresses so that no more home test is needed after     
   the initial home test.  Handover home keygen token is used during      
   handover in order to eliminate home test for the next proxy mobile     
   agent.  A different route optimization protocol is defined for inter-  
   proxy mobile agent operation if the correspondent node is not Mobile   
   IPv6 enabled.                                                          

your comments are sincerely welcome.

Best regards

Alice Qin

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Mar 2007 16:41:20 +0100

Vidya, how about adding a slot "SDO operationals"?

10minutes should suffice.

I can present the major RFCs talking about SDO IETF Relationships, 
during 5minutes.  Then there  can be 5minutes open mike.  Not 
necessarily to clarify any draft selection, not timeline clarification, 
and not to make any decision.

But just to give place for a topic important to this Working Group.

Recently the group received statements from other SDOs that are not 
Liaison statements.  In addition there is no Liaison for one of these 
SDOs.  In the WG there was much discussion about SDO operationals, so I 
consider support for this slot already happened on the mailing list.

What do you think?

Alex

> Chairs: Phil Roberts <[email-masked]>; Vidya Narayanan

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 10 Mar 2007 12:53:16 -0800

Alex,
As Phil and I requested already, we must stop this discussion on SDOs
now. 

The IETF receives requirements for a given problem from various venues
and in some cases, those venues are other SDOs. The IETF is not the end
user of technologies that it builds - so, we do need the end users to
tell us their needs. As already mentioned, those are requirements and
we, at the IETF, are responsible for designing the solutions, taking
into account all the requirements that we receive. It is in the IETF's
best interests to see that we offer a solution that will prevent
segmented, uninteroperable solutions in various deployments solving the
same problems. 

The IETF representatives and liaisons to the relevant SDOs are in touch
with the representatives from those SDOs on this topic. We have already
asked the other SDO participants to participate in the NETLMM WG and
provide technical feedback and comments. There is no need to waste more
time discussing other SDO operations.  

Regards,
Vidya

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Saturday, March 10, 2007 7:41 AM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: Slot for SDO Operationals (was: [netlmm] Draft 
> Agenda for NETLMM at IETF68)
> 
> I can present the major RFCs talking about SDO IETF 
> Relationships, during 5minutes.  Then there  can be 5minutes 
> open mike.  Not necessarily to clarify any draft selection, 
> not timeline clarification, and not to make any decision.
> 
> Recently the group received statements from other SDOs that 
> are not Liaison statements.  In addition there is no Liaison 
> for one of these SDOs.  In the WG there was much discussion 
> about SDO operationals, so I consider support for this slot 
> already happened on the mailing list.
> 
> What do you think?
> 
> Alex
> 
> Narayanan, Vidya wrote:
> > Draft agenda
> > 
> > 1. Agenda review, Blue sheets and volunteers for taking notes and 
> > Jabber scribe (5 Mins)
> > 
> > 2. WG status (5 Mins)
> > 
> addressing support

---

From: Katsutoshi Nishida <[email-masked]>
Date: Mon, 12 Mar 2007 15:53:50 +0900

Dear Chairs,

I believe below is still the latest version of the proposed agenda.

As I express in the separate e-mail, it would be efficient for making
progress to have clear agenda item for the discussion of WG document
decision.

This agenda item would be good to follow after "4. draft-sgundave-mip6-proxymip6".
And at the end of the discussion, we need to make a decision even it
might not be able to make everybody happy as usual in IETF, i.e. rough
consensus.

Please consider my proposal when you revise the agenda.

Best Regards,
Katsutoshi

On Mon, 05 Mar 2007 13:50:57 -0800

> Chairs: Phil Roberts <[email-masked]>; Vidya Narayanan

Regards,
Katsutoshi

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 12 Mar 2007 14:36:24 -0700

Hi Nishida-san,
The consensus call for document selection, as you know, is already in
progress on the mailing list. Decisions taken at the meeting are not
final anyway and they always need to be confirmed on the mailing list.
In this case, since we already have a call in progress, there is no need
to do a consensus call at the meeting. People are free to listen to the
draft presentations and open issues discussions before sending their
decision on the mailing list. At the end of the consensus call, we will
determine the consensus based on all the input we have received on the
list. 

Regards,
Vidya

> From: Katsutoshi Nishida [mailto:[email-masked]] 
> Sent: Sunday, March 11, 2007 11:54 PM
> To: Narayanan, Vidya
> Cc: [email-masked]; [email-masked]
> Subject: Re: [net] Draft Agenda for NETLMM at IETF68
> 
> Dear Chairs,
> 
> As I express in the separate e-mail, it would be efficient 
> for making progress to have clear agenda item for the 
> discussion of WG document decision.
> 
> And at the end of the discussion, we need to make a decision 
> even it might not be able to make everybody happy as usual in 
> IETF, i.e. rough consensus.
>

---

From: Katsutoshi Nishida <[email-masked]>
Date: Tue, 20 Mar 2007 15:26:47 +0900

Hi Vidya, 

Sorry for being very late to respond this.

I agree your statement that the consensus call is ongoing and today's
meeting is not the place to make the decision.

My intension was that it would helpful a lot for people to understand
two drafts if we have much time to discuss them in addition to the
15min presentations for each draft introduction.

Hope this can be agreeable.

Best Regards,
Katsutoshi

On Mon, 12 Mar 2007 14:36:24 -0700

Regards,
Katsutoshi