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

[Richard Barnes <[e-mail]>]

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 <[e-mail]>
wrote:

> Hi Rajesh,
>
> On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote:
> > Hello Richard and Brian
> >
> > Shall I go ahead and make the changes based on (4) and submit a new
> > version ?
> >
>
> I believe option 4 is the best approach.  If anyone in the WG disagrees,
> they can scream now.
>
> Regards,
> Brian
>
> > 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
> >>
>
>