Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt(ProblemStatement for bootstrapping Mobile IPv6 )

From: Gopal Dommety <[email-masked]>
Date: Wed, 02 Mar 2005 11:28:51 -0800

James and Junghoon,

Thank you for the comments. The suggestions are useful.

James,

You did have some comments in Section 9. Could you also send them out.

Alpesh,

do you have any concerns making the changes.

Thanks,
-Gopal

At 08:39 PM 2/17/2005 +0900, Junghoon Jee wrote:
>Hello James and ALL.
>It's very cool.
>Please see my comments inline.
>
>----- Original Message -----
>From: "James Kempf" <[email-masked]>
>To: <[email-masked]>; "Gopal Dommety" <[email-masked]>
>Sent: Friday, February 18, 2005 5:10 AM
>Subject: Re: [Mip6] WG LC: I-D 
>draft-ietf-mip6-bootstrap-ps-01.txt(ProblemStatement for bootstrapping 
>Mobile IPv6 )
>
>
> >
> > Here's my nonsecurity related comments on this draft.
> >
> > Overall: I think the draft is sound in general, and I like the separation
> > between mobility and access service provider. I believe this distinction is
> > clearly made. Less clear is the distinction between the access network
> > service provider and home network service provider, in the traditional
> > wireless sense. I think this needs to be clarified in order for this
> > document to clearly lay out the problem of roaming, in the traditional
> > wireless sense, and I think that might be what is leading to some of the
> > confusion on the list. I'll provide some suggestions for improvement below.
> >
> > 1) Section 1.3
> >
> > There are some terms that are used throughout the draft that are not well
> > defined. For example, trust relationship. I'd suggest adding the following
> > definitions to this section:
> >
> > trust relationship - In the context of this draft, trust relationship means
> > that two parties in question, typically the user of the mobile host and the
> > mobility or access service provider, have some sort of prior contact in
> > which the mobile host was provisioned with credentials.
>
> > These credentials allow the mobile host to authenticate itself to the 
> mobility or access
> > service provider and to prove its authorization to obtain service.
>
>I would like to change like below if my understanding of your terminology 
>is correct.
>"These credentials allow the mobile host to authenticate itself to the 
>mobility or access
>service --authorizer-- and to prove its authorization to obtain service"
>
> > infrastructureless relationship - In the context of this draft, an
> > infrastructureless relationship is one in which the user of the mobile host
> > and the mobility or access service provider have no previous contact 
> and the
> > mobile host is not required to supply credentials to authenticate and prove
> > authorization for service.
>
> > Mobility and/or network access service is provided without any 
> authentication or authorization.
> > Infrastructureless in this context does not mean that there is no 
> network infrastructure, such as
> > would be the case for an ad hoc network.
>
>The notable point of the above phrase is the use of "Mobility and/or 
>network access service" not
>"Mobility and/or network access authorizer".
>I like this so much. It's very clear.
>I hope to see this definition in the next version of this I-D.
>
> > credentials - Data or mechanism used by a mobile host to authenticate 
> itself
> > to a mobility or access network service provider and prove authorization to
> > receive service. User name/passwords, one time password cards,
> > public/private key pairs with certificates, biometric information, etc. are
> > some examples.
> >
> > I also think some of the terms need modification.  Here are those I would
> > suggest modifying:
> >
> > ASA
> >     Access Service Authorizer. A network operator that authenticates a
> > mobile host and establishes the mobile host's authorization to receive
> > Internet service.
> >
> > ASP
> >     Access Service Provider. A network operator that provides direct IP
> > packet forwarding to and from the end host.
> >
> > Serving Network Access Provider.
> >     A network operator that is the mobile host's ASP but not its ASA. The
> > roaming network accesss provider may or may not additionally provide
> > mobility service.
>
>What about changing the "Serving Network Access Provider" to "Roaming 
>Network Access Provider" ?
>This is not significant, it's just a choice.
>
> > Home Network Access Provider.
> >     A network operator that is both the mobile host's ASP and ASA. The home
> > network access provider may or may not additionally provide mobility 
> service
> > (note that this is a slighlty different definition from RFC 3775).
> >
> > IASP
> >     Integrated Access Service Provider. A service provider that provides
> > both authorization for network access and also provides mobility service.
> >
> > MSA
> >     Mobility Service Authorizer. A service provider that authorizes Mobile
> > IPv6 service.
> >
> > MSP
> >     Mobility Service Provider. A service provider that provides Mobile IPv6
> > service. In order to obtain such service, the mobile host must be
> > authenticated and prove authorization to obtain the service.
> >
> > Home Mobility Service Provider.
> >     A MSP that both provides mobility service and authorizes it.
> >
> > Serving Mobility Service Provider.
> >     A MSP that provides mobility service but depends on another service
> > provider to authorize it.
>
>What about changing the "Serving Mobility Service Provider" to "Roaming 
>Mobility Service Provider" ?
>
> > Roaming
> >     When the mobile host is receiving network access service from a network
> > other than its home network, it is said to be roaming.
> >
> > 2)  Section 6 needs to be modified to more clearly define roaming, 
> using the
> > terminology defined above. I would suggest rewriting paragraph 3 as 
> follows:
> >
> > If the mobile host is within the geographical area in which network access
> > service is not provided by its home network access service provider, the
> > mobile host is roaming. The home network access service provider in this
> > case acts as the access service authorizer, but the actual network 
> access is
> > provided by the serving network access provider. During the authentication
> > and authorization prior to the mobile host having Internet access, the
> > serving network access provider may simply act as a routing agent for
> > authentication and authorization back to the access service authorizer, or
> > it may require an additional authentication and authorization step itself.
> > An example of a roaming situation is when a business person is using a
> > hotspot service in an airport, and the hotspot service provider has a
> > roaming agreement with the business person's cellular provider. In that
> > case, the hotspot network is acting as the serving network access provider,
> > while the cellular network is acting as the access service authorizer. When
> > the business person moves from the hotspot network to the cellular network,
> > the cellular network is both the home access service provider and the 
> access
> > service authorizer.
>
>Yes it's clear.
>
> > Also, I think paragraph 5 would benefit from the following change:
> >
> > Mobility service using Mobile IPv6 is conceptually and possibly also in
> > practice separate from network access service, though of course network
> > access is required prior to providing mobility. Mobile IPv6 service enables
> > an IPv6 host to maintain its reachability despite changing its network
> > attachment point (subnets). A network operator providing Mobile IPv6 
> service
> > is called a mobility service provider (MSP). Granting Mobile IPv6 service
> > requires a host to authenticate and prove authorization for the service. A
> > network operator that authenticates a mobile host and authorizes mobility
> > service is called a mobility service authorizer. If both types of operation
> > are performed by the same operator, that operator is called a home mobility
> > service provider. If authentication and authorization is provided by one
> > operator and the actual service is provider by another, the operator
> > providing the service is called the serving mobility service provider. The
> > serving MSP must contact the mobile host's mobility service authorizer to
> > check the mobile host's authorization prior to granting mobility service.
>
>I like this way, if you agree with the change of the terminology.
>"If authentication and authorization is provided by one operator and the 
>actual service is provider by another, the operator providing the service 
>is called the "roaming" mobility service provider."
>This is also a choice.
>
> > Finally, I think that paragraph 8 needs modification. Here's a suggested
> > change:
> >
> > The service model defined here clearly separates the entity providing the
> > service from the entity that authentications and authorizes the service.
>
>This is the point what i like your expression.
>I think, we're using of terminology, "service provider" to express the 
>different entities.
>This point should be applied to the next version of this I-D.
>
>I think we can utilize this James' work to build-up our MIP6 bootstrapping 
>framework.
>
>--Junghoon
>
> > In the case of basic network access, this supports the traditional and
> > well-known roaming model, in which inter-operator roaming agreements 
> allow a
> > host to obtain network access in areas where their home network access
> > provider does not have coverage. In the case of mobility service, this
> > allows a roaming mobile host to obtain mobility service in the local
> > operator's network while having that service authorized by the home
> > operator. The service model also allows mobility service and network access
> > service to be provided by different entities. This allows a network 
> operator
> > with no wireless access, like, for example, an enterprise network operator,
> > to deploy a Mobile IPv6 home agent for mobility service while the actual
> > wireless network access is provided by the serving network access providers
> > with which the enterprise operator has a contract. Here are some other
> > possible combinations of ASPs and MSPs:
> >
> > I would drop paragraphs 4, 6, and 7, since they talk about mechanisms 
> rather
> > than the service model, and this section is really about the service model.
> >
> > The bullet list after paragraph 8 and paragraph 9 both look OK.
> >
> > I'll send comments on Section 9 in a separate message.
> >
> >             jak
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Mar 2005 11:33:36 -0800

