Re: [ippm] AD Review: draft-ietf-ippm-twamp-session-cntrl-03
Al Morton <acmorton@att.com> Fri, 26 February 2010 16:57 UTC
Return-Path: <acmorton@att.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 9E5B328C21F for <ippm@core3.amsl.com>; Fri, 26 Feb 2010 08:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.827
X-Spam-Level:
X-Spam-Status: No, score=-104.827 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 UT-tTH4eE7GM for <ippm@core3.amsl.com>; Fri, 26 Feb 2010 08:57:11 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9BEED28C20B for <ippm@ietf.org>; Fri, 26 Feb 2010 08:57:11 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-15.tower-120.messagelabs.com!1267203565!25614404!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 24554 invoked from network); 26 Feb 2010 16:59:25 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Feb 2010 16:59:25 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1QGxFST020135 for <ippm@ietf.org>; Fri, 26 Feb 2010 11:59:16 -0500
Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1QGxBRD020019 for <ippm@ietf.org>; Fri, 26 Feb 2010 11:59:12 -0500
Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o1QGxJgk016890 for <ippm@ietf.org>; Fri, 26 Feb 2010 10:59:19 -0600
Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o1QGxF3q016865 for <ippm@ietf.org>; Fri, 26 Feb 2010 10:59:15 -0600
Message-Id: <201002261659.o1QGxF3q016865@klpd017.kcdc.att.com>
Received: from acmt.att.com (vpn-135-70-102-148.vpn.swst.att.com[135.70.102.148](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100226165914gw100b8ip5e>; Fri, 26 Feb 2010 16:59:15 +0000
X-Originating-IP: [135.70.102.148]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 26 Feb 2010 11:58:13 -0500
To: Lars Eggert <lars.eggert@nokia.com>, IETF IPPM WG <ippm@ietf.org>
From: Al Morton <acmorton@att.com>
In-Reply-To: <53E0E1D0-3472-4DED-8A81-845E29B07132@nokia.com>
References: <53E0E1D0-3472-4DED-8A81-845E29B07132@nokia.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Subject: Re: [ippm] AD Review: draft-ietf-ippm-twamp-session-cntrl-03
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: Fri, 26 Feb 2010 16:57:12 -0000
We need one clarification, perhaps on the definition
of an "Update" to a standards track RFC and what it entails.
At 08:56 AM 2/26/2010, Lars Eggert wrote:
Section 1., paragraph 6:When we went ahead with the Mixed Security Mode RFC for TWAMP,
> This memo is intended to be an update to the TWAMP RFC.
Then you need an "Updates: 5357" header in the boilerplate. It would
also be good to clarify in the text that that means that this
extensions becomes mandatory to implement for all TWMP implementations
(i.e., it is non-optional.) Oh, and add a reference to RFC5357 to this
statement.
http://tools.ietf.org/html/rfc5618" rel="nofollow"> http://tools.ietf.org/html/rfc5618
we made it an Update for RFC 5357.
But it's not *mandatory to implement* RFC 5618 if you are building
RFC 5357 TWAMP, AFAIknew. Is that what we've effectively done
by making it an Update?
We want to make sure that someone who builds TWAMP knows that there
have been new (optional) features added, like mixed security mode and
Individual Session control, etc. Update seemed like the right mechanism.
thanks for your help,
Al