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