> You did have some comments in Section 9. Could you also send them out.

Already posted.

            jak

---

From: "Alpesh" <[email-masked]>
Date: Thu, 3 Mar 2005 13:54:46 -0800

Junghoon:

Please see inline: 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Junghoon Jee
> Sent: Wednesday, February 16, 2005 1:44 AM
> To: [email-masked]; Gopal Dommety
> draft-ietf-mip6-bootstrap-ps-01.txt (ProblemStatement for 
> bootstrapping Mobile IPv6 )
> 
> Hello, Gopal
> 
> I would like to re-comment about this WG I-D.
> I think this I-D needs to be refined to clearly state about 
> the relationship between the network access service and 
> mobility service, & local home agent assignment issue.
> I raised 3 questions related with this as follows.
> 
> Q1. Should the network access service be always performed 
> when a MN bootstraps ? 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Section 6.  Network Access and Mobility services [Page 14] 
> Only having Mobile IPv6 service is not possible, since the 
> Mobile IPv6 protocol requires ability to send and receive 
> IPv6 packets.  
> => It seems that network access service should be always performed.

If I understand your question correctly, the network access service should
always be performed. Network access is required to send/receive packets.
Now, whether access authentication/authorization is performed or not is
another issue. Were you refering to this later case? 

> 
> Section 7.1  Mobility Service Subscription Scenario => There 
> is no words about network access service.

