[Ballot comment]
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.