Subject: Re: [Mip6] Re: I-D ACTION:draft-ietf-mip6-mipext-advapi-00.txt

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 12 Feb 2004 17:19:50 -0800 (PST)

> 
> I have a few comments on the draft.
>

Thanks. 
> 
> I noticed the syntax of the data structures and #defines changed from 
> the last version of the draft, for example:
> 
>    struct ip6mh_binding_update
> became
>    struct ip6_mh_binding_update
> 
> and
>    IP6MH_BU_ACK
> became
>    IP6_MH_BU_ACK

They were changed on version 02 that was submitted and presented at
last IETF. The change was made because of input I received.

> 
> I could let it go :) but it is now mixing syntax from IPv6 and ICMPv6. 
> I think if you're going to keep this change, which is like that in 
> icmp6.h, you should go all the way and fix all the data elements:
> 
>    ip6mhbu_seqno
> turns into
>    ip6_mh_bu_seqno
> 
> I like that better anyways since I always mis-typed those since you were 
> squishing all those chars together without a break.
> 

When we discussed the prefix, it was agreed to follow RFC3542 style - also
note that it was mentioned that there was no firm rule to follow everywhere.
There are inconsistencies in prefix in RFC3542 as well. We followed what
most people felt comfortable with.

For example, the prefix of ip6_mh_binding_ack { } structure is ip6mhba_<field>.

Why ip6mh ? Because it is part of ip6mh.h as opposed to ip6.h.

This is similar to the example in RFC3542:
 struct ip6_opt_jumbo {
        uint8_t  ip6oj_type;
        uint8_t  ip6oj_len;
        uint8_t  ip6oj_jumbo_len[4];
      };

Other option is to have a prefix ip6_mhba_<field>, but that looks a bit
odd, hence they are all suqeezed together. 

> 
> Another thing that would be good to do would be to #define all the 
> ip6_mh pieces in the sub-structs, for example:
> 
> struct ip6_mh_binding_error {
>      struct ip6_mh ip6_mh_be_hdr;
>      uint8_t  ip6_mh_be_status;
>      uint8_t  ip6_mh_be_reserved;
>      struct in6_addr ip6mhbe_homeaddr;   /* home address */
>      /* followed by mobility options */
> };
> 
> #define ip6_mh_be_proto   ip6_mh_be_hdr.ip6_mh_proto
> #define ip6_mh_be_len     ip6_mh_be_hdr.ip6_mh_len
> #define ip6_mh_be_type    ip6_mh_be_hdr.ip6_mh_type
> #define ip6_mh_be_cksum   ip6_mh_be_hdr.ip6_mh_cksum
> 
> That way users can use the shorthand, just like all the ICMPv6 structures.
> 
> 

I think it can be done. I'd like to know whether others think it's useful
or required to add. Note, this can be implemenation specific.

> You define the ip6_mh_opt structure, but no longer embed it in the opt 
> sub-types, for example:
> 
>    struct ip6_mh_opt_refresh_advice {
>             uint8_t  ip6mora_type;
>             uint8_t  ip6mora_len;
>             uint16_t ip6mora_interval; /* Refresh interval in 4 sec */
>    };
> 
> This could (was?, should?) be:
> 
>    struct ip6_mh_opt_refresh_advice {
>             struct ip6_mh_opt ip6_mh_opt_ra_hdr;
>             uint16_t ip6_mh_opt_ra_interval; /* Refresh interval in 4 sec */
>    };
> 
> #define ip6_mh_opt_ra_type    ip6_mh_opt_ra_hdr.ip6_mh_opt_type
> #define ip6_mh_opt_ra_len     ip6_mh_opt_ra_hdr.ip6_mh_opt_len
> 
> 

No. The option hdr is not embedded. Please check RFC3542 - it's the same
style of option hdr.

> The /etc/protocols entry should probably have an all-caps version for MH:
> 
> ipv6-mh           135      IPV6-MH  # Mobility Protocol Header
> 

The third argument is there in most of the implementations, but since this 
document
is an extension to RFC3542, I followed the semantics in RFC3542, where it
does not list the third field.

-Samita

> I don't know the precedence for this, but it's done that way in all the 
> different systems I looked at.
> 
> 
> I only noticed all these things since I updated my structs to the 
> previous draft, that will teach me...
> 
> Let me know if I'm too crazy about this,
> 
> -Brian
> 
> 
> [email-masked] wrote:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
> > This draft is a work item of the Mobility for IPv6 Working Group of the 
IETF.
> > 
> > 	Title		: Extension to Sockets API for Mobile IPv6
> > 	Author(s)	: S. Chakrabarti
> > 	Filename	: draft-ietf-mip6-mipext-advapi-00.txt
> > 	Pages		: 18
> > 	Date		: 2004-2-11
> > 	
> > This document describes data structures and API support for Mobile 
> >    IPv6 as an extension to Advanced Socket API support for IPv6. 
> > 
> > 
> >    Mobility Support in IPv6 introduces mobility protocol header
> >    for IPv6. It is expected that future Mobile IPv6 applications
> >    and implementations may need to access Mobility binding messages
> >    and Return Routability messages for diagnostic, packet accounting
> >    and local policy setting purposes. In order to provide portability
> >    for Mobile IP applications that use sockets under IPv6,
> >    standardization is needed for the Mobile IPv6 specific APIs.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-00.txt
> > 
> > To remove yourself from the IETF Announcement list, send a message to 
> > ietf-announce-request with the word unsubscribe in the body of the message.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-ietf-mip6-mipext-advapi-00.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-mip6-mipext-advapi-00.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip6

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

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Wed, 18 Feb 2004 22:01:00 +0900 (JST)

Hello Samita and Brian,

From: Samita Chakrabarti <[email-masked]>
Subject: Re: [Mip6] Re: I-D ACTION:draft-ietf-mip6-mipext-advapi-00.txt
Date: Thu, 12 Feb 2004 17:19:50 -0800 (PST)
> > squishing all those chars together without a break.

I was also surprised by this change.  (I did sed on my code :-)

But, I can go with the current draft.  At least, the convention is
consistent to me.  All member names are squeezed, all structure names
and macro names have a break.

> or required to add. Note, this can be implemenation specific.

This is a matter of teste, but, I like defining shortcuts.

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

---

From: Brian Haley <[email-masked]>
Date: Wed, 18 Feb 2004 15:50:43 -0500

> last IETF. The change was made because of input I received.

Ok.

> odd, hence they are all suqeezed together. 

Ok regarding this and the other RFC 3542 style comments, I just noticed 
the change...

> or required to add. Note, this can be implemenation specific.

Implementation-specific is fine, I just think most will want them.

-Brian