The last paragraph mentions this. What specific details were you looking
for?

> 
> Q2. Does we have to consider the case of  infrastructure-less 
> scenario when we develop a bootstrapping solution or not ?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~~~
> Section 7.4 Infrastructure-less scenario [Page 17] This 
> specific scenario is not supported in this document.  The 
> reason for this is described in Section 9.
> Section 9. Security Considerations
> Thus, the case of infrastructure-less network where there is 
> absolutely no pre-mediated trust is kept outside of scope of 
> this document.
> => It seems that we don't need to consider the 
> infrastructure-less scenario 
>      when we create a bootstrapping solution.

This is explicitly left outside the scope.
> 
> Q3. Does a bootstrapping solution should support local home 
> agent assignment or not ?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Section 5.1.2  Dynamic Home Agent Assignment [Page 10] Local 
> home agents
>       The mobile node's home ASP may want to allow a local roaming
>       partner ASP to assign a local home agent for the mobile node.
>       This is useful both from the point of view of communications
>       efficiency, and has also been mentioned as one approach 
> to support
>       location privacy.
> => What is the exact meaning of the 'useful' and 'also been 
> mentioned' ?
>      Is the local home agent function optional[MAY] ?

So, this is an ancillary need. It is definitely not must from this draft.

-a

> 
> draft-le-aaa-mipv6-requirements-03.txt
> Section 5.5.  Home agent allocation
>    Such functionality SHOULD also be considered when designing the AAA
>    support for MIPv6 solution.
> => It seems that we SHOULD support the local HA assignment function.
> I already know that draft-ietf-mip6-bootstrap-ps is not a I-D 
> that describe the requirement & 
> draft-le-aaa-mipv6-requirements was expired. 
> But i think that we have to decide about this because many 
> different approaches can be come out depending on our decision.
> 
> --Junghoon
> 
> From: "Gopal Dommety" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, February 16, 2005 5:11 AM
> Subject: [Mip6] WG LC: I-D 
> draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for 
> bootstrapping Mobile IPv6 )
> 
> 
> > 
> > Hello All,
> > 
> > 
> > This is a Working Group Last Call for the following I-D:
> > draft-ietf-mip6-bootstrap-ps-01.txt
> > Title:
> > Problem Statement for bootstrapping Mobile IPv6
> > 
> > Please note that the status intended for this I-D is 
> Proposed Standard.
> > 
> > Please review and post your comments by March 3rd, 2005.
> > 
> > -Chairs,
> > 
> > URL-ID is:
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-
> ps-01.txt
> >

