Subject: [netlmm] Updated MN-MAG interface draft

From: Julien Laganier <[email-masked]>
Date: Mon, 14 May 2007 18:06:39 +0200

Folks,

I've updated the MN-*MAG* interface draft to reflect 
discussions we had in the WG (per-MN subnet, pt-2-pt 
link, etc.). You can read a pre-version there:

<http://julien.laganier.free.fr/draft-ietf-netlmm-mn-ar-if-pre02_20070514.txt>

Please read and comment on the mailing list.

Best,

--julien

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 May 2007 09:09:11 -0700

The dropping of shared link is IMHO based on a false
interpretation of the multilink subnet document and
unnecessarily restricts the domain of applicability.
As such, I would not be able to endorse this work
going forward.

Fred
[email-masked] 

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Monday, May 14, 2007 9:07 AM
> To: [email-masked]
> Subject: [netlmm] Updated MN-MAG interface draft
> 
> Folks,
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 May 2007 09:26:49 +0200

Fred, 

> As such, I would not be able to endorse this work

It is noted, and consequently you have been removed 
from the author list in today's revision of the draft:

<http://julien.laganier.free.fr/draft-ietf-netlmm-mn-ar-if-pre02_20070515.txt>

Best,

--julien

> > From: Julien Laganier
> > [mailto:[email-masked]] Sent: Monday, May
> > 14, 2007 9:07 AM
> > To: [email-masked]
> > I've updated the MN-*MAG* interface draft to
> > reflect discussions we had in the WG (per-MN
> > subnet, pt-2-pt link, etc.). You can read a
> > pre-version there:
> >
> > <http://julien.laganier.free.fr/draft-ietf-netlmm-
> >mn-ar-if-pre 02_20070514.txt>
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 15 May 2007 14:45:41 +0200

> Please read and comment on the mailing list.

Here are some random comments...

> 6.2.  MN_GET_ADDR_PARMS Sub-function
> 
>    The MN_GET_ADDR_PARMS function allows the MN to configure IP
>    addresses.  This can be achieved via different means, including:
> 
>    o  Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows the
>       MN to configure both link local and global unicast address(es).

In order to derive its link-local address with SLAAC the MN does not 
need to obtain any parameter from anybody.  So no need to send any 
message.  I'm not sure whether MN_GET_ADDR_PARMS corresponds to actually 
sending a message over the wire.

In same bulleted item maybe one needs to reference rfc2464 for Ethernet, 
draft-for-16ng and any other rfc corresponding to IPv6 over wireless 
link-layers for which NETLMM is pertinent.

Also, rfc2462 is being updated by draft-ietf-ipv6-rfc2462bis-08.

>    o  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]:
>       Allows the MN to configure global unicast address(es).  Typically
>       not used to configure link local unicast address(es).
> 
>    o  IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]: Allows the MN
>       to configure link local unicast address(es).

For deriving its link-local address with PPP the MN MUST send messages 
to negotiate the IID.  Again, I'm not sure whether MN_GET_ADDR_PARMS 
corresponds to an operation of sending a message.

Finally, I am not sure why the MN-AR interface draft drops the support 
for shared links.  This makes a clear assumption about where the netlmm 
protocol is going to be deployed.  But at the same time it is silent 
about that.

I completely agree with Fred about the fact that there are many false 
interpretations of the multilink subnet drafts.  In all cases I don't 
see why that draft can lead to a conclusion where the NETLMM protocol 
does not need to support shared links.

Or - maybe another draft is planned for shared links support?

Alex

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

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 15 May 2007 09:02:36 -0400

I also agree with Fred and Alex that we should consider shared links 
support so that the applicability does not become too constrained to a 
specific deployment environment.

The IETF developed protocol should be flexible enough for variety of 
deployment scenarios.

I remember there was a discussion about it during last IETF, but not 
sure if we had a general agreement on it.

Thanks
Ashutosh

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 May 2007 15:03:54 +0200

On Tuesday 15 May 2007 14:45, Alexandru Petrescu wrote:
> >    The MN_GET_ADDR_PARMS function allows the MN to
> > configure IP addresses.  This can be achieved via
> > different means, including:
> >
> >    o  Stateless Address Autoconfiguration (SLAAC)
> > [RFC2462]: Allows the MN to configure both link
> > local and global unicast address(es).
>
> In order to derive its link-local address with SLAAC
> the MN does not need to obtain any parameter from
> anybody.  

Yes, but it needs an RA to generate a global unicast 
using SLAAC. And to get quickly that RA, it sends an 
RS.

> So no need to send any message.  I'm not 
> sure whether MN_GET_ADDR_PARMS corresponds to
> actually sending a message over the wire.

See above RS and RA. And w.r.t. link local unicast, the 
MN needs to do DAD, so again message are sent over the 
wire.

> In same bulleted item maybe one needs to reference
> rfc2464 for Ethernet, draft-for-16ng and any other
> rfc corresponding to IPv6 over wireless link-layers
> for which NETLMM is pertinent.
>

s/is being/will be/ (2462bis isn't published yet)

> >    o  Dynamic Host Configuration Protocol for IPv6
> > (DHCPv6) [RFC3315]: Allows the MN to configure
> > global unicast address(es).  Typically not used to
> > configure link local unicast address(es).
> >
> >    o  IP Version 6 over PPP
> > [I-D.ietf-ipv6-over-ppp-v2]: Allows the MN to
> > configure link local unicast address(es).
>
> For deriving its link-local address with PPP the MN
> MUST send messages to negotiate the IID.  Again, I'm
> not sure whether MN_GET_ADDR_PARMS corresponds to an
> operation of sending a message.

Yes it needs to send message.

> Finally, I am not sure why the MN-AR interface draft
> drops the support for shared links.  This makes a
> clear assumption about where the netlmm protocol is
> going to be deployed.  But at the same time it is
> silent about that.

No, *this* interface doesn't make assumption about 
where to deploy NETLMM. This document targets 
Informative so it cannot restrict the scope of the 
Standard track NETLMM protocol. It restrict *its* 
scope to point-to-point link, which doesn't prevent 
another spec to define another interface suitable for 
shared links. It is also not silent about why it only 
supports point-to-point link -- the "Link Model" 
subsection describe the issues with shared link and 
why as a consequence only p2p links are supported by 
*this* interface.

> I completely agree with Fred about the fact that
> there are many false interpretations of the
> multilink subnet drafts.  

This is your opinion.

> In all cases I don't see why that draft can lead to a
> conclusion where the NETLMM protocol does not need to
> support shared links.

Again this draft does not lead to any conclusion 
regarding applicability or requirements of the NETLMM 
protocol. 

It simply define *one* interface which works for p2p 
links.

> Or - maybe another draft is planned for shared links

I cannot talk for others' plan. Off course you can 
write a draft if an interface supporting shared link 
is important to you.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 15 May 2007 16:00:58 +0200

Julien Laganier wrote:
>>> o  Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows
>>> the MN to configure both link local and global unicast
>>> address(es).
>> In order to derive its link-local address with SLAAC the MN does
>> not need to obtain any parameter from anybody.
> 
> Yes, but it needs an RA to generate a global unicast using SLAAC. And
> to get quickly that RA, it sends an RS.

YEs, but let's stay with the link-local address case (not global) for
this discussion.

>> So no need to send any message.  I'm not sure whether
>> MN_GET_ADDR_PARMS corresponds to actually sending a message over
>> the wire.
> 
> See above RS and RA. And w.r.t. link local unicast, the MN needs to
> do DAD, so again message are sent over the wire.

Yes, I agree.  So does this mean that MN-GET-ADDR-PARMS can actually be
a sequence of 3 messages (not just one) and a pre-determined amount of
wait time, ie DAD.

>> In same bulleted item maybe one needs to reference rfc2464 for
>> Ethernet, draft-for-16ng and any other rfc corresponding to IPv6
>> over wireless link-layers for which NETLMM is pertinent.
>> 

YEs, I agree.  Just to say good to mention it.

>>> o  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
>>> [RFC3315]: Allows the MN to configure global unicast address(es).
>>> Typically not used to configure link local unicast address(es).
>>> 
>>> o  IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]: Allows the
>>> MN to configure link local unicast address(es).
>> For deriving its link-local address with PPP the MN MUST send
>> messages to negotiate the IID.  Again, I'm not sure whether
>> MN_GET_ADDR_PARMS corresponds to an operation of sending a message.
>> 
> 

