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 > >> > >
- Re: [netext] Richard Barnes' Discuss on draft-iet… Rajesh Pazhyannur (rpazhyan)
- Re: [netext] Richard Barnes' Discuss on draft-iet… Brian Haberman
- Re: [netext] Richard Barnes' Discuss on draft-iet… Richard Barnes
- Re: [netext] Richard Barnes' Discuss on draft-iet… Brian Haberman
- [netext] Richard Barnes' Discuss on draft-ietf-ne… Richard Barnes
- Re: [netext] Richard Barnes' Discuss on draft-iet… Rajesh Pazhyannur (rpazhyan)