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