One message?  Several?

I'm asking because I am not sure what does mean for you (and co-authors)
"function" and "sub-function".

The draft seems to say that the "MN_ATTACH" function is constituted of
the sub-functions MAG_GET_MN_ID, MN_GET_ADDR_PARMS,
MN_GET_DEFAULT_ROUTER and MAG_GET_MN_MCAST_GROUPS.

Can MN_ATTACH happen without MAG_GET_MN_MCAST_GROUPS?

Actually, I am very much surprised by this manner of specifying the
MN-AR interface behaviour.

>> Finally, I am not sure why the MN-AR interface draft drops the
>> support for shared links.  This makes a clear assumption about
>> where the netlmm protocol is going to be deployed.  But at the same
>> time it is silent about that.
> 
> No, *this* interface doesn't make assumption about where to deploy
> NETLMM. This document targets Informative so it cannot restrict the
> scope of the Standard track NETLMM protocol. It restrict *its* scope
> to point-to-point link, which doesn't prevent another spec to define
> another interface suitable for shared links. It is also not silent
> about why it only supports point-to-point link -- the "Link Model" 
> subsection describe the issues with shared link and why as a
> consequence only p2p links are supported by *this* interface.

Ok, so this document is for use only on point-to-point links, and only 
with prefix-per-MN model.

It is strange though that same document refers to DHCP and to SEND and 
to DNA, all three being widely used on shared links and 
shared-prefixes-per-MN (not prefix-per-MN).

At the same time it is intended as INFORMATIONAL status, so it is 
something that can suggest one possible behaviour - I agree.

>> I completely agree with Fred about the fact that there are many
>> false interpretations of the multilink subnet drafts.
> 
> This is your opinion.

Yes.

>> In all cases I don't see why that draft can lead to a conclusion
>> where the NETLMM protocol does not need to support shared links.
> 
> Again this draft does not lead to any conclusion regarding
> applicability or requirements of the NETLMM protocol.
> 
> It simply define *one* interface which works for p2p links.

Could one please state in the document somewhere that DNA, DHCP and SEND 
have been widely used on shared links (not p2p).

> I cannot talk for others' plan. Off course you can write a draft if
> an interface supporting shared link is important to you.

Sure, sorry, I didn't mean to make a disturbing question.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 May 2007 17:16:16 +0200

On Tuesday 15 May 2007 16:00, Alexandru Petrescu wrote:
> >>> configure IP addresses.  This can be achieved
> >>> via different means, including:
> >>>
> >> In order to derive its link-local address with
> >> SLAAC the MN does not need to obtain any
> >> parameter from anybody.
> >
> > Yes, but it needs an RA to generate a global
> > unicast using SLAAC. And to get quickly that RA,
> > it sends an RS.
>
> YEs, but let's stay with the link-local address case
> (not global) for this discussion.

But you talk global bewow...

> >> So no need to send any message.  I'm not sure
> >> whether MN_GET_ADDR_PARMS corresponds to actually
> > See above RS and RA. And w.r.t. link local
> > unicast, the MN needs to do DAD, so again message
> > are sent over the wire.
>
> Yes, I agree.  So does this mean that
> MN-GET-ADDR-PARMS can actually be a sequence of 3
> messages (not just one) and a pre-determined amount
> of wait time, ie DAD.

