Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets
RFC 6802

Note: This ballot was opened for revision 04 and is now closed.

(Wesley Eddy) Yes

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-09-20 for -07)
Thank you for addressing the issues I raised as a Discuss.

(Gonzalo Camarillo) No Objection

Benoit Claise (was Discuss) No Objection

Comment (2012-09-26 for -07)
In his comment, Adrian summarized my feelings perfectly:
   I remain somewhat unhappy about the way this work has overloaded pieces of the
   protocol, and I wish it could be moved into true Experimental or
   vendor-specific space. I hope the WG will consider the need to create space for
   experimentation and vendor options, and I hope that this work will not be
   allowed to become a de facto standard without propser WG examination.
I see "The Value-Added Octets Version 1 feature" in this draft. I really don't want to see a version 2 specified this way.
The next version should be EXPERIMENTAL or STANDARDS TRACK, as agreed by the WG. If not agreed by the WG, a RFC Editor stream publication

Anyway, I could live with such a document, if the following changes were made:

- Section 2
OLD:
   In general, the Value-Added Octets
   feature should be deployed in an environment where both controller
   and responder are managed by the same administrative entity and such
   entity has established an agreement to operate the Value-Added Octets
   feature between the pair of hosts or between specific UDP endpoints
   between the pair of hosts. See section 4 and section 5.3 for
   additional considerations.

NEW:
   The Value-Added Octets
   feature MUST be deployed in an environment where both controller
   and responder are managed by the same administrative entity and such
   entity has established an agreement to operate the Value-Added Octets
   feature between the pair of hosts or between specific UDP endpoints
   between the pair of hosts. See section 4 and section 5.3 for
   additional considerations.


- Section 4.1
OLD:
   When the
   Value-Added Octets feature is not supported on a TWAMP reflector, the
   TWAMP controller must not select the Value-Added Octets feature and
   must not include any value-added octets in the test packets.

NEW:
   When the
   Value-Added Octets feature is not supported on a TWAMP reflector, the
   TWAMP controller MUST NOT select the Value-Added Octets feature and
   MUST NOT include any value-added octets in the test packets.

(Adrian Farrel) (was Discuss) No Objection

Comment (2012-07-23 for -05)
Thanks for addressing my Discuss points.

I remain somewhat unhappy about the way this work has overloaded pieces of the protocol, and I wish it could be moved into true Experimental or vendor-specific space. I hope the WG will consider the need to create space for experimentation and vendor options, and I hope that this work will not be allowed to become a de facto standard without propser WG examination.

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-07-15 for -04)
  Please consider the editorial comment from the Gen-ART Review by
  Peter Yee on 28-June-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07564.html

(Barry Leiba) No Objection

(Pete Resnick) No Objection

Comment (2012-07-19 for -04)
I agree with Adrian's concerns.

(Robert Sparks) (was Discuss) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection