Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt

Wesley Eddy <wes@mti-systems.com> Tue, 03 April 2012 15:03 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8927611E80B5 for <ippm@ietfa.amsl.com>; Tue, 3 Apr 2012 08:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WGM3XEhdkxC for <ippm@ietfa.amsl.com>; Tue, 3 Apr 2012 08:03:03 -0700 (PDT)
Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 877EA11E80A0 for <ippm@ietf.org>; Tue, 3 Apr 2012 08:03:03 -0700 (PDT)
Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q33F31U0023849 for <ippm@ietf.org>; Tue, 3 Apr 2012 11:03:02 -0400
Authentication-Results: cm-omr5 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [107.47.149.240] ([107.47.149.240:22633] helo=[192.168.43.65]) by cm-omr5 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B5/4C-13999-2211B7F4; Tue, 03 Apr 2012 11:03:01 -0400
Message-ID: <4F7B1114.6080603@mti-systems.com>
Date: Tue, 03 Apr 2012 11:02:44 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Steve Baillargeon <steve.baillargeon@ericsson.com>
References: <4F742D2D.4060408@uijterwaal.nl> <4F74397D.4050902@uijterwaal.nl> <201204021408.q32E8YEo001358@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF178ACB2AD5@EUSAACMS0701.eamcs.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Al Morton <acmorton@att.com>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 03 Apr 2012 15:03:04 -0000

On 4/2/2012 12:04 PM, Steve Baillargeon wrote:
> Hi
>  
>>>> The authors published -value-added-octets with a WG document filename(which confuses things, it has not represented WG consensus at   any stage)
> 
> My take on it is that it is OK for an Informational RFC: a subset did the work, the entire WG was asked to review the write-up.
> 


In similar cases, the document title (not to be confused with
the filename) has clearly specified whose work it reflects.
For instance, the document title is currently:
"TWAMP Value-Added Octets"
it could be something like:
"Ericsson's TWAMP Value-Added Octets"

I think that would be more clear for the record, rather than
messing with the filename, which disappears from view once it's
published as an RFC.


>>>> The authors modified the draft to adopt the function of asymmetrical packet size test capability and possibly other functions identified in the problem statement draft.
> 
> The only field we added in 03 is Desired Reverse Padding Length. We showed a prototype @ IETF-80, people came up with suggestions, we showed that our prototype could be extended.
> 
>>>> The authors now claim to have simplified their protocol, after discounting the WG's comments on the complexity of their approach for about a year.
> 
> The only field we removed in 03 is the Sender Discriminator since it is not specifically related to capacity measurements. Sender Discriminator looked like a good idea at the time @ IETF80 but then wasn't used during our demo and is now dropped.


To address the comments about confusion as to which parts
reflect the pre-WG activity, and which parts have been
incorporated after IPPM WG feedback, it might make sense
to just have a small bit of text in section 1 to say that
it started as an Ericsson project, but currently incorporates
some feedback from the IPPM working group.  This would, I
think, enhance the paragraph currently right before Section 1.1.

You might list the things that reflect that feedback (e.g. the
desired reverse padding length and removal of sender
discriminator) an an appendix or something, if you want to be
ultra-clear.

-- 
Wes Eddy
MTI Systems