Re: [ippm] AD Review: draft-ietf-ippm-twamp-session-cntrl-03

Lars Eggert <lars.eggert@nokia.com> Sat, 27 February 2010 15:31 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 1ECDB28C1B8 for <ippm@core3.amsl.com>; Sat, 27 Feb 2010 07:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level:
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 puP0KuK70gDx for <ippm@core3.amsl.com>; Sat, 27 Feb 2010 07:31:08 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A5F1D28C1BD for <ippm@ietf.org>; Sat, 27 Feb 2010 07:31:07 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o1RFXIS8031248; Sat, 27 Feb 2010 17:33:20 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Feb 2010 17:33:18 +0200
Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Feb 2010 17:33:18 +0200
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o1RFXGda031092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Feb 2010 17:33:17 +0200
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary="Apple-Mail-11--932705588"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <201002261659.o1QGxFUN016864@klpd017.kcdc.att.com>
Date: Sat, 27 Feb 2010 07:33:06 -0800
Message-Id: <DE507607-4624-4062-9C9A-FE64232F6397@nokia.com>
References: <53E0E1D0-3472-4DED-8A81-845E29B07132@nokia.com> <201002261659.o1QGxFUN016864@klpd017.kcdc.att.com>
To: Al Morton <acmorton@att.com>
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Sat, 27 Feb 2010 17:33:10 +0200 (EET)
X-OriginalArrivalTime: 27 Feb 2010 15:33:18.0645 (UTC) FILETIME=[2FC4DE50:01CAB7C2]
X-Nokia-AV: Clean
Cc: IETF IPPM WG <ippm@ietf.org>
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: Sat, 27 Feb 2010 15:31:09 -0000

Hi,

On 2010-2-26, at 8:58, Al Morton wrote:
> When we went ahead with the Mixed Security Mode RFC for TWAMP,
> 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?

what the "Updates" header means is unfortunately not well defined. To some, "Updates X" in document Y means "if you have implemented X, you now also need to implement Y to remain compliant." To others, it just means "if you implemented X you probably now also want to read Y".

The IESG is working on a statement that hopes to clarify the different interpretations. Personally, I'm more of a subscriber to the first viewpoint.

For RFC5618, we have no issue, because although it says that it updates RFC5357, it's very clear from the text that it is an OPTIONAL extension. In other words, it's more or a "also read this" 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.

We can do the same here, also for consistency: add an "Updates: 5357" header, but then in the text make it very clear that this is an OPTIONAL extension that is not required to implement for TWAMP compliance.

Lars