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
>