---

From: "Alpesh" <[email-masked]>
Date: Thu, 3 Mar 2005 16:32:25 -0800

Gopal:

I will make the appropriate changes in general text and security
considerations as James pointed out. Also will incorporate the comments from
Junghoon. I am not inclined to changing 'serving' to 'roaming' as I pointed
out.  

-a

> Behalf Of Gopal Dommety
> Sent: Wednesday, March 02, 2005 11:29 AM
> To: Junghoon Jee
> Cc: [email-masked]; James Kempf; alpesh
> Subject: Re: [Mip6] WG LC: 
> I-Ddraft-ietf-mip6-bootstrap-ps-01.txt(ProblemStatement for 
> bootstrappingMobile IPv6 )
> 
> James and Junghoon,
> 
> > > Overall: I think the draft is sound in general, and I like the 
> > > separation between mobility and access service provider. 
> I believe 
> > > this distinction is clearly made. Less clear is the distinction 
> > > between the access network service provider and home 
> network service 
> > > provider, in the traditional wireless sense. I think this 
> needs to 
> > > be clarified in order for this document to clearly lay out the 
> > > problem of roaming, in the traditional wireless sense, 
> and I think 
> > > that might be what is leading to some of the confusion on 
> the list. I'll provide some suggestions for improvement below.
> > >
> > > 1) Section 1.3
> > >
> > > There are some terms that are used throughout the draft 
> that are not 
> > > well defined. For example, trust relationship. I'd suggest adding 
> > > the following definitions to this section:
> > >
> > > trust relationship - In the context of this draft, trust 
> > > relationship means that two parties in question, 
> typically the user 
> > > of the mobile host and the mobility or access service 
> provider, have 
> > > some sort of prior contact in which the mobile host was 
> provisioned with credentials.
> >
> >I would like to change like below if my understanding of your 
> >terminology is correct.
> >mobility or access service --authorizer-- and to prove its 
> >authorization to obtain service"
> >
> > > infrastructureless relationship is one in which the user of the 
> > > mobile host and the mobility or access service provider have no 
> > > previous contact
> > and the
> > > mobile host is not required to supply credentials to authenticate 
> > > and prove authorization for service.
> >
> >network access service" not "Mobility and/or network access 
> >authorizer".
> > > to a mobility or access network service provider and prove 
> > > authorization to receive service. User name/passwords, one time 
> > > password cards, public/private key pairs with certificates, 
> > > biometric information, etc. are some examples.
> > >
> > > I also think some of the terms need modification.  Here 
> are those I 
> > > would suggest modifying:
> > >
> > > ASA
> > >     Access Service Authorizer. A network operator that 
> authenticates 
> > > a mobile host and establishes the mobile host's authorization to 
> > > receive Internet service.
> > >
> > > ASP
> > >     Access Service Provider. A network operator that 
> provides direct 
> > > IP packet forwarding to and from the end host.
> > >
> > >     A network operator that is the mobile host's ASP but not its 
> > > ASA. The roaming network accesss provider may or may not 
> > > additionally provide mobility service.
> >
> > >     A network operator that is both the mobile host's ASP 
> and ASA. 
> > > The home network access provider may or may not 
> additionally provide 
> > > mobility
> > service
> > >     Integrated Access Service Provider. A service provider that 
> > > provides both authorization for network access and also 
> provides mobility service.
> > >
> > > MSA
> > >     Mobility Service Authorizer. A service provider that 
> authorizes 
> > > Mobile
> > > IPv6 service.
> > >
> > > MSP
> > >     Mobility Service Provider. A service provider that provides 
> > > Mobile IPv6 service. In order to obtain such service, the mobile 
> > > host must be authenticated and prove authorization to 
> obtain the service.
> > >
> > >     A MSP that provides mobility service but depends on another 
> > > service provider to authorize it.
> >
> > >     When the mobile host is receiving network access 
> service from a 
> > > network other than its home network, it is said to be roaming.
> > >
> > > If the mobile host is within the geographical area in 
> which network 
> > > access service is not provided by its home network access service 
> > > provider, the mobile host is roaming. The home network access 
> > > service provider in this case acts as the access service 
> authorizer, 
> > > but the actual network
> > access is
> > > provided by the serving network access provider. During the 
> > > authentication and authorization prior to the mobile host having 
> > > Internet access, the serving network access provider may 
> simply act 
> > > as a routing agent for authentication and authorization 
> back to the 
> > > access service authorizer, or it may require an 
> additional authentication and authorization step itself.
> > > An example of a roaming situation is when a business 
> person is using 
> > > a hotspot service in an airport, and the hotspot service provider 
> > > has a roaming agreement with the business person's cellular 
> > > provider. In that case, the hotspot network is acting as 
> the serving 
> > > network access provider, while the cellular network is 
> acting as the 
> > > access service authorizer. When the business person moves 
> from the 
> > > hotspot network to the cellular network, the cellular network is 
> > > both the home access service provider and the
> > access
> > > service authorizer.
> >
> >Yes it's clear.
> >
> > > Mobility service using Mobile IPv6 is conceptually and 
> possibly also 
> > > in practice separate from network access service, though 
> of course 
> > > network access is required prior to providing mobility. 
> Mobile IPv6 
> > > service enables an IPv6 host to maintain its reachability despite 
> > > changing its network attachment point (subnets). A 
> network operator 
> > > providing Mobile IPv6
> > service
> > > is called a mobility service provider (MSP). Granting Mobile IPv6 
> > > service requires a host to authenticate and prove 
> authorization for 
> > > the service. A network operator that authenticates a 
> mobile host and 
> > > authorizes mobility service is called a mobility service 
> authorizer. 
> > > If both types of operation are performed by the same 
> operator, that 
> > > operator is called a home mobility service provider. If 
> > > authentication and authorization is provided by one 
> operator and the 
> > > actual service is provider by another, the operator providing the 
> > > service is called the serving mobility service provider. 
> The serving 
> > > MSP must contact the mobile host's mobility service 
> authorizer to check the mobile host's authorization prior to 
> granting mobility service.
> >
> >"If authentication and authorization is provided by one operator and 
> >the actual service is provider by another, the operator 
> providing the 
> >service is called the "roaming" mobility service provider."
> >This is also a choice.
> >
> > > The service model defined here clearly separates the entity 
> > > providing the service from the entity that 
> authentications and authorizes the service.
> >
> >I think we can utilize this James' work to build-up our MIP6 
> >bootstrapping framework.
> >
> >--Junghoon
> >
> > > In the case of basic network access, this supports the 
> traditional 
> > > and well-known roaming model, in which inter-operator roaming 
> > > agreements
> > allow a
> > > host to obtain network access in areas where their home network 
> > > access provider does not have coverage. In the case of mobility 
> > > service, this allows a roaming mobile host to obtain mobility 
> > > service in the local operator's network while having that service 
> > > authorized by the home operator. The service model also allows 
> > > mobility service and network access service to be provided by 
> > > different entities. This allows a network
> > operator
> > > with no wireless access, like, for example, an enterprise network 
> > > operator, to deploy a Mobile IPv6 home agent for mobility service 
> > > while the actual wireless network access is provided by 
> the serving 
> > > network access providers with which the enterprise operator has a 
> > > contract. Here are some other possible combinations of 
> ASPs and MSPs:
> > >

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 4 Mar 2005 23:48:47 +0900