Note that waiting time can be done in parallel with 
other steps if optimistic DAD is done.

> >> In same bulleted item maybe one needs to
> >> reference rfc2464 for Ethernet, draft-for-16ng
> >> and any other rfc corresponding to IPv6 over
> >> wireless link-layers for which NETLMM is
> >> pertinent.
> >>

Will be when it's published. It doesn't change much 
anyway.

> >>> global unicast address(es). Typically not used
> >> For deriving its link-local address with PPP the
> >> MN MUST send messages to negotiate the IID. 
> >> Again, I'm not sure whether MN_GET_ADDR_PARMS

This is specified in IPv6 over PPP and PPP spec. This 
document is not supposed to specify PPP.

> I'm asking because I am not sure what does mean for
> you (and co-authors) "function" and "sub-function".

The MN_ATTACH function happens is executed when the MN 
attaches. It is composed of sub function realizing 
distinct tasks. It's unrelated to the number of 
messages. The number of messages depends on the 
specific realization of the function. For example, 
DHCP address allocation can use two or four message 
exchanges.

> The draft seems to say that the "MN_ATTACH" function
> is constituted of the sub-functions MAG_GET_MN_ID,
> MN_GET_ADDR_PARMS, MN_GET_DEFAULT_ROUTER and
> MAG_GET_MN_MCAST_GROUPS.

Right.

> Can MN_ATTACH happen without

No, since MAG_GET_MN_MCAST_GROUPS? is a constituent of 
MN_ATTACH.
 
> Actually, I am very much surprised by this manner of
> specifying the MN-AR interface behaviour.

Well, as I said above, the interface isn't the place to 
specify DHCP, PPP, SLAAC, etc. These are defined in 
their own specifications.

The interface specification is the place describing 
what functions should be implemented at the interface, 
not how. How these are realized is dependent on the 
underlying link technology and on the deployment.

Independent of the way to realize the function, it is 
always required to configure addresses, get a router, 
etc.

> >> Finally, I am not sure why the MN-AR interface
> >> draft drops the support for shared links.  This
> >> makes a clear assumption about where the netlmm
> >> protocol is going to be deployed.  But at the
> >> same time it is silent about that.
> >
> > scope to point-to-point link, which doesn't
> > prevent another spec to define another interface
> > suitable for shared links. It is also not silent
> > about why it only supports point-to-point link --
> > the "Link Model" subsection describe the issues
> > with shared link and why as a consequence only p2p
> > links are supported by *this* interface.
>
> Ok, so this document is for use only on
> point-to-point links, and only with prefix-per-MN
> model.

Yes.

> It is strange though that same document refers to
> DHCP and to SEND and to DNA, all three being widely
> used on shared links and shared-prefixes-per-MN (not
> prefix-per-MN).

I don't see what's strange in this. Do you mean 
DHCP/SEND/DNA shall be used only on shared links and 
shared subnet per link? 

> At the same time it is intended as INFORMATIONAL
> status, so it is something that can suggest one
> possible behaviour - I agree.

Fine.

> >> In all cases I don't see why that draft can lead
> >> to a conclusion where the NETLMM protocol does
> >> not need to support shared links.
> >
> > regarding applicability or requirements of the
> > NETLMM protocol.
> >
> Could one please state in the document somewhere
> that DNA, DHCP and SEND have been widely used on
> shared links (not p2p).

Why should a document describing an interface for 
point-to-point links talks about usage of protocol X 
on a shared links??

-- julien

> > write a draft if an interface supporting shared
> > link is important to you.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 15 May 2007 22:16:07 +0200

