Re: [802.21] Comments on 21-06-0674-00-0000-IE_TLV_Representation.doc
Qiaobing,
On Mon, Jun 26, 2006 at 03:42:32PM -0500, Qiaobing Xie wrote:
> 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.
I may be missing something but I am not aware of an existing query
method for TLV with the use of query language, though I know some
protocol such as CARD that defines limited queries for TLV.
>
> 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.
At the conceptual level, what XML/RDF/OWL/SPARQL can support can be
supported by TLV. However, I am really afraid TLV would need very
strict schema and query language definitions in order for the both
schemes to be equivalent. If we take a look at LDAP, it has a strict
schema and a query language (the representation is based on ASN.1,
though). I believe if we want/need to enrich TLV to support general
semantic queries, we would need the same effort as required for LDAP.
>
> > 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.
I guess LIST_OF_INCLUSION/EXCLUTION/CONDITIONS part is supposed to
be able to specify required filters to narrow down the result space.
> >
> > [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.
Does this mean location information should not be contained in the
conditions part? I guess not.
>
> >
> > [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?
SPARQL query is strict about relationship among resources.
For example, if the query is something like:
SELECT ?x ?y ?z WHERE {... }
to fetch information on x, y, z, then relationship among x, y, z is
specified in the WHERE clause. When the response is returned, the
querier can automatically relate the returned values to each other
based on the relationship specified in the query.
Regards,
Yoshihiro Ohba
>
> regards,
> -Qiaobing
>
> >
> >
> > Best regards,
> > Yoshihiro Ohba
> >