Alpesh,

> another issue. Were you refering to this later case? 

This confisuion came from the use of 'network access provider.
As i said, i like James' recommendation of  using the concept of the 'service authorizer'.
With my understaning is correct, 
In the Mobility service subscription scenario, both the network access service and the mobility service are required.
Howerver, only the mobility service authorizer does exist without network access service authorizer.
If you accept the use of James' comments, i have no more issue related with this.

> The last paragraph mentions this. What specific details were you looking
This question is in line with the first question.
What about changing this section with little modification by changing MSP to mobility service authorizer ?

7.1  Mobility Service Subscription Scenario

   Many commercial deployments are based on the assumption that mobile
   nodes have a subscription with a mobility service authorizer.  In particular, in
   this scenario the MN has a subscription with an mobility service authorizer, called the home
   service authorizer, for Mobile IPv6 service.  As stated in Section 6, the mobility service authorizer is
   responsible of setting up a home agent on a subnet that acts as a
   Mobile IPv6 home link.  As a consequence, the home mobility service authorizer should
   explicitly authorize and control the whole bootstrapping procedure.

   Since the MN is assumed to have a pre-established trust relationship
   with its home provider, it must be configured with an identity and
   credentials, for instance an NAI and a shared secret by some
   out-of-band means before bootstrapping, for example by manual
   configuration.

   In order to guarantee ubiquitous service, the MN should be able to
   bootstrap MIPv6 operations with its home mobility service authorizer from any possible access
   location, such as an open network or a network managed by an ASP,
   that may be different from the mobility service authorizer and may not have any
   pre-established trust relationship with it.

