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

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
> 
>