Re: issue-#49: Length indicator for Router Certificate sub-option

James Kempf wrote:

>All the length fields in CARD are 8 bits, which means restricts the size of
>messages to 254 bytes. This length is insufficient for certificates.
>
>An additional concern is that if the length field of the entire
>Request/Reply mesage is the same as the sub-option length field, the
>sub-option generator may want generate an option longer than would fit into
>the message, since this would be allowed by the field length. The solution
>for this in any case is for the sub-option generator code to respect the
>overall limits on the message length, in addition to the sub-option length.
>
>Proposal 1: Keep the length field size at 8 bits and make the units of
>length be 8 octets, for a maximum 1634 bits  or 2048 bytes.
>
>Proposal 2: Change the length field size to 16 bits, for a total of 65535
>bits or 8192 bytes.
>
>Suggested resolution: Proposal 2
>
>Reason: Proposal 1 could result in a maximum of up to 7 padding bytes of
>null data in an option or sub-option which is an extra overhead that is
>unnecessary and unwanted over the air.
>
>  
>
Well, this is only my opinion, but if we transmit certs of size > 1kbyte 
over the air with
a CARD Reply, who cares about 7 bytes padding... What bothers me with 
the 16-bit proposal is
that potentially the length of this sub-option can be much larger than 
the length of the option it
is encapsulated with, which is max 256 x 8bytes long. And even when 
having resolution of
1 byte with 16-bit length identifier, requirement for all sub-options is 
to take care about 32-bit
boundary alignment.
Hence, max overhead with proposal 1 is 4 bytes, right?

What do others think?

marco

>            jak
>
>
>
>_______________________________________________
>Seamoby mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>