Subject: [netlmm] Review: draft-sgundave-mip6-proxymip6-01 TEXT needs to be more specific to avoid confusion

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 14 Feb 2007 22:34:05 -0600

All,

I am writing this email with one objective in mind, to help advancing
the PMIPv6 draft forward. However, having read this draft several times
and followed the discussion on the mailing list, I feel that the draft
is written in a way that may lead to confusion or different
interpretation. I will explain why I believe it does so and I will
recommend a way out, hoping that the authors and members on this list
will comment to enhance it further.

According to the draft, the main objectives, as in the Abstract and
Introduction sections, are the followings:

1. Provide mobility support to any IPv6 host. 
2. This mobility is within a restricted and topologically localized
portion of the network.
3. IPv6 host is NOT required to participate in mobility related
signaling.
4. Allows the same HA to provide mobility support to CMIPv6 and
Non-CMIPv6 hosts. 
5. Although item 4 above does not explicitly mention the support for
CMIP/PMIP co-existence for the same user/MN, however based on the list
discussion and as per "support to any IPv6 host", it is considered
supported 

Abstract:
"....... This protocol is for providing mobility support to any IPv6
host within a restricted and topologically localized portion of the
network and without requiring the participation of the host in any
mobility related signaling."

Excerpt from Introduction section:
"..... Further, the Proxy MIPv6 solution described in this document
allows the same Home Agent to provide mobility to hosts that use Mobile
IPv6 and hosts that do not use any mobility management protocol. Proxy
Mobile IPv6 provides solution to a real deployment problem."

Although the main objective of this draft is to propose a protocol that
would offer mobility to any IPv6 host without any participation from the
IPv6 host in the mobility signaling, the draft tries to address both
CMIP capable and non-CMIP MNs in the same wording at the same time. Most
of the time, this makes it very hard to follow the logic in the draft.
i.e. the common questions: Is this applicable for CMIP capable MN or
non-CMIP MNs. Below are some examples from the draft:

Example 1:
Proxy Mobile Agent (PMA)

         The proxy mobile agent is a functional element on the access
         router.  This is the entity that makes the mobile node believe
         it is on its home link, by emulating the home link properties.

