Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets
draft-ietf-ippm-twamp-value-added-octets-09

[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.

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

[Ballot discuss]
The "Document Quality" section of the ballot write-up seems to be
missing (it just shows the questions).

---

Updated after discussion with the authors...

Notwithstanding the working group's non-objection to the publication of
this document, it seems like an end-run on the working group process. As
I understanding it, the working group has agreed that there is a problem
to be described and resolved inthis area, but has not agreed that this
is the right problem or the right solution. Doesn't publication of this
document encourage adoption of this specific solution without agreement
from the WG?

For example, the text says:

  The purpose of this memo is to describe the Ericsson TWAMP Valued-
  Added Octets feature (version 1) for TWAMP [RFC5357].

But that hides the real puprpose. Why is there a need to describe the
feature in an RFC?

After discussion with the authors some text along the lines of the following
will be added and would satisfy this point for me:

> It is a description of a prototype
> presented and demonstrated at the IETF 80. The WG has a agreed to keep it as
> reference because it is the only known method today which provides a simple
> working solution with meaningful results. One possible purpose is to use it a
> benchmark when the actual standard method is available and see how it
> compares. At the end of the day, the usefulness of the protocol comes down to
> the precision of the available capacity estimates under various conditions or
> use cases. We are positive the standard method can learn from the good and
> bad of this prototype.

---

I would also like to understand better the way in which this document
relates to existing and future standard implementations. The text
states:

  This memo assumes the TWAMP responder is configured through non-
  standard means to interpret the value-added padding octets embedded
  in each TWAMP test packet.

This assumption is fine as far as it goes, but you need to document
what happens when there is a mismatch of configuration. How will a
legacy node react if it receives this form of overloading? How will an
Ericsson node react if it receives normal padding? What will happen if
a future standards track document uses the padding in a different way?

Furthermore, this document seems to specify a crass overloading of
fields when it would be more appropriate to define a correct protocol
extension. Such overloading often leads to interoperability issues
with implementations that do strict checking or with future extensions
that assign previously reserved bits for specific uses.

As 5357 states...

  Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
  generated independently of any other pseudo-random numbers mentioned
  in this document).  However, implementations MUST provide a
  configuration parameter, an option, or a different means of making
  Packet Padding consist of all zeros.  Packet Padding MUST NOT be
  covered by the HMAC and MUST NOT be encrypted.

Given this, I don't see how backward compatiblity can be achieved or how
the Ericsson extensions can be secured.

[Ballot discuss]
The "Document Quality" section of the ballot write-up seems to be
missing (it just shows the questions).

---

I would like to discuss this point with the rest of the IESG during the
telechat before updating my ballot.

Notwithstanding the working group's non-objection to the publication of
this document, it seems like an end-run on the working group process. As
I understanding it, the working group has agreed that there is a problem
to be described and resolved inthis area, but has not agreed that this
is the right problem or the right solution. Doesn't publication of this
document encourage adoption of this specific solution without agreement
from the WG?

For example, the text says:

  The purpose of this memo is to describe the Ericsson TWAMP Valued-
  Added Octets feature (version 1) for TWAMP [RFC5357].

But that hides the real puprpose. Why is there a need to describe the
feature in an RFC?

---

I would also like to understand better the way in which this document
relates to existing and future standard implementations. The text
states:

  This memo assumes the TWAMP responder is configured through non-
  standard means to interpret the value-added padding octets embedded
  in each TWAMP test packet.

This assumption is fine as far as it goes, but you need to document
what happens when there is a mismatch of configuration. How will a
legacy node react if it receives this form of overloading? How will an
Ericsson node react if it receives normal padding? What will happen if
a future standards track document uses the padding in a different way?

Furthermore, this document seems to specify a crass overloading of
fields when it would be more appropriate to define a correct protocol
extension. Such overloading often leads to interoperability issues
with implementations that do strict checking or with future extensions
that assign previously reserved bits for specific uses.

As 5357 states...

  Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
  generated independently of any other pseudo-random numbers mentioned
  in this document).  However, implementations MUST provide a
  configuration parameter, an option, or a different means of making
  Packet Padding consist of all zeros.  Packet Padding MUST NOT be
  covered by the HMAC and MUST NOT be encrypted.

Given this, I don't see how backward compatiblity can be achieved or how
the Ericsson extensions can be secured.

[Ballot discuss]

- The last part of the paragraph concerns me:

  This memo contains the description of a working prototype. It does
  not represent a consensus of the IETF community. The IETF community
  is currently working on the problem statement and has not reached
  consensus on the preferred method for measuring capacity metrics.

