[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