Re: [802.21] Comments on 21-06-0674-00-0000-IE_TLV_Representation.doc
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
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer