Subject: [Ecrit] Review request for draft-ohba-802dot21-basic-schema

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 5 Aug 2009 13:19:09 +0300

We would need someone to review draft-ohba-802dot21-basic-schema with a
focus on the emergency services aspects (which are quite small). It would be
good to have someone who is also familiar with the IEEE 802.21 work. 

Ciao
Hannes

>-----Original Message-----
>From: Jari Arkko [mailto:[email-masked]] 
>Sent: 05 August, 2009 11:59
>To: Yoshihiro Ohba; Lisa Dusseault; Alexey Melnikov
>Cc: Ecrit Chairs; Subir Das
>Subject: Re: draft-ohba-802dot21-basic-schema
>
>Yoshihiro, Lisa, Alexey,
>
>Is there a new version of the draft that addresses the small 
>issues that I raised in my review? And Lisa/Alexey, is there a 
>way for me to get an RDF expert to review this document? I'm 
>not expert enough myself...
>
>Jari
>
>Jari Arkko wrote:
>> Yoshihiro, Subir,
>>
>> I apologize for taking too long with this. Is this matter 
>still relevant?
>>
>> I have finally reviewed the draft. I ended up doing a complete 
>> re-review, because the diffs from last time were too big, 
>and I didn't 
>> remember all my comments anyway. I think the contents of the scheme 
>> are largely OK, though there were a number of small issues noted 
>> below. The larger issues are whether the RDF schema is done 
>correctly, 
>> and various specialized content (specifics of some link layers, 
>> emergency call information, ..) in the draft. I would like 
>to ask help 
>> from Alexey and Lisa to find an RDF reviewer, and from 
>Hannes and Marc 
>> about the emergency issues. Do you know what kind of review 
>happened in 802.21 vs.
>> .11, .16, 3GPP, and 3GPP2 for their respective link-layer 
>related stuff?
>>
>> Anyway, my general idea is that my review and the above two reviews 
>> would be used to improve the scheme (if needed) and then we should 
>> just publish it. I confess that I'm on the fence about an IETF 
>> Informational document that goes through a Last Call, and an 
>RFC Editor submission.
>> But either, way I think these reviews are necessary and useful.
>>
>> Here are my review comments:
>>
>> * There are some acronyms used before definition: PLMN, CDMA (at 
>> least)
>>
>> * There are several references to Annex something in the draft, 
>> presumably these should be to 802.21 specs, or somewhere 
>else in this 
>> spec. The spec says "Section numbers cited in comment tags without a 
>> reference to a ... ", maybe it should say "Section and 
>appendix .." or 
>> something that effect?
>>
>> * "subtype" isn't referenced by anything else. Is that correct?
>>
>> * I do not understand who can allocate "type_ext" values. Has this 
>> been defined in more detail in 802.21? The text does not live up to 
>> the preciseness that we would normally require from IANA 
>> considerations section, for instance.
>>
>> * Is there a better reference than an URL for unicode-xml?
>>
>> * ie_network_aux_id makes a point that it contains a HESSID. Is 
>> ie_network_id then an ESSID? Shouldn't this be documented?
>>
>> * I see that you have implemented some of the changes from 
>my previous 
>> review, and these now show up as differences wrt 802.21 
>original spec. 
>> I want to give you an opportunity to change some of these back to 
>> avoid the discrepancy *if* the issue was merely a different way to 
>> represent the same thing, not a bug. But don't unfix bugs... and 
>> clearly, the addition of comments has rendered this version 
>of the document readable!
>> Thank you for that.
>>
>> * Typo: "acronims"
>>
>> * Bit 0 (Security) ie_net_capabilities is a VERY weak definition.
>>
>> * It would be good to get standard references (e.g. RFC numbers) in 
>> the comment for ie_net_supported_lcp.
>>
>> * ie_net_mob_management_prot has a bit that is set when there's a 
>> MOBIKE node in the network. I guess you can set the bit whenever 
>> there's a Windows 7 PC in the network :-) Seriously though, I think 
>> you should rather indicate the existence of a MOBIKE node in a 
>> home-agent like role in the network or remove this altogether. I am 
>> not aware of MOBIKE being used in this mode, though I would 
>of course personally like that.
>>
>> * I don't understand how "3gpp_addr" can have anything to do 
>with the 
>> mobile's address (TMSI and so on). Are you trying to simulate the 
>> address of the WLAN access point? I think that is the PLMN and cell 
>> IDs, or possibly the empty string, not the mobile node's 
>address. But 
>> maybe I'm missing something.
>>
>> Jari
>>
>>
>>   
>

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 5 Aug 2009 14:32:28 +0200

Hi Hannes, 

looking at the -05 draft, here is one comment that is similar to one of
Jari's comments: 

The only explicit place where emergency support seems of relevance is in
the NETWORK type for the network capabilities. 
I have the same comment as Jari for bit#0 security. Also bit#8 emergency
services seems to be a weak definition. If there is some related logic
behind it would be good to add or reference it.
Otherwise, it seems questionable what the use of this could be in
practice:
- looking at it from the underlying access technology, the bit would not
help to provide further information about support for specific options
to support emergency within the access technology. 
- it also cannot help to tell what sort of suitable emergency service is
out there and how to discover it.
- regarding the regulatory domain: there is a separate data type
property REGU_DOMAIN. I am not sure what information is covered by the
REGU_DOMAIN besides country code, but it seems unclear whether any
combination of REGU_DOMAIN and bit#8 would provide any additional useful
information.
In general, something like indication for support of unauthorized or
unauthenticated calls (that can in general be supported by the access
but may be enabled/disabled based on regional requirements) might be of
some use, but it would be really hard to define this as it already seems
hard to agree on consistent terminology in this area.

Without any clear use (that I might just be missing) it might be safer
to drop this instead of risking implementations to interpret it in
different ways.

Dirk

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Hannes Tschofenig
> Sent: Wednesday, August 05, 2009 12:19 PM
> To: 'ecrit'
> Subject: [Ecrit] Review request for draft-ohba-802dot21-basic-schema
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>