[The reference you posted to this draft is no longer valid:
http://julien.laganier.free.fr/draft-ietf-netlmm-mn-ar-if-pre02_20070514.txt
  changed to:
http://julien.laganier.free.fr/draft-ietf-netlmm-mn-ar-if-pre02_20070515.txt]

Julien Laganier wrote:
>>>> MN_GET_ADDR_PARMS corresponds to actually sending a message 
>>>> over the wire.
>>> See above RS and RA. And w.r.t. link local unicast, the MN needs
>>>  to do DAD, so again message are sent over the wire.
>> 
>> Yes, I agree.  So does this mean that MN-GET-ADDR-PARMS can 
>> actually be a sequence of 3 messages (not just one) and a 
>> pre-determined amount of wait time, ie DAD.
> 
> Note that waiting time can be done in parallel with other steps if 
> optimistic DAD is done.

Right... I think other sub-functions of the MN_ATTACH function can also
be intertwined, making the the separation of functions in sub-functions
  probably superfluous.

>>>>  Ethernet, draft-for-16ng and any other rfc corresponding to 
>>>> IPv6 over wireless link-layers for which NETLMM is pertinent.
>>>> 
> Will be when it's published. It doesn't change much anyway.

Well... I'm not sure.

We are here on the MN-AR interface, so for example we should say what AR
sends to MN in order for MN to use DHCP instead of SLAAC.  The preferred
method in 2462 is to use 'M' bit whereas in 2462bis the tendency seems
to be no longer use that 'M' bit for this purpose.

It's probably true that this draft doesn't talk about 'M' bit in RA, or
'A' bit in prefix option... but the 16ng corresponding draft does talk
about it.  And, if you agree that 16ng draft should be referenced here
then we end up with the necessity of commonly specifying (commonly
between this draft and the 16ng draft) that AR behaviour...

There are probably other news in 2462bis (compared to 2462) that may
influence the way MN-AR interface should happen.

>>>>> [RFC3315]: Allows the MN to configure global unicast 
>>>>> address(es). Typically not used to configure link local 
>>>>> unicast address(es).
>>>>> 
>>>>> o IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]: Allows 
>>>>> the MN to configure link local unicast address(es).
> This is specified in IPv6 over PPP and PPP spec. This document is not
>  supposed to specify PPP.

I agree... I think I'm understanding it better the more I'm reading it.
  It looks more and more that this is not a protocol specification but
more a documentation of software running on machines.  Probably its
informational status is fine.

>> I'm asking because I am not sure what does mean for you (and 
>> co-authors) "function" and "sub-function".
> 
> The MN_ATTACH function happens is executed when the MN attaches. It 
> is composed of sub function realizing distinct tasks. It's unrelated 
> to the number of messages.

I don't think all tasks are distinct.

Getting the MN ID happens at the same time as ND or DHCP, if the ID is
the MAC address.

> The number of messages depends on the specific realization of the
> function. For example, DHCP address allocation can use two or four
> message exchanges.
> 
>> The draft seems to say that the "MN_ATTACH" function is constituted
>>  of the sub-functions MAG_GET_MN_ID, MN_GET_ADDR_PARMS, 
> No, since MAG_GET_MN_MCAST_GROUPS? is a constituent of MN_ATTACH.
> 
> Well, as I said above, the interface isn't the place to specify DHCP,
>  PPP, SLAAC, etc. These are defined in their own specifications.
> 
> The interface specification is the place describing what functions 
> should be implemented at the interface, not how. How these are 
> realized is dependent on the underlying link technology and on the 
> deployment.

I don't read this document as a list of implementation instructions.  I 
read it as a documentation of what somebody may have implemented.

Also, I wanted to suggest that if this document is the result of a EU 
project Ambient Networks then it makes sense to have that project name 
in the title, maybe something like "Network-based Localized Mobility 
Management Interface between Mobile Node and Mobility Access Gateway in 
Ambient Networks".

