[netext] AD Evaluation: draft-ietf-netext-pmip-qos-wifi

Brian Haberman <brian@innovationslab.net> Mon, 09 February 2015 15:11 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 1194E1A0E10 for <netext@ietfa.amsl.com>; Mon, 9 Feb 2015 07:11: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 MXvZOKB0ucU3 for <netext@ietfa.amsl.com>; Mon, 9 Feb 2015 07:11: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 3EE4E1A0AF7 for <netext@ietf.org>; Mon, 9 Feb 2015 07:11: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 2572B880E7; Mon, 9 Feb 2015 07:11: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 B57C271B0001; Mon, 9 Feb 2015 07:11:15 -0800 (PST)
Message-ID: <54D8CE18.1030101@innovationslab.net>
Date: Mon, 09 Feb 2015 10:11:20 -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-pmip-qos-wifi@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="QBaoLbIVcsRu68dHN325luNIo2JHrsKXL"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netext/sQau9FdfK3qa1cbdaxUzSzBL49g>
Subject: [netext] AD Evaluation: draft-ietf-netext-pmip-qos-wifi
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: Mon, 09 Feb 2015 15:11:18 -0000

All,
     I have completed my AD Evaluation of
draft-ietf-netext-pmip-qos-wifi as a part of the publication process.  I
have a few points that I would like to discuss before moving this
document into IETF Last Call...

* The reference to RFC 2119 needs cleaning up.  The Normative References
section tags the document as [RFC 2119], but section 1.1 refers to it as
[RFC2119].

* The Introduction uses several acronyms without expansion.  Notionally,
this seems to be because the acronyms are expanded in section 1.3.  I
would suggest avoiding the use of the acronyms until after section 1.3.
 The Introduction should just use the expanded terms.

* Definitions

     - Do the definitions need to use the 2119 keywords?

     - For simplicity, I would move section 1.3 ahead of section 1.2.

* Section 2 uses "(in decreasing order)". The context derived from the
next sentence indicates that is in decreasing order of priority.  I
would state that explicitly.

* Section 3.1.1

     - Step 1 seems to require the AP/MAG to do DPI if TCLAS is not
present. Does that imply that the AP/MAG must have application layer
gateway support for each app used by the MN?  If so, that could have
scalability and usability implications.  May be worth mentioning.

     - In Step 2, what is the AP/MAG to do if the TCLAS is not present
(when WMM-AC is used)?  Does it construct one via the ALG discussed above?

* Section 3.1.2

     - This is the first mention of a policy server and there is no
description or reference of what the policy server does or how it is
expected to interact with these QoS mechanisms.  At a minimum, there
should be something in the Definitions that describes this function.

     - What is the rationale for the order of steps?  I could very
easily see the order being 1, 3, 4, 2.  Are there corner cases that
should be discussed if the original order is not followed?

* Section 3.2 seems like an attempt to cover all possible scenarios when
it may not be needed.  Can a scenario be described where the network
would originate the QoS signaling?

* Figure 5 is never referenced in the text.

Regards,
Brian