Re: [netext] AD Evaluation: draft-ietf-netext-ani-location

"Rajesh Pazhyannur (rpazhyan)" <> Fri, 23 January 2015 22:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EE56E1AD09D for <>; Fri, 23 Jan 2015 14:47:17 -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 3BC58OBmEKua for <>; Fri, 23 Jan 2015 14:47:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A992E1AD0A1 for <>; Fri, 23 Jan 2015 14:47:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1547; q=dns/txt; s=iport; t=1422053237; x=1423262837; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5gWK27x3Ulmo0o91tnRYZwTIjU4P+RZhAyuhpzHONhI=; b=CLVP/rL9VBg7GB4a3K5RhpB5AthtjXuU5jr/SOSQE+YtBf6n3iT6Megk BevGSh9dc1sMfwNnBdpyTNz8dZBmvz0LZ1j7+J5zO1tgnF7zL1jG1f8yw OuGsMylPO5rnYhZKNRbV1irNgnaVcqojmCnKcKpiDG6vQyxsuWwDp9ez2 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.09,456,1418083200"; d="scan'208";a="117099850"
Received: from ([]) by with ESMTP; 23 Jan 2015 22:47:16 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t0NMlF4V027843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 22:47:16 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 16:47:15 -0600
From: "Rajesh Pazhyannur (rpazhyan)" <>
To: Brian Haberman <>, "" <>, "" <>, "" <>
Thread-Topic: [netext] AD Evaluation: draft-ietf-netext-ani-location
Thread-Index: AQHQNyv6+F6qqgRGTkuWjiIArO6N75zOLTMA
Date: Fri, 23 Jan 2015 22:47:15 +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: <>
Subject: Re: [netext] AD Evaluation: draft-ietf-netext-ani-location
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: Fri, 23 Jan 2015 22:47:18 -0000

Hello Brian

Thanks for the evaluation.
Comments embedded. 



On 1/23/15, 8:45 AM, "Brian Haberman" <> wrote:

>     I have performed the usual AD Evaluation of
>draft-ietf-netext-ani-location as a part of the RFC publication process.
> I only have a few comments/questions on this draft that I would like to
>see resolved prior to starting IETF Last Call:
>1. I would think that this document should be marked as "Updates RFC
>6757".  Thoughts on this?

This is not making any changes to RFC6757 and so this not updating RFC6757.

>2. In Section 3.1, the civic location field is limited to 253 bytes.
>Given that there are civic locations that exceed that length, can you
>provide a brief justification for that limit?

This is a good question. The practical reason for 253 bytes is that the
ANI length field is one byte.
However, the DHCPv4 Civic Location also has a one byte length, so we felt
it was reasonable. 
For longer length, a PIDF location URI could be used (a URI that would
dereference to a location object).
Potentially, we can add text around how the 253 byte limit could be
handled for long civic locations.
>3. The two sub-sections of Section 4 use 2119 keywords when describing
>implementation details that really do not impact interoperability.
>Unless you want to get into interesting procedural discussions with some
>ADs, I would suggest modifying the text to not use 2119 keywords.