Subject: Re: [Mipshop] AD review of draft-ohba-802dot21-basic-schema

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 5 Oct 2008 23:36:52 -0400

Jari,

Thank you for the review.

We will add sufficient explanation to the schema in <rdfs:comment>
fields in the schema as well as a list of acronyms and more
references.  Please see my comment in line.

On Fri, Sep 26, 2008 at 01:32:43PM +0300, Jari Arkko wrote:
>
> This was submitted as an individual submission for informational RFC. I  
> have made my AD review on it. My detailed comments and questions are  
> below. Overall, I think it is a good idea to document this type of a  
> schema, and we are certainly happy to do so when the IEEE wants us to.  
> However, the current draft version is not at all self contained and its  
> very hard to understand what the different information pieces should  
> carry, if you want to know it in exact enough detail to actually  
> implement something. I would suggest revising the draft one more time  
> before we move forward by adding sufficient explanations in comments  
> about the individual data items and their format, semantics and  
> dependencies.
>
> I will also have to find an RDF expert to review this from that  
> perspective before we move forward. But I'm waiting for a doc revision  
> before doing that, because I think that expert will have same issues  
> that I had in understand what the document wants to do.
>
> Issues:
>
>>    A value of Operator Type:
>>    0: GSM/UMTS
>>    1: CDMA
>>    2: REALM
>>    3: ITU-T/TSB
>>   
>
> This is underspecified. I do not know what kind of value to fill when  
> the type is any of these values. Please specify the format.

I took a look at 802.21 specification, but the format is ambiguous
except for REALM one.  We can probably add detailed text for REALM and
add a note that 802.21 specification is not clear for other types
(expecting the 802.21 WG to remove the ambiguity in this or the next
revision of 802.21 specification).

>
>> <owl:DatatypeProperty rdf:ID="ie_country_code">
>>   <mihbasic:ie_identifier>0x10000003</mihbasic:ie_identifier>
>>   <rdfs:domain rdf:resource="#NETWORK"/>
>>   <rdfs:range rdf:resource="&xsd;string"/>
>>  </owl:DatatypeProperty>
>>   
> Does this mean that you are using some string-based country names, e.g.,  
> "FI" or numeric E.164 country codes, e.g., 358? Please specify.

This is two-letter country code defined in ISO 3166-1.  We will add
explanation on it with a normative reference to ISO 3166-1.

>
>> <owl:Class rdf:ID="COST">
>>   ...
>>     <owl:onProperty rdf:resource="#cost_unit"/>
>>     <owl:onProperty rdf:resource="#cost_value"/>
>>     <owl:onProperty rdf:resource="#cost_curr"/>
>>   
>
> Can a cost entry appear multiple times? I'm trying to understand if this  
> representation will allow different options, e.g., flat fee $20 or $1  
> per minute. Then again, I'm not sure how the overall model of 802.21  
> fits with payment options in the same way as in current web-based login  
> model.

Since there is a <owl:cardinality> restriction of 1 on each of
cost_unit, cost_value and cost_curr, only one entry is allowed for a
single COST class object.  However, it is possible to include multiple
ie_cost object property entries (i.e., multiple COST class objects) in
a single NETWORK class object.  This way, multiple payment options for
a single netowrk can be supported in the basic schema.  We will add
text to explain it.

>
>>    7: free
> How is this different from, say, a flat rate with price of zero?

It seems that 802.21 specification is not clear enough to answer to
your question here, but I would say "free" may not be exactly the same
as a flat rate with price of zero in terms of detailed semantics.  For
example, flat rate may at least need to distinguish users (e.g., via
network access authentication) while free may not require to
distinguish users.

>
>>    A three-letter currency code(e.g., "USD") specified by
>>    ISO 4217.
>>   
> This should be a normative reference.

OK.

>
>>    This class has properties that represent geographic coordinate.
>>    The format is based on the Location Configuration Information (LCI)
>>    defined in RFC 3825 <http://tools.ietf.org/html/rfc3825>.
>>   
> Another normative reference needed here. (And what does "based on" mean,  
> exactly? Either you use that format or you need to define the format 
> here.)

Will add a normative reference to RFC 3825.  I agree that "based on"
here is ambiguous.  It means that we define RDF data properties
corresponding to the fields (such as LaRes, Latitude, LoRes,
Longitude, etc.) in the LCI option defined in RFC 3825.  We will add
more explanation here.

