RE: [802.21] [FW: connection bet. action ID and TLV type value]
Colleagues,
My recollection on this issue is that Qiaobing championed the idea, and
at first there was substantial confusion and some resistance. He was
patient but firm on the concept, and as people grasped the concept, they
were persuaded that it was a tradeoff, and few had any strong feelings
about it. So the concept was approved and the main rationale was the
increase in the number of possible TLVs without enlarging the type
field.
The one aspect to the implementation of the concept in d5 that wasn't
clear, at least to me, was that the TLV space would be defined per
Message-ID. Somehow the thought was it would be per Service ID.
A long time ago, there was a discussion of having the TLV type fields be
part of the schema. We should check that there are no problems with the
schema or extensibility concepts as a result of this change.
Best Regards,
Michael
-----Original Message-----
From: ext Gupta, Vivek G [mailto:vivek.g.gupta@INTEL.COM]
Sent: Friday, April 27, 2007 10:22 PM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] [FW: connection bet. action ID and TLV type value]
> -----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 -----
> >>>
> >