Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS)
"Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com> Tue, 17 March 2015 05:49 UTC
Return-Path: <rpazhyan@cisco.com>
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 7D7371A004C; Mon, 16 Mar 2015 22:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 PGm91h-XIyAL; Mon, 16 Mar 2015 22:49:38 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603D01A004B; Mon, 16 Mar 2015 22:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3809; q=dns/txt; s=iport; t=1426571378; x=1427780978; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8PxejwCEM5cHsIP3hD01mlKSfe1EaG65eF2rxdaljRA=; b=BlISsra7wq2LqXRgT8sWUN6JL21uYou795ynAwkfkPsRVtDoNZTtqhLl CT1rKqSm/SsbAIhXD/P4tb1hLIsZ5JL8XCad55TW1WvyyybV3QcoWGRiW BRe1PmM9JOoP6wHjUhNr9jA1J5UKrdnqF38ryzHfkCBx+1PgfCyhGyDWV k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DqBgDgvwdV/5BdJa1bgwZSWgTDBIIvCoUsSQKBO0wBAQEBAQF9hBABAQQBAQE3NAsQAgEIDgoeECcLJQIEAQ0FCYgmDck3AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhA8LBgFQAgWELQWGDoosg2uCI4NYgRs5gnKMB4NHI4F/HxSBPG8BgQIIFyJ/AQEB
X-IronPort-AV: E=Sophos;i="5.11,414,1422921600"; d="scan'208";a="404290095"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 17 Mar 2015 05:49:37 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2H5nbPW011364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 05:49:37 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 00:49:37 -0500
From: "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>
To: Richard Barnes <rlb@ipv.sx>, The IESG <iesg@ietf.org>, "brian@innovationslab.net" <brian@innovationslab.net>
Thread-Topic: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS)
Thread-Index: AQHQVuyhoJvOx1fN5UqX5E4fYH1vKp0OK5oAgBHxUYA=
Date: Tue, 17 Mar 2015 05:49:36 +0000
Message-ID: <D12D0E39.1DF74%rpazhyan@cisco.com>
References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> <D11DECAB.1D878%rpazhyan@cisco.com>
In-Reply-To: <D11DECAB.1D878%rpazhyan@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [10.24.6.208]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B654CADF1167754D8C0D8C588CDC27E4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/netext/ZmU59G4wVtO_35jLmj9GUE4IE5g>
Cc: "netext@ietf.org" <netext@ietf.org>, "netext-chairs@ietf.org" <netext-chairs@ietf.org>, "draft-ietf-netext-ani-location.all@ietf.org" <draft-ietf-netext-ani-location.all@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: Tue, 17 Mar 2015 05:49:42 -0000
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)" <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)