>> It is strange though that same document refers to DHCP and to SEND 
>> and to DNA, all three being widely used on shared links and 
> I don't see what's strange in this. Do you mean DHCP/SEND/DNA shall 
> be used only on shared links and shared subnet per link?

Has one ever seen DHCP/SEND/DNA running on non-tunnel point to point 
links?  I haven't that's why I expressed my surprise.

I have seen DHCP and RS/RA over tunnel interfaces, but not on 
point-to-point links like ppp.

>> Could one please state in the document somewhere that DNA, DHCP and
>>  SEND have been widely used on shared links (not p2p).
> 
> Why should a document describing an interface for point-to-point 
> link talk about usage of protocol X on a shared links??

Right... maybe then put in the title "for point-to-point links".

Alex

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 15 May 2007 14:32:17 -0700

Hi Fred, Julien, 
I think it is incorrect to say that the shared link local behavior for
last hops was dropped due to multilink subnet issues.  We discussed this
topic in the Prague meeting and said that we still have some issues to
solve here with respect to domain-wide uniqueness of addresses when
DNAv6 is used, etc.  And, per our AD's recommendations that we first
deliver the prefix-per-MN model before taking on more items, it was
agreed that we will look at shared link support as a phased feature.  

So, the draft should reflect that shared link support may be revisited
when the work on the base protocol advances further.  Also, if a few
members want to start looking into it and doing some parallel work, that
would be fine too.  

We can summarize as above and work on shared link support in the next
phase.  Fred, I hope this is acceptable to you and hope that we can
still get you to contribute to the document.  

Regards,
Vidya

> Sent: Tuesday, May 15, 2007 12:27 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [netlmm] Updated MN-MAG interface draft
> 
> Fred, 
> 
> interpretation of 
> > the multilink subnet document and unnecessarily restricts 
> the domain 
> > of applicability.
> > As such, I would not be able to endorse this work going forward.
> 
> It is noted, and consequently you have been removed from the 
> author list in today's revision of the draft:
> 
> > > [mailto:[email-masked]] Sent: Monday, May 14, 
> 2007 9:07 AM
> > > To: [email-masked]
> discussions we 
> > > had in the WG (per-MN subnet, pt-2-pt link, etc.). You can read a 
> > > pre-version there:
> > >

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 May 2007 09:28:43 +0200

On Tuesday 15 May 2007 22:16, Alexandru Petrescu wrote:
> http://julien.laganier.free.fr/draft-ietf-netlmm-mn-
>ar-if-pre02_20070514.txt changed to:

Right: Fred wanted his name out of the draft, hence the 
update.

> >>>> whether MN_GET_ADDR_PARMS corresponds to
> >>> unicast, the MN needs to do DAD, so again
> >>> message are sent over the wire.
> >>
> >> messages (not just one) and a pre-determined
> >> amount of wait time, ie DAD.
> >
> > Note that waiting time can be done in parallel
> > with other steps if optimistic DAD is done.
>
> Right... I think other sub-functions of the
> MN_ATTACH function can also be intertwined, making
> the the separation of functions in sub-functions
> probably superfluous.

Yes they can be interlaced. I do not think the 
separation is superfluous since these are independent 
elementary tasks that need to occurs. Of course two 
tasks might be implemented with a single protocol 
(e.g. RS/RA exchange for router configuration and 
stateless address configuration), but also with 
distinct protocols (e.g. RS/RA exchange for router 
configuration and DHCP for statefull address 
configuration).

> We are here on the MN-AR interface, so for example
> we should say what AR sends to MN in order for MN to
> use DHCP instead of SLAAC.  The preferred method in
> 2462 is to use 'M' bit whereas in 2462bis the
> tendency seems to be no longer use that 'M' bit for
> this purpose.
>
> It's probably true that this draft doesn't talk
> about 'M' bit in RA, or 'A' bit in prefix option...
> but the 16ng corresponding draft does talk about it.
>  And, if you agree that 16ng draft should be
> referenced here then we end up with the necessity of
> commonly specifying (commonly between this draft and
> the 16ng draft) that AR behaviour...
>
> There are probably other news in 2462bis (compared
> to 2462) that may influence the way MN-AR interface
> should happen.

