Subject: Re: [Mip6] Status draft-ietf-mip6-advapi

From: Keiichi SHIMA <[email-masked]>
Date: Fri, 04 Nov 2005 19:21:20 +0900 (JST)

Hi Samita,

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 26 Oct 2005 14:37:37 -0700 (PDT)

> An updated version ( 05) of the MIP6API draft has been
> published on the 24th. Based on IESG comments and other's comments, the notable
> changes are:
  ...
>       - Introduced new Socket Options (IPV6_MIPDSTOPTS, IPV6_RECVMIPDSTOPTS)
>          for Home address destination option in order to avoid
>          complexity of extension header ordering at the kernel
>          on the outbound path.

IPV6_MIPDSTOPTS will make it clear where to insert the destination
option including a HAO.  I agree it is a good way to specify.

But, I'm not sure if we need IPV6_RECVMIPDSTOPTS is necessary.

Even now, we don't distinguish dstopts before RTHDR and after RTHDR
when receiving destination options.  Do we need to introduce
IPV6_RECVMIPDSTOPTS??

Regards,

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

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

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 11 Nov 2005 00:13:09 -0800

Hi Keiichi,

>when receiving destination options.  Do we need to introduce
This is a good point.  Since ADVAPI  IPv6 Sockets specifies that  one 
anciallry data
object will be returned for each destination option , it is safe to 
assume that one
RECVDST option will be sufficient for  all three cases of destination 
options. The user
needs to do inet6_opt_next(), inet6_opt_find() etc. 

However, the new socket options are added at the request of IESG 
evaluation ; the authors are waiting for the final review comments from  
Bill Fenner on this.

Thanks,
-Samita