[ippm] AD review: draft-ietf-ippm-more-twamp

Lars Eggert <lars.eggert@nokia.com> Mon, 27 April 2009 19:57 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E973D3A692F for <ippm@core3.amsl.com>; Mon, 27 Apr 2009 12:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level:
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGcOMxVcvGpT for <ippm@core3.amsl.com>; Mon, 27 Apr 2009 12:57:10 -0700 (PDT)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 256933A6853 for <ippm@ietf.org>; Mon, 27 Apr 2009 12:57:08 -0700 (PDT)
Received: from lars-2.vzbi.com (lars-2.vzbi.com [166.58.67.119]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3RJwOO9081513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <ippm@ietf.org>; Mon, 27 Apr 2009 22:58:26 +0300 (EEST) (envelope-from lars.eggert@nokia.com)
Message-Id: <62431212-93A8-44E3-91F3-0E943899EC4A@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/signed; boundary="Apple-Mail-30-562093916"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 27 Apr 2009 15:58:18 -0400
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Mon, 27 Apr 2009 22:58:27 +0300 (EEST)
Subject: [ippm] AD review: draft-ietf-ippm-more-twamp
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2009 19:57:11 -0000

High-level bit: Revised ID needed to address a few minor issues,  
otherwise good to go.


INTRODUCTION, paragraph 1:
 > Network Working Group
 > Internet-Draft
 > Intended status: Standards Track
 > Expires: April 22, 2009

   Please add "Updates: 5357" header.


TITLE:
 >                         More Features for TWAMP

   Expand TWAMP acronym.


INTRODUCTION, paragraph 12:
 >    The IETF has completed its work on TWAMP - the Two-Way Active
 >    Measurement Protocol.  This memo describes a simple extension to
 >    TWAMP, the option to use different security modes in the TWAMP-
 >    Control and TWAMP-Test protocols.

   Suggest to drop the first sentence of the abstract - WG/protocol
   history is quickly outdated, RFCs live forever. Also, expand TWAMP
   acronym.


Section 1., paragraph 1:
 >    The IETF has completed its work on the core specification of  
TWAMP -
 >    the Two-Way Active Measurement Protocol [RFC5357].  TWAMP is an
 >    extension of the One-way Active Measurement Protocol, OWAMP
 >    [RFC4656].  The TWAMP specification gathered wide review as it
 >    approached completion, and the by-products were several
 >    recommendations for new features in TWAMP.  There are a growing
 >    number TWAMP implementations at present, and wide-spread usage is
 >    expected.  There are even devices that are designed to test
 >    implementations for protocol compliance.

   Suggest to drop the first sentence of the abstract - WG/protocol
   history is quickly outdated, RFCs live forever.


Section 1., paragraph 3:
 >    The relationship between this memo and TWAMP is intended to be an
 >    update to [RFC5357] when published.

   Rephrase for publication, i.e., "This documents updates [RFC5337]."


Section 4.1., paragraph 1:
 >    This section describes REQUIRED extensions to the behavior of the
 >    TWAMP Sender.

   Section 2 said that this entire draft specifies OPTIONAL
   functionality.   This section says that the following extensions are
   REQUIRED. That's a bit of a mismatch. Either this entire document is
   now required to implement TWAMP, or the extensions are OPTIONAL, but
   implementations that chose to implement them need to do these. Please
   make this more clear.


Section 8.1., paragraph 2:
 >    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing  
an
 >               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
 >               October 1998.

   Please update this reference and the text in Section 6.2 to RFC5226.


Section 8.2., paragraph 0:
 > 8.2.  Informative References
 >    [x]        "".

   Remove section.