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

["Rajesh Pazhyannur (rpazhyan)" <[e-mail]>]

Hello Richard and Brian

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

Thanks

Rajesh

On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" <[e-mail]>
wrote:

>Hello 
>
>Thanks for the review and suggestions.
>
>Best 
>
>Rajesh
>On 3/4/15, 6:32 PM, "Richard Barnes" <[e-mail]> wrote:
>
>>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.
>
>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.
> 
>>
>>(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.
>
>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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/netext
>