Re: [netext] AD Evaluation: draft-ietf-netext-ani-location
Brian Haberman <brian@innovationslab.net> Fri, 23 January 2015 22:54 UTC
Return-Path: <brian@innovationslab.net>
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 DCCFF1A8AEA for <netext@ietfa.amsl.com>; Fri, 23 Jan 2015 14:54:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HizHYjwm0gJQ for <netext@ietfa.amsl.com>; Fri, 23 Jan 2015 14:54:22 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808701A00A8 for <netext@ietf.org>; Fri, 23 Jan 2015 14:54:22 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 53F7B88135; Fri, 23 Jan 2015 14:54:22 -0800 (PST)
Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C1B7D71C0002; Fri, 23 Jan 2015 14:54:21 -0800 (PST)
Message-ID: <54C2D11D.8090205@innovationslab.net>
Date: Fri, 23 Jan 2015 17:54:21 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>, "draft-ietf-netext-ani-location@tools.ietf.org" <draft-ietf-netext-ani-location@tools.ietf.org>, "netext-chairs@tools.ietf.org" <netext-chairs@tools.ietf.org>, "netext@ietf.org" <netext@ietf.org>
References: <54C27A93.4010504@innovationslab.net> <D0E80E37.1A934%rpazhyan@cisco.com>
In-Reply-To: <D0E80E37.1A934%rpazhyan@cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="ChwBCDfjaAXed9sXLF2IHG0HQc7EKfFq5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netext/jXwLGf1EqAN0dNLOH_ajbaqeQqM>
Subject: Re: [netext] AD Evaluation: draft-ietf-netext-ani-location
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: Fri, 23 Jan 2015 22:54:24 -0000
Hi Rajesh, On 1/23/15 5:47 PM, Rajesh Pazhyannur (rpazhyan) wrote: > Hello Brian > > Thanks for the evaluation. > Comments embedded. > > Thanks > > Rajesh > > On 1/23/15, 8:45 AM, "Brian Haberman" <brian@innovationslab.net> wrote: > >> All, >> 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. > An Updates tag is not reserved only for changing an RFC. Do you want new implementers of 6757 to also implement this spec at the same time? > > >> >> 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. > I think some text describing how to handle locations that won't fit in the field would be good. >> >> 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. > > Ok. > Cool. Regards, Brian
- [netext] AD Evaluation: draft-ietf-netext-ani-loc… Brian Haberman
- Re: [netext] AD Evaluation: draft-ietf-netext-ani… Rajesh Pazhyannur (rpazhyan)
- Re: [netext] AD Evaluation: draft-ietf-netext-ani… Brian Haberman
- Re: [netext] AD Evaluation: draft-ietf-netext-ani… Sri Gundavelli (sgundave)