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

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Tue Jun 29 2010 - 02:15:30 EDT

Hi Bernard,

On Monday, 28 June 2010 5:33 AM, Bernard Aboba writes:
> 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Tue, 29 Jun 2010 14:15:30 +0800

This archive was generated by hypermail 2.1.8 : Tue Jun 29 2010 - 02:13:57 EDT