IMHO these are details, and we should reference 2462bis 
once it obsoletes 2462.

> >>>> For deriving its link-local address with PPP
> >>>> the MN MUST send messages to negotiate the IID.
> > This is specified in IPv6 over PPP and PPP spec.
> > This document is not supposed to specify PPP.
>
> I agree... I think I'm understanding it better the
> more I'm reading it. It looks more and more that
> this is not a protocol specification but more a
> documentation of software running on machines. 
> Probably its informational status is fine.

No this is not a protocol specification, protocol are 
specified in their standard track RFCs. This is a 
documentation of what should be implemented at minimum 
on this interface. A document with a somehow similar 
intent documents "Internet Protocol Version 6 (IPv6)
for Some Second and Third Generation Cellular 
Hosts" [RFC3316].

> >> I'm asking because I am not sure what does mean
> >> for you (and co-authors) "function" and
> >> "sub-function".
> >
> > The MN_ATTACH function happens is executed when
> > the MN attaches. It is composed of sub function
> > realizing distinct tasks. It's unrelated to the
> > number of messages.
>
> Getting the MN ID happens at the same time as ND or
> DHCP, if the ID is the MAC address.

As I said earlier, the fact the a task is distinct from 
another task doesn't mean both tasks can't happen by 
way of a single protocol.

Take the example of address configuration vs. router 
configuration. DHCPv4 does both. DHCPv6 does only the 
former, while Router Discovery does the latter.

[...]

> >> Actually, I am very much surprised by this manner
> >> of specifying the MN-AR interface behaviour.
> >
> > Well, as I said above, the interface isn't the
> > place to specify DHCP, PPP, SLAAC, etc. These are
> > defined in their own specifications.
> >
> > The interface specification is the place
> > describing what functions should be implemented at
> > the interface, not how. How these are realized is
> > dependent on the underlying link technology and on
> > the deployment.
>
> I don't read this document as a list of
> implementation instructions.  I read it as a
> documentation of what somebody may have implemented.

This is a documentation of what function *needs* to be 
implemented in the interface.

> Also, I wanted to suggest that if this document is
> the result of a EU project Ambient Networks then it
> makes sense to have that project name in the title,
> maybe something like "Network-based Localized
> Mobility Management Interface between Mobile Node
> and Mobility Access Gateway in Ambient Networks".

No it doesn't make sense. This interface isn't 
restricted to Ambient Networks. It's valid for 
point-to-point links between MAGs and MNs of a NETLMM 
domain.

Besides, this document is not the *result* of an EU 
projects, and nothing in it suggests so (If you read 
carefully the Acknowledgment Section, it says that 1. 
I'm "partly funded by Ambient Networks" and 2. the 
"views and conclusions contained herein are those of 
the authors and should not be interpreted as 
necessarily representing the official policies or 
endorsements, either expressed or implied, of the 
Ambient Networks project")

> >> DHCP and to SEND and to DNA, all three being
> >> widely used on shared links and
> > DHCP/SEND/DNA shall be used only on shared links
> > and shared subnet per link?
>
> Has one ever seen DHCP/SEND/DNA running on
> non-tunnel point to point links?  I haven't that's
> why I expressed my surprise.

You can't have seen everything. Even if you had, 
something new may appear in the future.

> I have seen DHCP and RS/RA over tunnel interfaces,
> but not on point-to-point links like ppp.

Ah. How do you think address configuration is done on 
the MN when PPP is used then?

> > point-to-point link talk about usage of protocol X
> > on a shared links??
>

This makes sense. However the title gets verbose:

"Network-based Localized Mobility Management Interface 
between Mobile Node and Mobility Access Gateway for 
Point-to-Point Link"

--julien