[DMM] AD Evaluation: draft-ietf-dmm-best-practices-gap-analysis
Brian Haberman <brian@innovationslab.net> Thu, 31 July 2014 14:13 UTC
Return-Path: <brian@innovationslab.net>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9331E1B2839 for <dmm@ietfa.amsl.com>; Thu, 31 Jul 2014 07:13:14 -0700 (PDT)
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 lpDBvs4HRPML for <dmm@ietfa.amsl.com>; Thu, 31 Jul 2014 07:13:08 -0700 (PDT)
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 D92FA1A0045 for <dmm@ietf.org>; Thu, 31 Jul 2014 07:12:48 -0700 (PDT)
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 BE410880F3; Thu, 31 Jul 2014 07:12:48 -0700 (PDT)
Received: from 102529874.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 648B671B0001; Thu, 31 Jul 2014 07:12:48 -0700 (PDT)
Message-ID: <53DA4EDA.3030808@innovationslab.net>
Date: Thu, 31 Jul 2014 10:12:42 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm-chairs@tools.ietf.org" <dmm-chairs@tools.ietf.org>, draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org, "dmm@ietf.org" <dmm@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="5WJUiJBRgldeW5t0dR97ccxo6niWPld5x"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Msm50_owtHzwEIBQOaSgfwZFIDY
Subject: [DMM] AD Evaluation: draft-ietf-dmm-best-practices-gap-analysis
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jul 2014 14:13:14 -0000
All, I have reviewed draft-ietf-dmm-best-practices-gap-analysis as a part of the publication process. The document is well-written and easy to follow. I only have a few points I would like to see addressed/discussed before I move the draft to IETF Last Call. 1. I would suggest making the following change to the Abstract: s/The present document/This document/ 2. Re-word the Introduction to not refer to the DMM WG. In general, an RFC should not reference a WG name since that WG may not exist forever. 3. I would drop the 2119 keyword paragraph (and the corresponding reference to 2119). The only places where those words are used is in sections 5.5 & 5.6 and those should be changed (described in a later point). 4. Please expand (and reference) SCTP in section 4.1. I would also suggest doing a search for acronyms and ensuring they are all expanded on first use. 5. In Figure 1 (section 4.2), I would suggest giving the MNs unique labels and then using those labels in the supporting text. 6. Section 4.2.1: * s/by IETF// * s/outside IETF/in other standards organizations/ * s/IETF has defined extensions/Extensions have been defined/ * Please remove reference to seamoby WG. 7. Section 5.1 : s/by IETF// 8. Section 5.2 mentions the need for host to network signaling for determining which apps are using IP mobility management, but there is no mention of any signaling from applications to the IP stack that a particular app needs IP mobility management. I think that needs some discussion in the document. 9. Sections 5.5 and 5.6... I would suggest re-wording these sections to paraphrase the text from the requirements document. Specifically, the verbatim use of 2119 keywords may be confusing since it is inconsistent with previous sections. 10. Section 5.8 : Remove explicit mention of multimob WG. Let me know if you have any questions/concerns with these comments/suggestions. Regards, Brian
- [DMM] AD Evaluation: draft-ietf-dmm-best-practice… Brian Haberman