RE: [802.21] [FW: connection bet. action ID and TLV type value]
Dear all,
Thank you for mentioning the additional concern about the limitation of the
name space, limited by using 1 octet for the TLV type.
Counting roughly the TLV types that we currently are using:
44 (main TLVs in section 8.5)
+ 10 nested TLVs in 8.5
+ 10 nested TLVs in 8.6 = total of about 65 TLVs
.. we still have extra 190 TLVs types that we can define.
And even if anybody would be concern that this is not sufficient, what would
be the drawback of using 2 octets instead of 1 octet for the TLV type?
Most of the messages have less than 10 TLVs, so the only drawback that I can
think of is that message size would be 10 bytes larger. Is that too bad?
Please let me know your thoughts,
Regards
Miriam
-----Original Message-----
From: Subir Das [mailto:subir@research.telcordia.com]
Sent: Saturday, April 28, 2007 8:56 AM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] [FW: connection bet. action ID and TLV type value]
> value]
>
>> Kenichi/Mac,
>>
>> In terms of implementation, I've heard a lot of people saying that
>>
> they
>
>> feel this way is much clearer and less confusing and not hard to code
>>
> at
>
>> all. I think all of this is a just a matter of personal preference for
>> individual programmers.
>>
>> The only technical difference is that the previous approach allows 256
>> number space for parameters for the entire protocol and the new
>>
> approach
>
>> allows 256 number space for parameters for each message.
>>
> [Vivek G Gupta]
> And if you have multiple parameters of same Type in a particular
> message, this method makes it convenient to assign different Type values
> (which lie within the context of that message only) and thus leads to
> lesser confusion, as opposed to having to impose additional rules
> regarding order of these parameters.
>
Subir> I fact, we do not have multiple parameters of the same type.
D04 had this problem since we
had assigned a single type for Link identifier and tried to
use the same one for Old link and new
link identifiers and so on. We can simply avoid that
assigning separate Type values for each
of them. By this way we can avoid nested TLVs. Technically
both are fine, however, the current
method is little difficult to understand and enforces a few
things. For example, 'defined in messages'
in TLV structure is new to me. Also latest .16g draft is
using fixed type values for MIH messages.
Therefore, what is the real benefit of changing an exiting
representation?
>
>
>>>>>