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

"Rajesh Pazhyannur (rpazhyan)" <> Thu, 05 March 2015 19:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D3FAF1A88D5; Thu, 5 Mar 2015 11:49:30 -0800 (PST)
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 UA8DWK7OuBDn; Thu, 5 Mar 2015 11:49:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D31FF1A88CA; Thu, 5 Mar 2015 11:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3505; q=dns/txt; s=iport; t=1425584970; x=1426794570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gQdOr9viuK4V6KJOPNzV0Pi5T0OrTBmqwwivOrDawHQ=; b=ABOVtwRW5V0aZ2h0SIvq8L51q2j06vkrnC2fU7q0f3Z/KQDJBjgBnkJK mVGpeVtI4nRed7YnR97ynQdjyTxo1oDdjZRSfvF1peeurhVuk3EhOCH1V JJjxG9QLvxHbZlVqVOUtiywSSZIgJt09IdF7NT3vl9KYZtY+oTIIIOHfy 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="scan'208";a="129320103"
Received: from ([]) by with ESMTP; 05 Mar 2015 19:49:29 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t25JnRG1018926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 19:49:28 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 13:49:27 -0600
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: AQHQVuyhoJvOx1fN5UqX5E4fYH1vKp0OK5oA
Date: Thu, 5 Mar 2015 19:49:27 +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: Thu, 05 Mar 2015 19:49:31 -0000


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