Subject: [Geopriv] Review of draft-thomson-geopriv-held-measurements

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Jun 2010 12:33:16 -0700

Overall, I think this document needs more work. 

Section 5.1

This section needs some additional text explaining the usage scenarios.

 In a situation where an LLDP node includes location information (e.g. 
MED TLVs), it would seem odd to disregard that location information and 
instead request the LIS to determine location based on "measurement 
info".  Given this, I assume that the goal is to enable LLDP to be used to determine location in a situation where the devices don't support MED attributes, or where the operator does not want to provision each device with this information, preferring to provision the LIS instead.  Since the LLDP-MED MIB enables the sending of traps, there seems to be an assumption that updating the clients to submit the information via HELD would be simpler than updating the LIS to import the same info via SNMP.  

Also, LLDP is an extensible protocol.   On reading this section, I was unclear whether the schema was capable of including arbitrary LLDP TLVs, including vendor-specific ones. 

Section 5.3

In addition to the information provided in the basic schema, I'm wondering whether it wouldn't also be useful to enable encoding of "Radio Resource 
Measurement" information from specifications such as IEEE 802.11k.   This could enable encoding of things like the spectral region (relevant for attenuation), rate, etc.

Should I assume that the channel isn't included for the neighbors because they are on the same channel as the "serving WAP"? 

Also, is the RTT measuring the time between a request and a response, or the time between a request and an ACK? 

Section 5.6.1

L2TP is an extensible protocol. In some cases, relevant measurement info is provided in vendor-specific 
attributes.  On reading this section, I was unclear whether the schema 
was capable of including arbitrary L2TP attributes. 

Section 5.6.2

RADIUS is also an extensible protocol.  In some cases, relevant measurement info is provided in vendor-specific attributes.  On reading this section, I was unclear whether the schema was capable of including arbitrary RADIUS attributes.

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 29 Jun 2010 14:15:30 +0800

Hi Bernard,

> Overall, I think this document needs more work. 

That’s a fair statement.  I would hope that there is more review of the sort that you provide here before we request publication.

Your comments are fairly specific - did you have any feedback on sections outside of Section 5?

> […] I assume that the goal is to enable LLDP to be used to determine location in a situation where the devices don't support MED attributes, or where the operator does not want to provision each device with this information, preferring to provision the LIS instead.  […]

That's correct.  A Device with location from LLDP-MED has little reason to go to a LIS, if all they want is that location.  We should elaborate on the use case.

> Since the LLDP-MED MIB enables the sending of traps, there seems to be an assumption that updating the clients to submit the information via HELD would be simpler than updating the LIS to import the same info via SNMP.

Regarding traps, I'd have thought that updating the LIS would be easier than updating the Devices.  There's no assumption either way: I wouldn't presume to make that judgement.

Given the security considerations, I'd expect that a LIS would support the traps.

> Also, LLDP is an extensible protocol.  

Extensibility seems to be a general comment you have.  So I'll address it generally.  Each schema does permit arbitrary extension.  There is no extension container specific to each protocol.

We could have provided a generic LLDP extension container, just as we could have for RADIUS or Diameter attributes (or anything else).  However, I believe it better to constrain the set of measurements to the ones that have a use case.  I personally don’t feel that we should provide an open channel for all parameters of these protocols.  That should not preclude extension, even extension of the generic sort that I mention, even if I think that more specific measurement sets are more likely to interoperate.

That means that vendor-specific attributes need vendor-specific measurement elements.  I don't see that as a major limitation.

> In addition to the information provided in the basic schema, I'm wondering whether it wouldn't also be useful to enable encoding of "Radio Resource Measurement" information from specifications such as IEEE 802.11k.  This could enable encoding of things like the spectral region (relevant for attenuation), rate, etc.

RCPI and RSNI are the only measurements of this type in my copy of 'k.  Admittedly, my copy is 2 years old.  I'll ask our WiFi positioning guys about this.

> Should I assume that the channel isn't included for the neighbors because they are on the same channel as the "serving WAP"? 

Hmm, channel is missing only from the example - it is permitted.  I simply forgot to add it to the neighbours when I added it to the example.

> Also, is the RTT measuring the time between a request and a response, or the time between a request and an ACK? 

That was a mistake.  It should have been the acknowledgement.

Cheers,
Martin