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

["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.