Re: [802.21] Comments on 21-06-0674-00-0000-IE_TLV_Representation.doc
Hi, Kalyan,
Please see my response to Yoshi.
Also, I think the IE_TLV_Representation proposal should work well with
the loc_info_over_tlv you mentioned below, right? At least that's my
intention. So, I fail to see your point that they are in conflict to one
other. Maybe I should take another look at the loc_info_over_tlv document.
regards,
-Qiaobin
Kalyan Koora wrote:
> Hello Together,
>
> I agree with Yoshi and also say not to complicate
> the IE-TLV representation at this stage.
> IMO: the present way (as defined in draft) provides
> a simple and flexible way of handling TLVs and also
> carrying other syntax like XML within TLVs.
> So, I propose to let it be simple.
>
> Further, 21-06-0674-00-0000-IE_TLV_Representation.doc
> also points on the query mechanisms which is not
> clearly defined in present .21 draft. The proposal
> 21-06-0606-01-0000_loc_info_over_tlv.doc already
> defines a simple mechnism.
> As Yoshi pointed out, we should atleast keep the
> boolean operations (and, or, not, ..) away from
> the queries in TLV at this stage.
>
> Regards,
> Kalyan
>
> -------- Original-Nachricht --------
> Datum: Fri, 23 Jun 2006 22:33:22 -0400
> Von: Yoshihiro Ohba <yohba@TARI.TOSHIBA.COM>
> An: STDS-802-21@listserv.ieee.org
> Betreff: [802.21] Comments on 21-06-0674-00-0000-IE_TLV_Representation.doc
>
>
>>Hi,
>>
>>As I promised in the ad-hoc meeting last week in Singapore, let me
>>send my comments on 21-06-0674-00-0000-IE_TLV_Representation.doc.
>>
>>Comments on 21-06-0674-00-0000-IE_TLV_Representation
>>----------------------------------------------------
>>
>>General Comment:
>>
>>The contribution tries to define the following things: (i)
>>relationship among IEs, (ii) how IEs that are related to each other
>>are encoded in TLVs, (iii) how query requests and responses are
>>encoded in TLVs and (iv) semantics of queries. I have to note that
>>these are already perfectly defined using XML/RDF/OWL/SPARQL. How can
>>we justify the effort of re-inventing the wheel for TLV-based query at
>>the LB stage? I believe the re-invention would require a significant
>>effort.
>>
>>Specific Comments:
>>
>>[1] In Section 6.3.4.1, the TLV IE representation is not as extensible
>>as basic/extended schema because the specification needs to be updated
>>to define a new IE.
>>
>>[2] Section 6.3.4.1 states: "For a given geophysical location, the top
>>level IE is the List of Neighboring Access Networks containing at
>>least 1 Network IE". This means that there is relationship between a
>>geophysical location and neighboring access networks, but without
>>explicitly carrying the geophysical location information in List of
>>neighboring networks IE, it is not possible to figure out what
>>geophysical location is associated with the IE by just parsing the IE.
>>
>>[3] If a querier is interested in only a particular IE carried in
>>other IE, is there a way to fetch only that particular IE? For
>>example, it is not acceptable in terms of efficiency if a Network IE
>>contains OPERATOR_IDENTIFICATION IE, ROAMING_PARTNERS IE, COST_IE,
>>NETWORK_SECURITY IE, QOS IE and POA IE, if the querier is interested
>>in NETWORK_TYPE IE only. The contribution requires more work on
>>filtering functionality.
>>
>>[4] Section 6.3.5 states: "MIIS Query: MIIS client sends
>>Information_query(QUERY_TLV) to MIIS server to initiate a query, where
>>QUERY_TLV has the following format:". "MIIS Query" should read "MIIS
>>TLV Query" because this encoding is not used by the other types of
>>queries (i.e., RDF_DATA, RDF_SCHEMA_URL and RDF_SCHEMA). Also,
>>"QUERY_TLV" should read "MIIS_TLV_QUERY".
>>
>>[5] Section 6.3.5 states: "MIIS Response: MIIS server sends
>>Information_response(RESPONSE_TLV) in response to a query, where
>>RESPONSE_TLV contains one or more returned IEs:" "MIIS Response"
>>should read "MIIS TLV Response" because this encoding is not used by
>>the other types of queries (i.e., RDF_DATA, RDF_SCHEMA_URL and
>>RDF_SCHEMA). Also, "RESPONSE_TLV" should read "MIIS_TLV_RESPONSE".
>>
>>[6] In Section 6.3.5, it is not clear for why QUERY_LOCATION IE is
>>specially handled while conditions on geophysical location can be
>>specified in LIST_OF_INCLUSION/EXCLUTION_CONDITIONS.
>>
>>
>>[7] In Section 6.3.5 states "Note, the inclusion/exclusion conditions
>>employs typical OR, AND, ==, !=, >, <, etc. operators and possibly
>>wildcards." Obviously a complete definition is needed, including how
>>operators are encoded, what kinds of operands are allowed, how
>>operands are encoded, what is the priorities among operators, how
>>parenthesises are encoded if the default priority of some operator
>>needs to be overrode. Specifying the operand part is a huge issue
>>including datatype definitions, how to specify a particular field/IE
>>of a particular IE. Note that this is equivalent to design a new
>>query language as well as a schema for TLV. I'd warn this effort can
>>take another one or two year before completion and we should not go
>>down the road. I'd suggest removing
>>LIST_OF_INCLUSION/EXCLUTION_CONDITIONS.
>>
>>[8] In Section 6.3.5, when multiple RETURNED IEs are contained in a
>>response, it is still not possible to figure out how the RETURNED IEs
>>are related to each other. The contribution does not seem to address
>>the problem of the current TLV queries either.
>>
>>
>>Best regards,
>>Yoshihiro Ohba
>
>