Subject: [Mip6] [issue54] Comments by Jari Arkko

From: Samita <[email-masked]>
Date: Fri, 07 Oct 2005 03:05:32 +0000

New submission from Samita <[email-masked]>:

Issue:

1st - agree with the comments in the I-D tracker.

2nd - I think this is a valid API and its standardization
is very useful. Overall, the document is in excellent shape.
Main my concern is what the document
says about its applicability:
 >   The applicability of this API mainly target user-level applications.
>   However, some Mobile IPv6 implementations may take advantage of this
>   API and implement part of the Mobile IPv6 protocol at the user-level.
>   It is up to the implementors to architect which part of the Mobile
>   IPv6 packet processing should be done at the user-level in order to
>   meet the design needs of the particular platform and operating system.
>   The target applications for this socket API is believed to be the 
>   debugging and diagnostic applications as well as some policy 
>   applications which would like to receive a copy of protocol 
>   information at the application layer. 
>
>   Note that user applications for transferring data between two
>   systems may not need to be mobility aware. Future IPv6 mobility
>   aware applications may use this socket API for per-packet
>   information for further processing at the application layer
>   program interface.
>  
>
This leaves the impression that its the regular applications
that would be using this. But I would actually see the use
of this API either as an partial implementation of Mobile IPv6
itself in the user space, the construction of new tools & options
over existing Mobile IPv6 (e.g. mh-ping, rr-ping etc), or
very special case applications. Other applications should
probably be using other, higher level APIs such as the
the address selection API. For instance, if the monami6
effort gets completed, there might be a need for a flow-based
API to provide information to the mobility layer about the
desired characteristics so that the multihoming policy
decisions can be made. But I wouldn't actually want to
see applications to use MH operations own their own
to do this control.

>   It is up to the implementors to architect which part of the Mobile
>   IPv6 packet processing should be done at the user-level in order to
>   meet the design needs of the particular platform and operating system.
>  
>
Perhaps you should warn already here that the implementation
ties itself also to IPsec processing. Maybe s/IPv6 packet/IPv6
and IPsec packet/

>  If the kernel
>  implementation supports this API, it is responsible for extracting
>  the Home address destination option data object and placing it as
>  destination option extension header in compliance with section
>  6.3 of Mobile IPv6 [2] base specification.

And 9.3.1, because presumably some IPsec processing may need
to take place.

Editorial:

>     struct mip6_prefix_advert {    /* Mobile Prefix Adverisements */
>
typo

>      appplications. This is captured in section 2.
>
typo

>   for Mobile Network [4] specific needs. Futhermore, it should be noted
>
typo

>    It is assumed that no portable applications will send routing hader
>
typo

>Expires: Novemebr, 2005                           Erik Nordmark 
>
typo

>   possible by priviledged users. However, this API does not prevent
>
typo

----
Accepted and fixed in the updated doc.

----------
category: Editorial
draft: draft-ietf-mip6-mipext-advapi
messages: 183
nosy: samita
priority: Should fix
status: Accepted
title: Comments by Jari Arkko

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue54>
_________________________________________________

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