IETF Logo Mail Archive

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

Brian Haberman <brian@innovationslab.net> Fri, 23 January 2015 16:45 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 2C3C71A87AC for <netext@ietfa.amsl.com>; Fri, 23 Jan 2015 08:45:18 -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 lbjVc6wgeLCc for <netext@ietfa.amsl.com>; Fri, 23 Jan 2015 08:45:16 -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 738C41A1AD8 for <netext@ietf.org>; Fri, 23 Jan 2015 08:45:16 -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 584EB880E2; Fri, 23 Jan 2015 08:45:16 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id DA85371C0002; Fri, 23 Jan 2015 08:45:15 -0800 (PST)
Message-ID: <54C27A93.4010504@innovationslab.net>
Date: Fri, 23 Jan 2015 11:45:07 -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: draft-ietf-netext-ani-location@tools.ietf.org, "netext-chairs@tools.ietf.org" <netext-chairs@tools.ietf.org>, "netext@ietf.org" <netext@ietf.org>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="5uvqTQ7ieDJoVkS6USHpRtLJcEDhRRan5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netext/fWQaFwe9ZJrzfvRPAD8LSUu8rk4>
Subject: [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 16:45:18 -0000

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?

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?

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.

Regards,
Brian

v2.23.0 | Report a Bug | By Email