Re: [802.21] [FW: connection bet. action ID and TLV type value]
Hi, Kenichi,
Kenichi Taniuchi wrote:
> 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.
Of cause you don't have to start with 301; you can in fact just start
with 0 for *any* level of nested TLVs without ambiguity.
regards,
-Qiaobing
> 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 -----
>>>>>>
>>>>>>
>