[As far as IPv6 host which Non-CMIPv6 capable, there is no concept of
home and home link. So does this wording apply to CMIP capable MN only?
If yes, how, since mobile node definition refers to both. PMA definition
continues below,

         It registers the location of the mobile node to the home agent
         and establishes a tunnel for receiving packets sent to the
         mobile node's home address.

[Here mostly this text applies to Non-CMIP capable MN.] Is not this a
little confusing?

Example 2:
Mobile Node (MN):
         This document uses the term mobile node to refer to an IPv6
         host.  This specification does not require the mobile node to
         have the Mobile IPv6 client stack.

[OK. Then 'mobile node' is used to refer to both types of mobiles, CMIP
capable and non-CMIP capable. Should not it be clearer if we
differentiate between the two?]

Example 3:
Under section 3:
"
   Every mobile node that roams in a Proxy Mobile IPv6 network, would
   typically be identified by an identifier, such as NAI and that
   identifier will have an associated policy profile that identifies the
   mobile's home network prefix, permitted address configuration modes,
   roaming policy and other parameters that are essential for providing
   network based mobility service.
"  

[What does 'home network prefix' mean here?]
My understanding is: 
1. For non-CMIP MN, this means the prefix hosted on the LMA which works
similar to the HA for a CMIP-capable MN.
2. For CMIP-capable MN which is configured for example for CMIP only,
this home network prefix is the MN real home network prefix.
3. If configuration allows CMIP-capable MN to receive PMIP services and
assume that MN still can use CMIP, what is meant by this 'home network
prefix'?

For the "the mobile's home network prefix," to mean all of the above or
may be more, is too much.

Example 4:
Under the same section:
"
   Once a mobile node enters its Proxy Mobile IPv6 domain and performs
   access authentication, the network will ensure the mobile node is
   always on its home network and further ensures the mobile can always
   obtain its home address on the access link and using any of the
   address configuration procedures.  
"
Well, same comment as above. non-CMIP capable MN has no concept of home.

Example 5:
There are still several examples under this section but I like the
following one:
"
   ....  In any case, the mobile node will be able to obtain its home
address.
"

Although the text preceding this one is applicable to both CMIP-capable
& non-CMIP capable hosts, this conclusion is only applicable to CMIP
capable MN.

This goes on and on. My suggestion is the following:
1. The draft needs to briefly capture the objectives under the
Introduction section in order to be a reference for all sections to
follow (most already captured).

2. Identify two different terms for the CMIP-capable MN and one for
non-CMIP capable MN to avoid confusion.

3. The main theme of the draft should address PMIP for Mobiles which are
non-CMIP capable using the applicable terminologies, LMA, (MAG/PMA),
etc.

4. Since one of the major objectives of this draft is to allow
CMIP-capable MN to operate transparently on the PMIP enabled network, I
would suggest a whole section to address CMIP support. This section must
be dedicated to the details needed to explain how the PMIP protocol,
which is detailed in the rest of the draft, would actually allow CMIP MN
to work transparently. Under this section we need to mention
simultaneous PMIP and CMIP support for the same user/MN.

5. The draft should appropriately mention that the co-location of the
LMA and HA functionality is implementation specific. Also, hierarchical
PMIP needs to be mentioned but the draft should not go through any
details. Similar to what NEMO RFC3963 does when mentioning nested mobile
networks.

6. Finally, the clear separation between CMIP-capable and non-CMIP
capable hosts, as outlined above, makes the conclusion at the end of the
draft quite clear and reduces the amount of confusion and also helps
focus the discussion on the real issues if any.

Regards,
Ahmad

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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 14 Feb 2007 21:33:14 -0800 (PST)

Hi Ahmad,

Thanks for the comments. We are revising the draft and plan
to publish it after next week. We will go over each of these
comments and ensure there is no ambiguity. The draft evolved
with the initial focus on bringing a new concept to the stage,
later focussed on different technical aspects and defining
a scope and now the focus will be on the presentation. Its the
part of evolution of any draft. We appreciate your feedback
and will certainly address each and every comment. Since we
will present the draft in a week to 2 week time frame, it is
probably might be better to check these comments in the context
of the latest version since we would have taken care of some
of these comments anyways. We will do all that to enhance the
draft.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 14 Feb 2007 23:36:35 -0600

Thanks Sri. 
I will be looking forward for the new draft revision.

Regards,
Ahmad

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Thursday, February 15, 2007 2:33 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]; Vijay Devarapalli; Chowdhury, Kuntal
> Subject: Re: Review: draft-sgundave-mip6-proxymip6-01 TEXT 
> needs to be more specific to avoid confusion
> 
> 
> Hi Ahmad,
> 
> with the initial focus on bringing a new concept to the 
> stage, later focussed on different technical aspects and 
> defining a scope and now the focus will be on the 
> presentation. Its the part of evolution of any draft. We 
> appreciate your feedback and will certainly address each and 
> every comment. Since we will present the draft in a week to 2 
> week time frame, it is probably might be better to check 
> these comments in the context of the latest version since we 
> would have taken care of some of these comments anyways. We 
> will do all that to enhance the draft.
> 
> Regards
> Sri
> 
> > the PMIPv6 draft forward. However, having read this draft several 
> > times and followed the discussion on the mailing list, I 
> feel that the 
> > draft is written in a way that may lead to confusion or different 
> > Although the main objective of this draft is to propose a protocol 
> > that would offer mobility to any IPv6 host without any 
> participation 
> > from the
> > CMIP capable and non-CMIP MNs in the same wording at the same time. 
> > Most of the time, this makes it very hard to follow the 
> logic in the draft.
> > If yes, how, since mobile node definition refers to both. PMA 
> > definition continues below,
> >
> > [OK. Then 'mobile node' is used to refer to both types of mobiles, 
> > CMIP capable and non-CMIP capable. Should not it be clearer if we 
> > [What does 'home network prefix' mean here?] My understanding is:
> > 1. For non-CMIP MN, this means the prefix hosted on the LMA which 
> > works similar to the HA for a CMIP-capable MN.
> > 3. If configuration allows CMIP-capable MN to receive PMIP services 
> > and assume that MN still can use CMIP, what is meant by this 'home 
> > network prefix'?
> >
> > For the "the mobile's home network prefix," to mean all of 
> the above 
> > or may be more, is too much.
> >
> > Example 4:
> > Under the same section:
> > "
> > Although the text preceding this one is applicable to both 
> > CMIP-capable & non-CMIP capable hosts, this conclusion is only 
> > applicable to CMIP capable MN.
> >
> >
> > 3. The main theme of the draft should address PMIP for 
> Mobiles which 
> > are non-CMIP capable using the applicable terminologies, LMA, 
> > (MAG/PMA), etc.
> >
> > CMIP-capable MN to operate transparently on the PMIP 
> enabled network, 
> > I would suggest a whole section to address CMIP support. 
> This section 
> > must be dedicated to the details needed to explain how the PMIP 
> > protocol, which is detailed in the rest of the draft, would 
> actually 
> > allow CMIP MN to work transparently. Under this section we need to 
> > mention simultaneous PMIP and CMIP support for the same user/MN.
> >
> > LMA and HA functionality is implementation specific. Also, 
> > hierarchical PMIP needs to be mentioned but the draft should not go 
> > through any details. Similar to what NEMO RFC3963 does when 
> mentioning 
> > nested mobile networks.
> >
> > capable hosts, as outlined above, makes the conclusion at 
> the end of 
> > the draft quite clear and reduces the amount of confusion and also 
> > helps focus the discussion on the real issues if any.
> >
> >
> > Regards,
> > Ahmad
> >
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 15 Feb 2007 17:07:41 -0800

I second a lot of Ahmad's suggestions. In particular, I think the
following would be good: 

* Not use the term 'CMIP' - it is a term used in other SDOs, but, not a
term used at the IETF. "Client" in general is not limited to an end node
- for instance, there is a client in PMIP as well; it just happens to be
on a network node. The use of the term MN seems fine to me, but, using
MIP6 and PMIP6 must provide the necessary separation clearly anyway. So,
we probably don't need other terminology. 

* I like the idea of having a dedicated section on "MIP6-PMIP6
interactions" or something to that effect, instead of discussing such
interactions throughout the document. The document's primary focus is on
defining the PMIP6 protocol - so, that should be clear. The interactions
section can focus on the interworking between the two protocols and any
implications placed on MIP6. This would also be the place to address the
permitted models on the PMIP6 RHoA being used as the MIP6 CoA/HoA, etc. 

Vidya

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Wednesday, February 14, 2007 8:34 PM
> To: [email-masked]
> Cc: Vijay Devarapalli
> Subject: [netlmm] Review: draft-sgundave-mip6-proxymip6-01 
> TEXT needs to bemore specific to avoid confusion
> 
> 
> All,
> 
> I am writing this email with one objective in mind, to help 
> advancing the PMIPv6 draft forward. However, having read this 
> draft several times and followed the discussion on the 
> mailing list, I feel that the draft is written in a way that 
> may lead to confusion or different interpretation. I will 
> explain why I believe it does so and I will recommend a way 
> out, hoping that the authors and members on this list will 
> comment to enhance it further.
> 
> According to the draft, the main objectives, as in the 
> Abstract and Introduction sections, are the followings:
> 
> 2. This mobility is within a restricted and topologically 
> localized portion of the network.
> 3. IPv6 host is NOT required to participate in mobility 
> related signaling.
> 5. Although item 4 above does not explicitly mention the 
> support for CMIP/PMIP co-existence for the same user/MN, 
> however based on the list discussion and as per "support to 
> any IPv6 host", it is considered supported 
> 
> Abstract:
> "....... This protocol is for providing mobility support to 
> any IPv6 host within a restricted and topologically localized 
> portion of the network and without requiring the 
> participation of the host in any mobility related signaling."
> 
> "..... Further, the Proxy MIPv6 solution described in this 
> document allows the same Home Agent to provide mobility to 
> hosts that use Mobile
> IPv6 and hosts that do not use any mobility management 
> protocol. Proxy Mobile IPv6 provides solution to a real 
> deployment problem."
> 
> 
> Although the main objective of this draft is to propose a 
> protocol that would offer mobility to any IPv6 host without 
> any participation from the
> IPv6 host in the mobility signaling, the draft tries to 
> address both CMIP capable and non-CMIP MNs in the same 
> wording at the same time. Most of the time, this makes it 
> very hard to follow the logic in the draft.
> i.e. the common questions: Is this applicable for CMIP 
> capable MN or non-CMIP MNs. Below are some examples from the draft:
> 
> Example 1:
> Proxy Mobile Agent (PMA)
> 
> [As far as IPv6 host which Non-CMIPv6 capable, there is no 
> concept of home and home link. So does this wording apply to 
> CMIP capable MN only?
> [Here mostly this text applies to Non-CMIP capable MN.] Is 
> not this a little confusing?
> 
> Example 2:
> Mobile Node (MN):
> [OK. Then 'mobile node' is used to refer to both types of 
> mobiles, CMIP capable and non-CMIP capable. Should not it be 
> clearer if we differentiate between the two?]
> 
> Example 3:
> Under section 3:
> "
> 1. For non-CMIP MN, this means the prefix hosted on the LMA 
> which works similar to the HA for a CMIP-capable MN.
> 2. For CMIP-capable MN which is configured for example for 
> CMIP only, this home network prefix is the MN real home 
> network prefix.
> 3. If configuration allows CMIP-capable MN to receive PMIP 
> services and assume that MN still can use CMIP, what is meant 
> by this 'home network prefix'?
> 
> the above or may be more, is too much.
> 
> Example 4:
> Under the same section:
> "
> There are still several examples under this section but I 
> like the following one:
> "
>    ....  In any case, the mobile node will be able to obtain 
> its home address.
> "
> 
> CMIP-capable & non-CMIP capable hosts, this conclusion is 
> only applicable to CMIP capable MN.
> 
> 
> 1. The draft needs to briefly capture the objectives under 
> the Introduction section in order to be a reference for all 
> sections to follow (most already captured).
> 
> 2. Identify two different terms for the CMIP-capable MN and 
> one for non-CMIP capable MN to avoid confusion.
> 
> Mobiles which are non-CMIP capable using the applicable 
> terminologies, LMA, (MAG/PMA), etc.
> 
> 4. Since one of the major objectives of this draft is to 
> allow CMIP-capable MN to operate transparently on the PMIP 
> enabled network, I would suggest a whole section to address 
> CMIP support. This section must be dedicated to the details 
> needed to explain how the PMIP protocol, which is detailed in 
> the rest of the draft, would actually allow CMIP MN to work 
> transparently. Under this section we need to mention 
> 5. The draft should appropriately mention that the 
> co-location of the LMA and HA functionality is implementation 
> specific. Also, hierarchical PMIP needs to be mentioned but 
> the draft should not go through any details. Similar to what 
> NEMO RFC3963 does when mentioning nested mobile networks.
> 
> 6. Finally, the clear separation between CMIP-capable and 
> non-CMIP capable hosts, as outlined above, makes the 
> conclusion at the end of the draft quite clear and reduces 
> the amount of confusion and also helps focus the discussion 
> on the real issues if any.
> 
> 
> Regards,
> Ahmad
> 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 15 Feb 2007 17:37:32 -0800 (PST)

Hi Vidya,

On having a dedicated section on PMIP interactions,
I thought that's what we have today to the most extent.
Generally, should be ok, since the interactions can be
contained to a specific section.

On CMIP Mobile vs a PMIP mobile reference, we generally
tried to use descriptive text as supposed to some specific
terms. I agree, in couple of places we have it as CMIP.
We will try to keep clear seperation, one way are the
other, we will discuss and fix it in the next rev.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 15 Feb 2007 21:36:05 -0600

Hi Sri,

I would like to thank you and the rest of the authors for all the hard
work to get this draft to best shape possible. I am sure you guys are
working hard to get the new revision out as soon as possible. Because of
time constraint, It should be fine if the current revision you are
working on guys do not address all of these recommendation as long as we
have the understanding that it will be addressed at one point.

Many thanks once again.

Regards,
Ahmad

> Sent: Friday, February 16, 2007 10:38 AM
> To: Narayanan, Vidya
> Cc: Muhanna, Ahmad (RICH1:2H10); [email-masked]; Vijay Devarapalli
> Subject: RE: [netlmm] Review: 
> draft-sgundave-mip6-proxymip6-01 TEXT needs to bemore 
> specific to avoid confusion
> 
> 
> Hi Vidya,
> 
> On having a dedicated section on PMIP interactions, I thought 
> that's what we have today to the most extent.
> On CMIP Mobile vs a PMIP mobile reference, we generally tried 
> to use descriptive text as supposed to some specific terms. I 
> agree, in couple of places we have it as CMIP.
> We will try to keep clear seperation, one way are the other, 
> we will discuss and fix it in the next rev.
> 
> Thanks
> Sri
> 
> > * Not use the term 'CMIP' - it is a term used in other 
> SDOs, but, not 
> > a term used at the IETF. "Client" in general is not limited 
> to an end 
> > node
> > - for instance, there is a client in PMIP as well; it just 
> happens to 
> > be on a network node. The use of the term MN seems fine to me, but, 
> > using
> > MIP6 and PMIP6 must provide the necessary separation 
> clearly anyway. 
> > So, we probably don't need other terminology.
> >
> > interactions throughout the document. The document's 
> primary focus is 
> > on defining the PMIP6 protocol - so, that should be clear. The 
> > interactions section can focus on the interworking between the two 
> > protocols and any implications placed on MIP6. This would 
> also be the 
> > place to address the permitted models on the PMIP6 RHoA 
> being used as the MIP6 CoA/HoA, etc.
> >
> > Vidya
> >
> >> times and followed the discussion on the mailing list, I feel that 
> >> the draft is written in a way that may lead to confusion 
> or different 
> Abstract and 
> support for 
> >> CMIP/PMIP co-existence for the same user/MN, however based on the 
> >> list discussion and as per "support to any IPv6 host", it is 
> >> considered supported
> >>
> >> Abstract:
> document 
> >> IPv6 and hosts that do not use any mobility management protocol. 
> >> Proxy Mobile IPv6 provides solution to a real deployment problem."
> >>
> >>
> address both 
> logic in the 
> capable MN or 
> concept of 
> >>    identifier will have an associated policy profile that 
> identifies 
> >> the
> CMIP only, 
> services 
> >> protocol, which is detailed in the rest of the draft, 
> would actually 
> co-location of the 
> >> mentioning nested mobile networks.
> >>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 15 Feb 2007 21:24:17 -0800 (PST)

Hi Ahmad,

Thanks for this note. Also, over the last few months, we had some
good discussions in the mailing list and some very good comments
from you and others. We will try to make sure, all these comments
are properly addressed. It will take one or two revs from here to
bring the draft to a very good shape. We will try. Thanks again
for all these discussions.

Regards
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Feb 2007 12:20:03 +0100

Sri Gundavelli wrote:
> good discussions in the mailing list and some very good comments from
> you and others. We will try to make sure, all these comments are
> properly addressed. It will take one or two revs from here to bring
> the draft to a very good shape. We will try. Thanks again for all
> these discussions.

Sri, thanks for taking into account the large amount of discussion that
was made.  Both you and those who raised the comments (myself included)
have interest in that gets reflected in the draft.  The recent Ahmad and
Vidya comments I support as well.  To that end, an issue list is the
best way to deal with it.

On another hand, it is not yet clear whether this draft is a WG item or
not.  It indeed shows support from many parties but if one day it so
happens that this draft does not become a WG item then many will be
disappointed (myself included).

Also, if this draft is to be combined with other drafts (as WG item
selection procedure goes sometimes), then the combination will obviously
lead to some of the remarks raised fading out, and other issues fading in.

So I'm not sure how much new discussion around this draft, in its
current state, without seeing the modifications reflected, is useful to
anyone.

Alex

> Regards Sri
>> I would like to thank you and the rest of the authors for all the
>> hard work to get this draft to best shape possible. I am sure you
>> guys are working hard to get the new revision out as soon as
>> possible. Because of time constraint, It should be fine if the
>> current revision you are working on guys do not address all of
>> these recommendation as long as we have the understanding that it
>> will be addressed at one point.
>> 
>> Many thanks once again.
>> 
>> Regards, Ahmad
>> 
>> 
>>> -----Original Message----- From: Sri Gundavelli
>>> [mailto:[email-masked]] Sent: Friday, February 16, 2007 10:38
>>> AM To: Narayanan, Vidya Cc: Muhanna, Ahmad (RICH1:2H10);
>>> [email-masked]; Vijay Devarapalli Subject: RE: [netlmm] Review: 
>>> draft-sgundave-mip6-proxymip6-01 TEXT needs to bemore specific to
>>> avoid confusion
>>> 
>>> 
>>> Hi Vidya,
>>> 
>>> that's what we have today to the most extent. Generally, should
>>> be ok, since the interactions can be contained to a specific
>>> section.
>>> 
>>> On CMIP Mobile vs a PMIP mobile reference, we generally tried to
>>> use descriptive text as supposed to some specific terms. I agree,
>>> in couple of places we have it as CMIP. We will try to keep clear
>>> seperation, one way are the other, we will discuss and fix it in
>>> the next rev.
>>> 
>>> Thanks Sri
>>> 
>>>> I second a lot of Ahmad's suggestions. In particular, I think
>>>> the following would be good:
>>>> 
>>>> node - for instance, there is a client in PMIP as well; it just
>>>> 
>>> happens to
>>>> be on a network node. The use of the term MN seems fine to me,
>>>> but, using MIP6 and PMIP6 must provide the necessary separation
>>>> 
>>> clearly anyway.
>>>> interactions section can focus on the interworking between the
>>>> two protocols and any implications placed on MIP6. This would
>>> also be the
>>>>> -----Original Message----- From: Ahmad Muhanna
>>>>> [mailto:[email-masked]] Sent: Wednesday, February 14,
>>>>> 2007 8:34 PM To: [email-masked] Cc: Vijay Devarapalli 
>>>>> the PMIPv6 draft forward. However, having read this draft
>>>>> several times and followed the discussion on the mailing
>>>>> list, I feel that the draft is written in a way that may lead
>>>>> to confusion
>>> or different
>>>>> interpretation. I will explain why I believe it does so and I
>>>>> will recommend a way out, hoping that the authors and members
>>>>> 
>>> on this list
>>>>> 1. Provide mobility support to any IPv6 host. 2. This
>>>>> mobility is within a restricted and topologically
>>> localized
>>>>> portion of the network. 3. IPv6 host is NOT required to
>>>>> participate in mobility related signaling. 4. Allows the same
>>>>> HA to provide mobility support to CMIPv6 and Non-CMIPv6
>>>>> hosts. 5. Although item 4 above does not explicitly mention
>>>>> the
>>> support for
>>>>> CMIP/PMIP co-existence for the same user/MN, however based on
>>>>> the list discussion and as per "support to any IPv6 host", it
>>>>> is considered supported
>>>>> 
>>>>> Abstract: "....... This protocol is for providing mobility
>>>>> support
>>> to any IPv6
>>>>> network and without requiring the participation of the host
>>>>> in any mobility related signaling."
>>>>> 
>>>>> Excerpt from Introduction section: "..... Further, the Proxy
>>>>> MIPv6 solution described in this
>>> document
>>>>> allows the same Home Agent to provide mobility to hosts that
>>>>> use Mobile IPv6 and hosts that do not use any mobility
>>>>> management protocol. Proxy Mobile IPv6 provides solution to a
>>>>> real deployment problem."
>>>>> 
>>>>> 
>>>>> any
>>>>> from the IPv6 host in the mobility signaling, the draft tries
>>>>> to
>>> address both
>>>>> draft. i.e. the common questions: Is this applicable for CMIP
>>>>> 
>>> capable MN or
>>>>> Example 1: Proxy Mobile Agent (PMA)
>>>>> 
>>>>> router.  This is the entity that makes the mobile node 
>>>>> believe it is on its home link, by emulating the home link 
>>>>> properties.
>>>>> 
>>>>> home and home link. So does this wording apply to CMIP
>>>>> capable MN only? If yes, how, since mobile node definition
>>>>> refers to both. PMA definition continues below,
>>>>> 
>>>>> It registers the location of the mobile node to the home 
>>>>> agent and establishes a tunnel for receiving packets sent to
>>>>> the mobile node's home address.
>>>>> 
>>>>> Example 2: Mobile Node (MN): This document uses the term
>>>>> mobile node to refer
>>> to an IPv6
>>>>> Example 3: Under section 3: " Every mobile node that roams in
>>>>> a Proxy Mobile IPv6
>>> network, would
>>>>> typically be identified by an identifier, such as NAI and
>>>>> that identifier will have an associated policy profile that
>>> identifies
>>>>> the mobile's home network prefix, permitted address
>>>>> configuration modes, roaming policy and other parameters that
>>>>> are essential for providing network based mobility service. "
>>>>> 
>>>>> 
>>>>> [What does 'home network prefix' mean here?] My understanding
>>>>> is: 1. For non-CMIP MN, this means the prefix hosted on the
>>>>> LMA which works similar to the HA for a CMIP-capable MN. 2.
>>>>> For CMIP-capable MN which is configured for example for
>>> CMIP only,
>>>>> and assume that MN still can use CMIP, what is meant by this
>>>>> 'home network prefix'?
>>>>> 
>>>>> Example 4: Under the same section: " Once a mobile node
>>>>> enters its Proxy Mobile IPv6 domain
>>> and performs
>>>>> always on its home network and further ensures the mobile can
>>>>>  always obtain its home address on the access link and using
>>>>> any of the address configuration procedures. " Well, same
>>>>> comment as above. non-CMIP capable MN has no concept of home.
>>>>> 
>>>>> 
>>>>> Example 5: There are still several examples under this
>>>>> section but I like the following one: " ....  In any case,
>>>>> the mobile node will be able to
>>> obtain its home
>>>>> address. "
>>>>> 
>>>>> This goes on and on. My suggestion is the following: 1. The
>>>>> draft needs to briefly capture the objectives under the 
>>>>> must be dedicated to the details needed to explain how the
>>>>> PMIP protocol, which is detailed in the rest of the draft,
>>> would actually
>>>>> allow CMIP MN to work transparently. Under this section we
>>>>> need to mention simultaneous PMIP and CMIP support for the
>>>>> same user/MN.
>>>>> 
>>>>> conclusion at
>>>>> the draft quite clear and reduces the amount of confusion and
>>>>> also helps focus the discussion on the real issues if any.
>>>>> 
>>>>> 
>>>>> Regards, Ahmad
>>>>> 
>>>>> 
>>>>> _______________________________________________ netlmm
>>>>> mailing list [email-masked] 
>>>> _______________________________________________ netlmm mailing
>>>> list [email-masked] 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>