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

Richard Barnes <rlb@ipv.sx> Thu, 19 March 2015 16:44 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F491A1BF4 for <netext@ietfa.amsl.com>; Thu, 19 Mar 2015 09:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MhT5d9FUo59 for <netext@ietfa.amsl.com>; Thu, 19 Mar 2015 09:44:40 -0700 (PDT)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEB51A1DBD for <netext@ietf.org>; Thu, 19 Mar 2015 09:44:38 -0700 (PDT)
Received: by ladw1 with SMTP id w1so66940886lad.0 for <netext@ietf.org>; Thu, 19 Mar 2015 09:44:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HODp5WvRyMWidhDAIXHsKoyB8F4D06idaz2odg730Eg=; b=d1boPR4QFLYfLcxcn1VmKmOLDGCkws18YyEpdvHGGaBVY+ROiACPbVdbkD2r1KSmt7 9jkgpuC3Bww6t5bADtEeLVPwVcKwn0Ff/zTfOsnAhbToBq5DXOXNbbX4Ha/LHKEdL9XX lrR9yoYsr9TD3ax0CTmqd2elp4PWVnsYb8aJqrbcgnrg0PGJoO8udkoro7l+pCSy5E6L 3NpPAfdVdTz3Fa8U2Ps9behYR/BUvG7hEJxnjmmRYbYWwrDidMC+H9Ub6/cFofVxmu2S soIKyofRdrMKcTlHW4gC9ymyU4aiCwNLN2MVYXocbMOsNBuRV16Irw56TySaTri311AW SOXg==
X-Gm-Message-State: ALoCoQkcB4U0885nPXI+OxXaOCKIh7QVzMe6hC7eENfFrb/aDCm2VNg9sXExtnkJL/hdFeXLTGTC
MIME-Version: 1.0
X-Received: by 10.112.148.38 with SMTP id tp6mr69185993lbb.82.1426783476827; Thu, 19 Mar 2015 09:44:36 -0700 (PDT)
Received: by 10.25.135.4 with HTTP; Thu, 19 Mar 2015 09:44:36 -0700 (PDT)
In-Reply-To: <55081C46.4000109@innovationslab.net>
References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> <D11DECAB.1D878%rpazhyan@cisco.com> <D12D0E39.1DF74%rpazhyan@cisco.com> <55081C46.4000109@innovationslab.net>
Date: Thu, 19 Mar 2015 12:44:36 -0400
Message-ID: <CAL02cgTSvSKtiRBk3=wB75qJ+6WyW9ORkerUE26Wudxq_o+-8Q@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Brian Haberman <brian@innovationslab.net>
Content-Type: multipart/alternative; boundary=047d7b343fbe4ed3fc0511a6ea51
Archived-At: <http://mailarchive.ietf.org/arch/msg/netext/7oeLZf3FLpVa7NUIM7HecH2LmGk>
Cc: "draft-ietf-netext-ani-location.all@ietf.org" <draft-ietf-netext-ani-location.all@ietf.org>, The IESG <iesg@ietf.org>, "netext-chairs@ietf.org" <netext-chairs@ietf.org>, "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS)
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext/>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 16:44:43 -0000

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 <brian@innovationslab.net>
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)" <rpazhyan@cisco.com>
> > wrote:
> >
> >> Hello
> >>
> >> Thanks for the review and suggestions.
> >>
> >> Best
> >>
> >> Rajesh
> >> On 3/4/15, 6:32 PM, "Richard Barnes" <rlb@ipv.sx> 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
> >>> netext@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netext
> >>
>
>