RE: DoCoMo Implementation Issues with CTP

James,

These seem like reasonable changes to me.

John

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> ext James Kempf
> Sent: 18 February, 2004 00:21
> To: [email protected]
> Cc: Raghu Dendukuri
> Subject: [Seamoby] DoCoMo Implementation Issues with CTP
> 
> 
> 
> DoCoMo is in the process of implementing CTP, and we came up with the
> following list of issues in the spec. Since none of them seem 
> particularly
> large, Allison suggested that we simply update the current 
> version of the
> document (which is now under review by the ROHC WG) in place, 
> without reving
> the document to a new version. She will make the changes.
> Below, a list of the issues and suggested changes to the 
> document to address
> them.
> 
> Any comments? Please let me know by March 6.
> 
>             jak
> 
> -------------------------------------------
> 
> 1) Section 2.5.1, pg. 10; Section 2.5.2, pg. 11; Section 
> 2.5.3, pg. 12;
> Section 2.5.4, pg. 13; Section 2.5.6, pg. 15 - 'V' flag
> 
> The spec allows CTP messages to carry both IPv4 and IPv6 
> addresses, but as a
> practical matter in the implementation, a CTP message will be 
> sent to the
> IPv4 or IPv6 address of a router. Processing the address of 
> the opposite
> version in the stack is complicated. Suggestion is to only 
> allow IPv4 or
> IPv6 addresses, but keep the flag field size at 2 bits in case further
> experience shows that there are reasons why both might be 
> sent. The router
> can issue separate messages if both addresses must be 
> changed,  Suggested
> change in text:
> 
> Replace: "When set to '10', indicate presence of both IPv6 
> and IPv4 Previous
> (New) addresses."
> With: "Values of '10' and '11' are reserved".
> 
> 2) Section 2.5.3, pg. 12 - Length of Algorithm field in CTD 
> message block.
> 
> The length of the algorithm field in the CTD message block is 
> shown as 17
> bits. It should be 16.
> 
> 3) Section 2.5.1, pg. 10; Section 2.5.2, pg. 11; Section 
> 2.5.3, pg. 12;
> Section 2.5.4, pg. 13; Section 2.5.6, pg. 15 - Length field.
> 
> The size of the message length field is currently 8 bits, and 
> the units for
> the length are in 8 octet words. This allows a maximum of 
> 2048 octets, which
> might not be enough for bundling large amounts of context if 
> padding is
> required. Suggestion is to increase the size of the field and 
> make it be
> units of octets, for a total of 65535 octets. This would only 
> involve moving
> the flags into the Reserved field, and would not otherwise modify the
> message.
> 
> Replace: In message diagram blocks, move Length to be 16 bits 
> rather than 8.
> 
> Replace: "Length    message length in units of 8 octet words"
> With: "Length    message length in units of octets"
> 
> 4) Section 2.5.1. pg. 9; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12;
> Section 2.5.4, pg. 13; Section 2.5.5, pg. 14; Section 2.4.6, 
> pg. 15 - IP
> address field size.
> 
> The message block diagrams show the size of the IP address fields as 4
> octets, but if the IP address is for IPv6, it will be 16.
> 
> Replace: In the message block diagrams, replace the final "|" 
> with a "~" to
> indicate a variable length field. Indicate variable length 
> field by putting
> "(4 or 16 octets)" after the text in the field.
> 
> 5) Section 2.5.3, pg. 12 - Key field in message diagram
> 
> Only 4 bytes are shown for the key field, but the key size 
> field allows
> 65535. The message diagram needs to be changed.
> 
> Replace: In the message diagram, replace the final "|" with a "~" to
> indicate a variable length field. Indicate the variable 
> length field by
> putting "(variable)" after the text in the field.
> 
> 
> 
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>