Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.21] [FW: connection bet. action ID and TLV type value]



Another question is like that the TLV can not have
3rd level of nested TLVs.
Because the 3rd level of Type value starts from 301 but the value range
is from 0 to 255. So far MIH protocol has at most 2nd level of nested TLVs,
right ? That's why still it's survived.

In the fixed type value case, the number of TLV is less than 255.
So I don't see any problem with fixed type value. And also it's possible
not to think about the ordering of TLVs using fixed Type value if each
parameter
has a Type (e.g. Old Link ID TLV, Current Link ID TLV, New Link ID TLV).

Kenichi

Gupta, Vivek G wrote:
>   
>> -----Original Message-----
>> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of
>> Qiaobing Xie
>> Sent: Friday, April 27, 2007 10:09 PM
>> To: Kenichi Taniuchi
>> Cc: STDS-802-21@listserv.ieee.org
>> Subject: Re: [802.21] [FW: connection bet. action ID and TLV type
>>     
> 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.
>
>   
>> regards,
>> -Qiaobing
>>
>> Kenichi Taniuchi wrote:
>>     
>>> I also support static value of type.
>>> Dinamic value of type increases implementation cost,
>>> debuging cost and confusions. I don't see any benefit for using
>>> it so far.
>>>
>>> Kenichi
>>>
>>> Meylemans, Marc wrote:
>>>       
>>>> Personally I would prefer seeing 'static' TLV types assigned to
>>>>         
> these
>   
>>>> parameters, so that these TLV type values do not change when used
>>>>         
> with
>   
>>>> the same parameters but in different messages.
>>>> I would think that this makes implementation more
>>>>         
> straightforward...
>   
>>>> My 2 cents,
>>>> -Marc
>>>>
>>>> -----Original Message-----
>>>> From: Miriam Tauil [mailto:miriam@RESEARCH.TELCORDIA.COM]
>>>> Sent: Thursday, April 26, 2007 12:11 PM
>>>> To: STDS-802-21@listserv.ieee.org
>>>> Subject: Re: [802.21] [FW: connection bet. action ID and TLV type
>>>>         
>> value]
>>     
>>>> I'm referring to the message parameters. The same parameter in
>>>>         
>> different
>>     
>>>> messages can have a different TLV type.
>>>>
>>>> I hope this clarifies my question.
>>>> Thanks
>>>>
>>>> Miriam
>>>> -----Original Message-----
>>>> From: Qiaobing Xie [mailto:Qiaobing.Xie@MOTOROLA.COM]
>>>> Sent: Thursday, April 26, 2007 12:37 PM
>>>> To: STDS-802-21@listserv.ieee.org
>>>> Subject: Re: [802.21] [FW: connection bet. action ID and TLV type
>>>>         
>> value]
>>     
>>>> Hello Miriam,
>>>>
>>>>
>>>>         
>>>>> Hello,
>>>>>
>>>>> I was wondering if anybody can point me to the comment resolution
>>>>>           
> or
>   
>>>>> contribution that led to the change in assignment of the different
>>>>>           
> TLV
>   
>>>> type
>>>>
>>>>         
>>>>> values. I would be interested to look into the considerations for
>>>>>           
> this
>   
>>>>> change.
>>>>>
>>>>>           
>>>> Which TLV values are you referring to here (we have IE types,
>>>>         
> message
>   
>>>> parameter types, etc.)?
>>>>
>>>> regards,
>>>> -Qiaobing
>>>>
>>>>
>>>>         
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Miriam
>>>>>
>>>>>
>>>>> ----- End forwarded message -----
>>>>>
>>>>>