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

From: "Richard Barnes" <[email-masked]>
Date: Wed, 04 Mar 2015 18:32:25 -0800

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.

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Thu, 5 Mar 2015 19:49:27 +0000

Hello 

Thanks for the review and suggestions.

Best 

Rajesh

>http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/

So, yes we recognized the limitation of not being able to fit much in 253
bytes. 
Initially, we felt that it was still worthwhile to have that option in
case someone wanted to fit an XML based object within that.
But, I am increasingly skeptical of the value. So I am okay with the
change suggested. 
However, this may be a moot point given what we decide with respect to
your point (3) below.
 
>verbose, the examples I'm finding are still on the order of 70-100

I am quite in favor of this, because I think the DHCP based option will
meet all the deployment scenarios and the preferred
option because it eliminates the need for dereferencing.
if there is a need for it, we can always come back and add other formats
in the future (for example URL based)

>
>
>
>
>_______________________________________________
>netext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Thu, 5 Mar 2015 19:49:27 +0000

Hello 

Best 

Rajesh

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 17 Mar 2015 05:49:36 +0000

Hello Richard and Brian

Shall I go ahead and make the changes based on (4) and submit a new
version ? 

Thanks

Rajesh

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 17 Mar 2015 05:49:36 +0000

Hello Richard and Brian

Thanks

Rajesh

---

From: Brian Haberman <[email-masked]>
Date: Tue, 17 Mar 2015 08:21:26 -0400

Hi Rajesh,

> Shall I go ahead and make the changes based on (4) and submit a new

I believe option 4 is the best approach.  If anyone in the WG disagrees,
they can scream now.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 17 Mar 2015 08:21:26 -0400

Hi Rajesh,

Regards,
Brian

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Mar 2015 12:44:36 -0400

In the spirit of cleaning things out before my departure from the IESG, I
went ahead and cleared on this.

Brian: I assume you will make sure the relevant change is made?

Thanks,
--Richard

On Tue, Mar 17, 2015 at 8:21 AM, Brian Haberman <[email-masked]>
wrote:

> >>> Please refer to
> http://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Mar 2015 12:44:36 -0400

Thanks,
--Richard

---

From: Brian Haberman <[email-masked]>
Date: Thu, 19 Mar 2015 13:20:20 -0400

Richard,

> went ahead and cleared on this.

Cool.

> Brian: I assume you will make sure the relevant change is made?

Will do!  Thanks!

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 19 Mar 2015 13:20:20 -0400

Richard,

Cool.

Will do!  Thanks!

Regards,
Brian