>> <owl:ObjectProperty rdf:ID="min_pk_tx_delay">
>>   
> I wish there was an explanation somewhere what this and other class of  
> service parameters can convey and what they cannot. The model seems  
> relatively simple. The implication is that it cannot necessarily  
> represent everything. For instance, packet transmit delay alone tells me  
> very little without knowing what size packets we are talking about. And  
> where's nominal bandwidth of the interface?

They are basically measured values (so packet sizes are based on
measurements).  The exact calculation for each QoS parameter is
described in Annex B of 802.21.  We can refer to Annex B of 802.21
specification on how the QoS parameters are calculated.

>
>>  <owl:DatatypeProperty rdf:ID="regu_domain_country_code">
>>   <rdfs:domain rdf:resource="#REGU_DOMAIN"/>
>>   <rdfs:range rdf:resource="&xsd;String"/>
>>  </owl:DatatypeProperty>
>>   
> Represented how?
>
>>  <owl:DatatypeProperty rdf:ID="regu_class">
> I did not understand what regu_class represents. Please specify. See  
> also below.

We will add detailed text for the classes and properties related to
regulatory domain.

>
>>   <rdfs:comment>
> Some of the objects have a comment, some don't. I was generally unable  
> to understand the ones without. Please consider adding comments at least  
> to all leaf object types.

We will add <rdfs:comment> whereever needed.

>
>>  <owl:DatatypeProperty rdf:ID="ie_net_frequency_bands">
> I did not understand exactly what you wanted to represent here. Its an  
> unsigned int, but in what units, hz, Mhz, etc? Is the frequency band  
> indicates as in 900 - 910 Mhz, i.e., as two numbers or with one? Please  
> specify in more detail.

This is in KHz.  We will add text on this.

>>  <owl:DatatypeProperty rdf:ID="ip_cfg_mthds">
> The options for this appear to be DHCP, FA, and access router. First of  
> all, its unclear to me what access router means in this context. An  
> access router can support any address configuration mechanism. Secondly,  
> does this list exclude stateless address autoconfiguration?
>>  <owl:DatatypeProperty rdf:ID="ie_net_supported_lcp">
>
> What does LCP stand for in here?

LCP stands for location configuration protocol.  We will add more
explanation on this property.

>
>>  <owl:ObjectProperty rdf:ID="ie_net_mob_mgmt_prot">
>>   
>
> Does this stand for *local* mobility management protocol, or something  
> else? Note that networks do not have to be involved in other mobility  
> management protocols. Or does this refer to the capability to handle 
> 802.21?

It seems that 802.21 specification is ambiguous as to whether it's
local or something else.  I think we can only add note the ambiguity
in <rdf:comment> at this moment (expecting the 802.21 WG to remove
the ambiguity in this or the next revision of 802.21 specification).

>
>>  <owl:ObjectProperty rdf:ID="ie_net_emserv_proxy">
>>   
> Proxy at what level?

This is an address of the proxy providing access to public safety
answering point (PSAP).  We will add text on this.

>
>>  <owl:DatatypeProperty rdf:ID="ie_net_mobile_network">
> I think you mean a mobile network in the NEMO sense. If so, please  
> clarify. "Mobile network" in the cellular terminology refers to a  
> network that support mobile hosts.

OK.

>
>>  <owl:ObjectProperty rdf:ID="ie_container_poa">
> What is a POA?

It's a network point of attachment.  We will add text on this.

>
>> <owl:DatatypeProperty rdf:ID="mac_addr">
>>   <rdfs:domain rdf:resource="#LINK_ADDR"/>
>>   <rdfs:range rdf:resource="#TRANSPORT_ADDR"/>
>>  </owl:DatatypeProperty>
>>
>>  <owl:Class rdf:ID="LINK_ADDR_3GPP_3G">
>>   <rdfs:subClassOf rdf:resource="#LINK_ADDR"/>
>>  </owl:Class>
>>
>>  <owl:DatatypeProperty rdf:ID="link_addr_3gpp_3g_cell_id_plmn_id">
>>   <rdfs:domain rdf:resource="#LINK_ADDR_3GPP_3G"/>
>>   <rdfs:range rdf:resource="&xsd;string"/>
>>  </owl:DatatypeProperty>
>>
>>  <owl:DatatypeProperty rdf:ID="link_addr_3gpp_3g_cell_id_cell_id">
>>   
> First, you need references to the documents that define the PLMN and  
> cell IDs and their format.

OK.

