[netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS and COMMENT)

["Richard Barnes" <[e-mail]>]

Richard Barnes has entered the following ballot position for
draft-ietf-netext-ani-location-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) In Section 3.1, the "civic location" description here mentions the
use of a location URI, but there's no corresponding Format for it.  Is
that what you actually mean to have for XML Encoding (1)?  You're not
going to fit much XML in 253 octets anyway.  I would suggest having
format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML
document.

(2) It would help interoperability if you could constrain the classes of
location URI that are supported.  For example, if the mechanism in RFC
6753 is sufficient for your purposes, you could require that geolocation
values in format 1 use an HTTPS URI to be dereferenced using that
mechanism.  Likewise, unless there's a known, compelling need to support
HTTP URIs, you should require HTTPS.  The fact that you have 253 format
codes remaining means that if there are future needs for other URI types,
you can liberalize.

(3) To ensure that the location information referenced by location URIs
is protected, please comment on the assumed access control model for
these URIs.  Can anyone with the URI dereference it?  Or are they
required to be access-controlled?  Section 4 of RFC 6753 should provide a
helpful framework. 

(4) Alternatively to (2) and (3), you could just remove the option for a
XML/URI-based location altogether.  Is there a compelling use cases here
for very precise location?  Even with the 253-octet limit, the RFC 4776
format would allow you to specify down to roughly the neighborhood level
in most cases.  For example, encoding "Washington, DC 20001, US" takes
only 26 octets.  Even looking at some Japanese addresses, which are more
verbose, the examples I'm finding are still on the order of 70-100
octets.

(5) Did the WG consider constraining the set of civic address elements
that can be used?  It's not clear to me that the use cases for this
document require very granular information, e.g., to the individual
building, floor, or room.  The RFC 4776 format makes it fairly easy to
express these constraints, by saying something like "The civic addresses
carried in the civic location sub option MUST NOT contain elements other
than A1, ..., A6 and PC."


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a good discussion of confidentiality protections in the
Security Considerations.  It would be helpful if you could also note that
another way to address the concerns here is to provision location
information at the least granular level possible.  Suggested:

"The other way to protect the sensitive location information of network
users is of course to not send it in the first places.  Users of the
civic location sub option should provision location values with the
highest possible level of granularity, e.g., to the province or city
level, rather than provisioning specific addresses.  In addition to
helping protect private information, reducing granularity will also
reduce the size of the civic location sub option."