So basically, you want to document a prototype, for which the IETF community is currently working on problem statement?
What do I miss?

- The way I understand the two following paragraphs ...

  The definition of a structure for embedding a sequence of
  value-added fields at the beginning of the Packet Padding field
  [RFC5357] or Packet Padding (to be reflected) field [RFC6038]
  in the TWAMP test packets and, ...

  ...

  This memo assumes the TWAMP responder is configured through non-
  standard means to interpret the value-added padding octets embedded
  in each TWAMP test packet.

... is that you want to document a cover channel. I mean, the semantic of what you include is completely unknown as far as I can tell. Again, what do I miss?

- I support Stewart's and Robert's DISCUSS

- Regarding the following sentence ...

  Assignment of a proprietary TWAMP mode communicated during
  TWAMP control connection setup

... I don't see any reference to proprietary TWAMP mode in RFC5357. Practically, how is it done?

I'm wondering if you should not specify an "experimental" mode, and specify this document as using this "experimental" mode, avoiding any potential clash.
The following two sentences seem contradictory to me

  This memo does not extend the standard modes of operation through
  assignment of a new value in the Modes field (see Section 3.1 of
  [RFC4656] for the format of the Server Greeting message). A new mode
  is recommended to communicate feature capability during control
  connection setup.

[Ballot discuss]
The document encourages proprietary use (essentially, squatting) in a space reserved for expanding the protocol. In general that's proven to be a problem for other protocols. Can the document say why this one is different? Since an out of band agreement would need to be made before using a proprietary mode value, why use it at all instead of just relying on configuration of each end?

[Ballot discuss]
(this is for Wes nothing for the authors to do)

Wes, I'm probably jumping the gun here but are you going to request that the boiler plate be changed to match the abstract/intro, which contains:

  It does not represent a consensus of the IETF community.

[Ballot discuss]

I am concerned that there is no provision in the protocol to identify the vendor who has defined the extension. Thus
if one equipment is deploying this extension, and it's peer is from another vendor, there appears to be no way for the two equipments to resolve the semantics of the extension that each may be attempting to use.

The best approach in these circumstances would seem to be to publish an update to RFC5357 providing a well defined vendor extension mechanism including a vendor identifier, and then to carry this added value information behind the vendor identifier.

[Ballot comment]

  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

IANA has reviewed draft-ietf-ippm-twamp-value-added-octets-03, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Ericsson TWAMP Value-Added Octets) to Informational RFC


The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'Ericsson TWAMP Value-Added Octets'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo describes an extension to the TWAMP test protocol for
  identifying and managing packet trains, which enables measuring
  capacity metrics like the available path capacity, tight section
  capacity and UDP delivery rate in the forward and reverse path
  directions.

  This memo contains the description of a working prototype. It does
  not represent a consensus of the IETF community. The IETF community
  is currently working on the problem statement and has not reached
  consensus on the preferred method for measuring capacity metrics.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-value-added-octets/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-value-added-octets/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1782/

    Ericsson TWAMP Value-Added Octets
    draft-ietf-ippm-twamp-value-added-octets-02.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Informational.  Yes, this is indicated and it is an information document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

    Technical Summary

  This memo describes an extension to the TWAMP test protocol for
  identifying and managing packet trains, which enables measuring
  capacity metrics like the available path capacity, tight section
  capacity and UDP delivery rate in the forward and reverse path
  directions.

  This memo contains the description of a working prototype. It does
  not represent a consensus of the IETF community. The IETF community
  is currently working on the problem statement and has not reached
  consensus on the preferred method for measuring capacity metrics.

    Working Group Summary
  The prototype (and the first version of the draft) was presented at the
  March 2011 meeting, as the result of an experiment conducted by the authors.
  At the meeting, there was consensus that the prototype addressed a problem,
  though there was no consensus on what the problem exactly was.  In subsequent
  discussion, the WG agreed to work on the problem statement, while publishing
  this document in order to document the work done.

  As the prototype evolved during the year, and people brought up ideas,
  the document evolved as well.  There was some discussion on what should (not)
  be in this write-up.  This has been settled.

    Document Quality
  Good.

  Are there existing implementations of the protocol?

Yes, the document describes actual work done.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Henk Uijterwaal, AD Wes Eddy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Followed and contributed to the discussion on the document.  Read the final
document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Good, see above.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are a few lines longer than 72 characters, this is to be fixed by
the editor upon publication.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes, one reference needs to be updated as the draft is now an RFC.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

None

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section[...]

The IANA Sections is empty and can be removed on publication

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A