>
> Second, your model for 802 and 2/3G networks is very different. 2/3G  
> cellular networks do not use link layer addresses in the same sense as  
> they exist in Ethernet. Not sure we need to do anything about this, but  
> I hope the authors realize that there are significant differences.

Yes, we know that there are significant differences between cellular
and 802 link layers in terms of usage of link layer identifiers.
Celullar-related identifiers are somehow classified as LINK_ADDR, but
their main usages are to serve as identifiers for network points of
attachment.

>
>> <owl:DatatypeProperty rdf:ID="dcd_ucd_base_id">
>>   <rdfs:domain rdf:resource="#DCD_UCD"/>
>>   <rdfs:range rdf:resource="&xsd;unsignedShort"/>
>>  </owl:DatatypeProperty>
>>
>>  <owl:DatatypeProperty rdf:ID="bandwidth">
>>   <rdfs:domain rdf:resource="#DCD_UCD"/>
>>   <rdfs:range rdf:resource="&xsd;unsignedShort"/>
>>  </owl:DatatypeProperty>
>>
>>  <owl:DatatypeProperty rdf:ID="du_ctr_freq">
>>   <rdfs:domain rdf:resource="#DCD_UCD"/>
>>   <rdfs:range rdf:resource="&xsd;unsignedLong"/>
>>  </owl:DatatypeProperty>
>>
>>  <owl:DatatypeProperty rdf:ID="eirp">
>>   <rdfs:domain rdf:resource="#DCD_UCD"/>
>>   <rdfs:range rdf:resource="&xsd;unsignedByte"/>
>>  </owl:DatatypeProperty>
>>
>>  <owl:DatatypeProperty rdf:ID="ttg">
>>   <rdfs:domain rdf:resource="#DCD_UCD"/>
>>   <rdfs:range rdf:resource="&xsd;unsignedShort"/>
>>  </owl:DatatypeProperty>
>>
>>  <owl:DatatypeProperty rdf:ID="rtg">
>>   
> Explanations needed for all of these.

We will add exlanations.

>
>>    RFC3588 <http://tools.ietf.org/html/rfc3588>. The first 2-octet contains AddressType, which may be
> Reference needed.

OK.

>
>>  <owl:Class rdf:ID="IP_SUBNET_INFO">
>
> Can you send multiple subnet infos? IPv6 supports multiple prefixes.

Yes, multiple subnet infos can be sent.

>
> And what if the subnet information is dependent on whatever happens in  
> the network attachment phase. Proxy MIP, for instance, can choose the  
> prefix based on random selection (when the host joins the network for  
> the first time) or based on the identity of the host (as it moves  
> around). I hope the model supports this somehow.

I think the schema itself can support the model mentioned above.  To
realize this, 802.21 information service will need to support access
control based on user of a proper security mechanism.  A new Task
Group about 802.21 security is being prepared in IEEE 802, and MIH
access control will be covered by the new TG once it is formed.

>
>>  <owl:ObjectProperty rdf:ID="ie_poa_ip_addr">
> Whose address is this, the access routers? Link local, global? Or the  
> hosts? Again, can we have multiple?

This is an IP address of network point of attachment if it has an IP
address.  Since 802.21 specification is ambiguous as to whether it is
a link-local or global, I think we can only add note the ambiguity in
<rdf:comment> at this moment (expecting the 802.21 WG to remove the
ambiguity in this or the next revision of 802.21 specification).

Best Regards,
Yoshihiro Ohba

>
> Jari
>
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
>
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Oct 2008 22:29:09 +0300

Thanks for your mail. Everything you noted below seemed fine. I guess we
are then also waiting for the next revision of 802.21. When will that
happen?

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 8 Oct 2008 18:14:51 -0400

Since a next revision can depend on several things in IEEE, it is a
bit difficult to tell when that will happen.  I checked with 802.21 WG
Chair and Vice Chair and they are ok with revising the basic schema
I-D to add details including ones that are currently not specified in
802.21/D14.  The bottomline is that IEEE will incorporate changes to
be made in the basic schema I-D into a new revision of 802.21
specification in an appropriate procedure and with an appropriate
liaison relationship/statement whenever needed in order to maintain
the quality of 802.21 specification and consistency between IETF and
IEEE specifications.  This way, it is possible to publish the basic
schema I-D an an Informational RFC (and a persistent URL for the
schema) before waiting for a new revision of 802.21 specification.

Best Regards,
Yoshihiro Ohba