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

<Ruediger.Geib@telekom.de> Tue, 03 April 2012 07:50 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 7B97B21F8623 for <ippm@ietfa.amsl.com>; Tue, 3 Apr 2012 00:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 jwV3oYba-LQx for <ippm@ietfa.amsl.com>; Tue, 3 Apr 2012 00:50:29 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id A454221F854E for <ippm@ietf.org>; Tue, 3 Apr 2012 00:50:28 -0700 (PDT)
Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 03 Apr 2012 09:50:24 +0200
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 3 Apr 2012 09:50:22 +0200
From: Ruediger.Geib@telekom.de
To: henk@uijterwaal.nl, matt@internet2.edu
Date: Tue, 03 Apr 2012 09:50:20 +0200
Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt
Thread-Index: Ac0Q2ji9zm3VhUfBQ0+EWy/hCkVRtgADhUKgAB8SYiA=
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE8CA4C5@HE111648.emea1.cds.t-internal.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>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 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 07:50:29 -0000

Chairs,

could you clarify your idea of the process making value-added-octets an informational?
I understand Al's position. I myself am not clear whether Al's view is following
the process rules (and I don't know what exactly the process is). Please let me hear your
version.

Al wrote

  Adding features which they didn't suggest/invent, and reversing their
  position on protocol complexity means that the current draft does not meet
  the goal of "documenting work done by them", and instead lands in a
  middle-ground of "partly addresses WG comments and the problem statement".
  I don't think that's fair or useful.

  So, I still have no objection if the WG documents the individual
  draft-baillargeon-ippm-twamp-value-added-octets-02.txt (not -03 or other)
  with *Historic* status prepared on the way to a WG consensus solution,
  IF it means the WG can close the unproductive discussion on this draft.

  To me, the authors have circumvented the WG process with their
  current text, waving the "this is how the prototype works now" flag.
  It takes benefit from contributions under Note Well, and includes
  ideas of others contributed to the IETF IPPM WG which are not theirs.
  I object to publishing the current text, and I note that a new IPR
  disclosure is likely needed for it.

As there is an IPR issue and the WG compromise seems to have been to publish value-added-octets
with functionality as demonstrated during IETF 80, I favour sticking to that.

I agree with Al and Yaakov that it is not appropriate incorporate features discussed
under note well into an IPR protected solution. I don't think it is apropriate to continue to
change technical features described in this publication before it's IETF stamped as informational .
It is not relevant whether these changes are small. Apart from that the authors refuse to refer to
other IETF work while they seem to integrate functionality resulting from this work into their
prototype. If that's true (and it again doesn't matter whether changes are big or small), it's
not agreeable.

Regards,

Ruediger