Review of IEEE Documents

IEEE 802.11k

Review by Dan Romascanu

3.79a and in other places where RFC 3825 is mentioned - it would be good to make clear that this RFC is about coordinate-based LCI

section 5.2.7.7 - It is not clear why the text mentions 'it includes types of altitude such as floors ...' - are not both types of altitude supported?

section 7.3.2.22.9 - an example about how a specific longitude, latitude or altitude value as defined in 3825 is represented in the fields format would help here

I am not sure what is the scope and status of the MIB module defined in Annex D. Does it just define a data model or is it intended to be used for management by a protocol as SNMP? In any case it would certainly benefit from a MIB Doctor review. It should specifically define how it relates to previous versions of the IEEE 802.11 MIB as MIB modules cannot 'grow' by just adding new objects. Some objects in the MIB allow for write operations but there is no Security Considerations section.

Review by Peter Blatherwick

I have finally had a chance to go through the 802.11k document in some detail and have some comments. (Very sorry for the delay! All the usual excuses apply.) I have also included the other reviewers and interested parties here directly. My apologies in advance if (when) I mess up terminology and details -- I am certainly far from deep on 802.11.

THE BIG COMMENT:

My main comment is that I am very concerned that 802.11k does not reuse IEEE 802.1AB Link Layer Discovery Protocol (LLDP) as the mechanism to return device-specific location. More specifically, I believe LLDP-MED (ANSI/TIA-1057, a VoIP^?-specific extension of 802.1AB) is the appropriate means to return location or other device-specific parameters of similar nature in WLAN environments. In 802.11k, this appears to be happening through a lower level mechanisms (Measurement Request Frames), different from LLDP. My fear is this will result in multiple different ways to return the very same location information at L2, dependent on the specific 802 network technology. Such differences and proliferation of methods would, I believe, be very problematic for Emergency Call Service and other location-based applications, so should be avoided at all costs. Also note that LLDP-MED is the one method for location determination at L2 currently specified in IETF ECRIT (of 3 methods total, at various layers).

In addition, reuse of LLDP / LLDP-MED for location and similar purposes (not related to the measurement itself) would have several other benefits:

• LLDP and extensions to it can support any 802 link layer, or could be

readily extended to do so (more on this below), so could be common to all;

• Since LLDP is above the MAC layer, it can be implemented without

driver-level changes, making it much easier to deploy;

• LLDP/LLDP-MED is already deployed in VoIP^? endpoints, and that deployment

is growing, so forms a base for moving the same types of information in WLAN environments as well (noting also that LLDP-MED can already support AP-specific location today);

• LLDP/LLDP-MED, with appropriate extension, could also be used to carry

other device-specific information in WLAN environments, such as device-specific LAN policy or others (LLDP-MED is already used for this today in wired environments, and can already carry AP-specific information along these lines).

As further background, 802.1AB is currently in revision process ("ABrev"), so it would a very opportune time to define appropriate extensions to allow for device-specific information exchange in WLAN environments. One proposal is to allow 802.1AB frames to be addressed to the endpoint device MAC (rather than a broadcast seen by all endpoints on the same SSID), which would allow 802.11i to be used to address individual devices through the corresponding virtual port. If I understand correctly (which may or may not be the case) this would allow LLDP to be used for device-specific exchanges, as well as provide security for those exchanges. Comments related to this are about to be submitted to the ABrev group as well.

ADDITIONAL COMMENTS:

• Section 7.3.2.21.9 & ..22.9, adding to Brian Rosen's comment, yes it

does appear that the location information carried would not be secured, since encryption does not apply to 802.11 action frames. Additionally, these frames can be exchanged before 802.1X completes (not the case with LLDP). I believe this is a serious issues as well, and could potentially preclude its use in Geopriv.

• Section 7.3.2.21.9 & ..22.9, only geolocation LCI format is supported.

For compatibility with IETF ECRIT and Geopriv, this should also be capable of carrying Civic Location format (RFC 4776, or LLDP-MED). Additional formats may be desirable in future, which may be difficult to deploy after the fact.

I hope this helps clarify the situation and acts as useful input to 802.11k and others.

Regards, Peter Blatherwick (Editor, LLDP-MED, ANSI/TIA-1057)

Review by Brian Rosen

I have reviewed this document from an IETF geopriv and ecrit perspective. I have three comments

1. Section 7.3.2.21.9 Location Configuration Indication (LCI) Request permits a LCI Subject Remote operation. This is defined in the document as: Remote LCI Measurement Request is used by requesting STA to obtain the location of the reporting STA, asking "Where are you?". As the LCI carried by the 802.11k system is in raw form, without the privacy ruleset, this is a very dangerous (in the privacy sense) operation. I recommend the entire option be deleted, but if it is kept, then the form of the LCI should be changed to a full PIDF, including the ruleset.

2. In the same section, we find that the request can specify the desired resolution it desires, separately for all three dimensions. I would like to understand the use case for this option. I believe endpoints always desire the most resolution they can get, and it is the measurement methodology, and sometimes the policy of the server that determines how much resolution is returned. It is my opinion that these parameters can be removed, thus simplifying the document and all implementations.

3. While the mechanism specifies an RFC3825 compatible format for location (geo), further work within the geopriv working group probably favors using the PIDF form (PIDF-LO) rather than 3825, and probably including the "shapes" work.

IEEE 802.11u

TBD.

IEEE 802.11v

TBD.

IEEE 802.11y

TBD.

IEEE 802.16

TBD.

IEEE 802.21

TBD.

IEEE 802.1

Dan Romascanu believes that we should also include IEEE 802.1 in the list of IEEE 802 WGs that may issue documents to be relevant for ECRIT and GEOPRIV. IEEE 802.1ABrev is a revision of the IEEE 802.1AB, the basic standard LLDP-MED is built upon, and it just went through a Task Force Ballot.

-- HannesTschofenig - 06 May 2007