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

"Rajesh Pazhyannur (rpazhyan)" <> Tue, 17 March 2015 05:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7D7371A004C; Mon, 16 Mar 2015 22:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PGm91h-XIyAL; Mon, 16 Mar 2015 22:49:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 603D01A004B; Mon, 16 Mar 2015 22:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.11,414,1422921600"; d="scan'208";a="404290095"
Received: from ([]) by with ESMTP; 17 Mar 2015 05:49:37 +0000
Received: from ( []) by (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 ([]) by ([]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 00:49:37 -0500
From: "Rajesh Pazhyannur (rpazhyan)" <>
To: Richard Barnes <>, The IESG <>, "" <>
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: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 ? 



On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" <>

>Thanks for the review and suggestions.
>On 3/4/15, 6:32 PM, "Richard Barnes" <> 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
>>for more information about IESG DISCUSS and COMMENT positions.
>>The document, along with other ballot positions, can be found here:
>>(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
>So, yes we recognized the limitation of not being able to fit much in 253
>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
>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