> This is explicitly left outside the scope.

In my understanding,
Infrastructure-less network means that there is no service authorizer.
If it's right, yes it is outside the scope of bootstrapping.

> So, this is an ancillary need. It is definitely not must from this draft.

Yes, i understand your opinion.
I think we need to clearly decide that,
it can be included in requirement items or not.

--Junghoon

---

From: "Alpesh" <[email-masked]>
Date: Fri, 4 Mar 2005 07:05:15 -0800

Junghoon:

As I noted in separate emails, I am adding James suggestions - in main text
as well as security considerations. There may be a bit more changes/cleanup.

-a

> From: Junghoon Jee [mailto:[email-masked]] 
> Sent: Friday, March 04, 2005 6:49 AM
> To: Alpesh; [email-masked]; 'Gopal Dommety'
> when a MN 
> > > bootstraps ?
> > > Section 6.  Network Access and Mobility services [Page 14] Only 
> > > having Mobile IPv6 service is not possible, since the Mobile IPv6 
> > > protocol requires ability to send and receive
> > > IPv6 packets.  
> > If I understand your question correctly, the network access service 
> > should always be performed. Network access is required to 
> send/receive packets.
> > Now, whether access authentication/authorization is 
> performed or not 
> > is another issue. Were you refering to this later case?
> 
> In the Mobility service subscription scenario, both the 
> network access service and the mobility service are required.
> Howerver, only the mobility service authorizer does exist 
> without network access service authorizer.
> > > Section 7.1  Mobility Service Subscription Scenario => 
> There is no 
> > > words about network access service.
> > 
> > The last paragraph mentions this. What specific details were you 
> > looking for?
> > 
> What about changing this section with little modification by 
> changing MSP to mobility service authorizer ?
> 
>    service authorizer, for Mobile IPv6 service.  As stated in 
> Section 6, the mobility service authorizer is
> > > Section 7.4 Infrastructure-less scenario [Page 17] This specific 
> > > scenario is not supported in this document.  The reason 
> for this is 
> > > described in Section 9.
> > > absolutely no pre-mediated trust is kept outside of scope of this 
> > > document.
> > > Q3. Does a bootstrapping solution should support local home agent 
> > > assignment or not ?
> > > Section 5.1.2  Dynamic Home Agent Assignment [Page 10] Local home 
> > > agents
> > >       efficiency, and has also been mentioned as one approach to 
> > > support
> > >       location privacy.
> > > I already know that draft-ietf-mip6-bootstrap-ps is not a 
> I-D that 
> > > describe the requirement & draft-le-aaa-mipv6-requirements was 
> > > expired.
> > > But i think that we have to decide about this because 
> many different 
> > > approaches can be come out depending on our decision.
> > > 
> > > --Junghoon
> > >