Re: [802.21] Comments on 21-06-0674-00-0000-IE_TLV_Representation.doc
Yoshi,
Please see my comments in-line.
Yoshihiro Ohba wrote:
> 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.
TLV based query/response has been around for decades, nothing is
re-invented here. The Comment Assignment #3 from our May meeting is
meant to find resolution for LB comments 339, 345. I think leaving the
TLV broken and crippled is not going to help us solving LB comments.
After all, technical integrity should overrule procedural things.
Also as you noted above, the TLV representation can be improved to do
what XML/RDF/OWL/SPARQL can do. As to the amount of effort, I don't see
it as significant, as shown in 21-06-0674-00-0000-IE_TLV_Representation,
a couple of pages of TLV description already gives enough details to
start an implementation. As a comparison, you could do an exercise using
XML/RDF/OWL/SPARQL to show the same examples in the contribution.
> 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.
Yes, everyone seems to agree with that for a long time. But this doesn't
mean TLV should be left broken and crippled.
> [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.
The geophysical location is the UE's current location (we have an
ongoing discussion for adding UE's current location in the query).
"Neighbor" is only defined for a given location, i.e., without a
location, there is no neighbor. Nothing is new here.
> [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.
You list what IE(s) you want to return in the response in your
QUERY_TLV, as described in the contribution.
>
> [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".
OK.
>
> [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".
Ok.
>
> [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.
Location is the UE's current location and is not a condition (again we
have an ongoing discussion for adding UE's current location in the
query). So, if the querier (UE or IS client) knows about its location,
then it sends it along with the query in the hope that the server may do
some refinement on the response. If the querier does not know its
location, the server may use an approximate location to generate the
neighbor information. Again, keep in mind, "neighbor" is relative to a
location.
>
> [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.
In my time scale, it is one to two **day** worth of work to lay out the
condition/operator TLV details.
Keep in mind that the precise details of a particular field/IE are going
to be needed no matter what. It has nothing to do with TLV.
>
> [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.
1) The querier gets what it asked for. 2) your comment [3] above also
asks for this capability, but now you seems to say this is undesirable?
3) will XML do anything different in this example?
regards,
-Qiaobing
>
>
> Best regards,
> Yoshihiro Ohba
>