Subject: [Mip6] Comments on draft-borst-mip6api-00.txt

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 2 Nov 2004 12:29:46 -0800 (PST)

I assume this document is an effort to identify usage cases and basic
API for MIP6 applications, which could be a feedback to another organization
which actually will create application level API.

I only had time to review the document in a haste, here are some general
comments.

- Please mention in the introduction and section 3 (goals and requirements)
  that the application level API should use "MIP6 Sockets API" to access
  low level data when applicable.
  
- This document discusses movement detection for "localized service discovery",
  but I assume that a mobile device would implement a "DNA" solution to 
  achieve movement detection at the system level. If it does not use RO,
  then MIP6 implementation takes care of updating HA with new COA. This 
  should be transparent to the mobileip user applications.
  If using RO, the MN/CN takes care of RO signaling and BU/BACK after
  finding out the movement as per DNA or other method specified in FMIP6.
  Some system apps may need to be involved in that detection - I don't
  see why applications need to know the movement at that point. 
  However, if the application wants to know when BUL or BCE gets updated,
  it can query the MIP6 system to find out its movement status given the
  current COA. An API may be needed at that level.
  
- A few API seem to be important for user level mobile APPs ( they are
  addressed in the draft) :
     -- whether it is home
     -- whether it has moved ( given the COA that it knows and home-addr)
     -- Lookup of entry of binding given the home-addr/(and may be interface
        for multi-interfaced nodes)
        [ Providing an API to retrieve all the entries in the list may
        not be so useful, IMHO. Instead entry lookup is more useful for
        apps. But for performance reason, in some cases the whole list
        is useful than going in a loop - perhaps both options are needed]
        
     -- Finding out its home-agent on a particular interface might be
        useful as well. Finding domain name might be useful from the
        ip-address.

 Hope this helps.
 
 -Samita

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

---

From: Mark Borst <[email-masked]>
Date: Wed, 03 Nov 2004 15:31:53 +0200

Hello

Thank you for your review. You will find my comments inline.

> which actually will create application level API.

We are not completely sure on the path to take with this draft, but at
least we have need for this API and are implementing it.

>   low level data when applicable.

This is actually an implementation requirement, which cannot be a
'requirement'. We have extensively thought about it, but it proves to be
more a burden than a benefit to use the "MIP6 Sockets API" in this case.
The thing is that you are then duplicating a lot of code that is already
in the MIPv6 stack, for instance for the movement detection. This is at
least valid for the MIPL platform. We could add it as a hint to
implementers though.

>   achieve movement detection at the system level. 

That is correct. The whole word 'detection' is not mentioned in the
draft. We leave the movement detection part completely to other
solutions, as are already implemented or otherwise available. We just
want to extract this information from the MIPv6 stack and present it to
applications.

> If it does not use RO,

The very point of this leads to the need for movement notification.
Maybe the explanation in section 2.1 is not so clear, so let me try to
give a very concrete example:

A mobile node is in its home network. It uses SLP to find the closest
printer, and uses that. Now the mobile node moves to another network. If
SLP doesn't know about the movement, it would still use the printer in
the home network. To solve this, one can enhance SLP for mobile
environments so that it rediscovers the closest printer when it knows
that the node has moved. SLP could for instance detect changes in
application level (SLP) packets. Or, the way we are proposing, it
requests movement notifications from this API that tell it that the node
has moved. The latter solution is in our opinion preferable.

It is all about telling applications that their environment has changed.
MIPv6 goes a long way to hide that, but this is not always desired.

>   current COA. An API may be needed at that level.

We provide this.
  
>   addressed in the draft) :

Provided.

>      -- whether it has moved ( given the COA that it knows and home-addr)

Provided.

>         is useful than going in a loop - perhaps both options are needed]

We provide both single-entry lookup and whole-list lookup as we think
they are both useful. However, we are open for other ideas.

>         useful as well. Finding domain name might be useful from the

That's a good point. We will take it along in our considerations.

>  Hope this helps.

It does. Thanks.

-- 
Mark Borst
Researcher
Network and Protocols Group
Tampere University of Technology, Finland

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 10 Nov 2004 07:01:08 -0800

>least valid for the MIPL platform. We could add it as a hint to
The API  is a specification for implementation. My suggestion was to 
include "MIP6 Socket API" as  one of the preferable options for 
underlying implementations. 

Thanks,
-Samita

---

From: Mark Borst <[email-masked]>
Date: Thu, 11 Nov 2004 12:15:53 +0200

On Wed, 2004-11-10 at 07:01 -0800, Samita Chakrabarti wrote:
> The API is a specification for implementation. 

I would rather say: The API is a specification of the external behaviour
of its implementations. I would say that leaves the actual
implementation up to the implementors.

> My suggestion was to 

I still don't think that the option can be 'preferable', but it
certainly can be an option and we can include a statement regarding
this.

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 11 Nov 2004 08:51:54 -0800

>implementation up to the implementors.

What is your definition of implementation?
I was distinguishing between implementation and protocol specification.

>certainly can be an option and we can include a statement regarding
All the interfaces defined in the APPLICATION api  do not need to use 
Socket APi extension
for obvious reasons. But  using socket API calls underneath this 
application api is preferable
for portability  wherever it is applicable.

-Samita

---

From: Mark Borst <[email-masked]>
Date: Thu, 11 Nov 2004 18:59:09 +0200

> I was distinguishing between implementation and protocol specification.

I think I misinterpreted your comment then. Yes, we are specifying an
implementation, not a protocol. 

I was meaning to say that we specify the outside behaviour of the black
box, not how the black box is working. So I meant with implementation:
the black box, ultimately object code, but originating from source code.
But I think we mean the same, just are saying it a bit differently.

> Socket APi extension for obvious reasons. But using socket API calls underneath this 
> application api is preferable for portability wherever it is applicable.

Agreed.

Regards,