Re: [802.21] Comments on 21-06-0674-00-0000-IE_TLV_Representation.doc
Hi Kalyan,
On Mon, Jun 26, 2006 at 09:25:37AM +0200, 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.
The proposal was not accepted in the ad-hoc meeting either, mostly
because semantics of the query filter cluster is not clear enough.
Yoshihiro Ohba
> 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