Skip to main content

Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)
RFC 5938

Revision differences

Document history

Date Rev. By Action
2020-01-21
07 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
07 (System) Notify list changed from ippm-chairs@ietf.org, draft-ietf-ippm-twamp-session-cntrl@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2010-08-13
07 Cindy Morgan [Note]: changed to 'RFC 5938' by Cindy Morgan
2010-08-13
07 Cindy Morgan State changed to RFC Published from RFC Ed Queue by Cindy Morgan
2010-08-11
07 (System) RFC published
2010-04-14
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-04-14
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-04-14
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-04-14
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-04-14
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-04-13
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-04-12
07 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-04-12
07 (System) IANA Action state changed to In Progress
2010-04-12
07 Amy Vezza IESG state changed to Approved-announcement sent
2010-04-12
07 Amy Vezza IESG has approved the document
2010-04-12
07 Amy Vezza Closed "Approve" ballot
2010-04-09
07 Lars Eggert State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert
2010-04-09
07 (System) Removed from agenda for telechat - 2010-04-08
2010-04-08
07 Sean Turner [Ballot discuss]
2010-04-08
07 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner
2010-04-08
07 (System) New version available: draft-ietf-ippm-twamp-session-cntrl-07.txt
2010-04-08
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-04-08
06 (System) New version available: draft-ietf-ippm-twamp-session-cntrl-06.txt
2010-04-08
07 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-04-08
07 Tim Polk [Ballot comment]
I support Sean's Discuss on HMAC pecification.
2010-04-08
07 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-04-08
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-04-07
07 Jari Arkko
[Ballot comment]
I support Sean's Discuss, and the spec needs to point back to the
original RFCs so that the semantics of HMAC and other …
[Ballot comment]
I support Sean's Discuss, and the spec needs to point back to the
original RFCs so that the semantics of HMAC and other fields are
adequately specified for the new commands.

Secondly, I found this text a bit odd:

  o  If the RECOMMENDED REFWAIT timer is implemented, it SHOULD be
      enforced when any test session is in-progress (started and not
      stopped).

The text should probably read "If the REFWAIRT timer is implemented ..."
Earlier text already recommends REFWAIT to be implemented, it should
not be repeated here.
2010-04-07
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2010-04-07
07 Sean Turner
[Ballot discuss]
The HMAC algorithm used in section 3.3, 3.4, and 3.5 needs to be specified.  I assume it's the same one that's specified in …
[Ballot discuss]
The HMAC algorithm used in section 3.3, 3.4, and 3.5 needs to be specified.  I assume it's the same one that's specified in [RFC4656]/[RFC5357], but I'd prefer an explicit statement that says as much.  Please either add a normative reference to the HMAC algorithm or a pointer to the appropriate section in [RFC4656]/[RFC5357].
2010-04-07
07 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner
2010-04-07
07 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-04-07
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-04-07
07 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-04-06
07 David Harrington [Ballot comment]
A couple minor edits:
s/must be one or greater/MUST be one or greater/g
s/one or more the sessions/one or more of the sessions/g
2010-04-06
07 David Harrington [Ballot Position Update] New position, No Objection, has been recorded by David Harrington
2010-04-06
07 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2010-04-06
07 Adrian Farrel
[Ballot comment]
A few nits you might sort out along the way...

I don't think that using 2119 language in the Abstract or Introduction
is …
[Ballot comment]
A few nits you might sort out along the way...

I don't think that using 2119 language in the Abstract or Introduction
is very appropriate. That language is really intended for specifying
protocol behavior.

---

Section 1

  This memo is intended to be an update to the TWAMP core protocol
  specified in [RFC5357].  It is not required to implement the feature
  described in this memo to claim compliance with [RFC5357].

It is a bit late for intentions :-)
I think this is an update fair and square.

The second sentence could also do with some polish. What is not required
to implement the feature?

---

It is not immediately clear to me whether this feature also applies to
OWAMP. I think not, so it is slightly confusing that Section 1 says...

  This memo describes an OPTIONAL feature for TWAMP.  TWAMP (and OWAMP)
  start all previously requested and accepted test sessions at once.

---

Section 2

  The scope of the memo is currently limited to specifications of the
  following features:

So at what point might it change?

---

My Discuss used to read...
A small issue I would like to clarify before supporting the publication of this document. In Section 1 you have...

  Implementers of this feature may also wish to implement the "Reflect
  Octets" feature, described in [I-D.ietf-ippm-twamp-reflect-octets],
  once it has been published as an RFC.  This feature allows a Control-
  Client to insert a locally-specified request number into the Request-
  TW-Session command (in octets originally designated MBZ=Must Be
  Zero), and a compliant Server will return the request number in its
  reply (Accept message).  The Reflect Octets feature makes multiple
  simultaneous session requests possible, and supports the operation of
  many simultaneous test sessions (similar to the goal of this memo).

Do I read this to mean that the working group is developing two
solutions to the same problem? One (the other) having wider
applicability.

Can you clarify the working group thinking on this?

- Al has clarified for me that there is no overlap between the
- work, but it would be really nice if the quoted paragraph
- could be rewritten to avoid implying that there are two
- different solutions to the same problems.
2010-04-06
07 Adrian Farrel [Ballot discuss]
Discuss reduced to a comment after an exchange with Al Morton
2010-04-06
07 Adrian Farrel
[Ballot comment]
A few nits you might sort out along the way...

I don't think that using 2119 language in the Abstract or Introduction
is …
[Ballot comment]
A few nits you might sort out along the way...

I don't think that using 2119 language in the Abstract or Introduction
is very appropriate. That language is really intended for specifying
protocol behavior.

---

Section 1

  This memo is intended to be an update to the TWAMP core protocol
  specified in [RFC5357].  It is not required to implement the feature
  described in this memo to claim compliance with [RFC5357].

It is a bit late for intentions :-)
I think this is an update fair and square.

The second sentence could also do with some polish. What is not required
to implement the feature?

---

It is not immediately clear to me whether this feature also applies to
OWAMP. I think not, so it is slightly confusing that Section 1 says...

  This memo describes an OPTIONAL feature for TWAMP.  TWAMP (and OWAMP)
  start all previously requested and accepted test sessions at once.

---

Section 2

  The scope of the memo is currently limited to specifications of the
  following features:

So at what point might it change?
2010-04-06
07 Adrian Farrel
[Ballot discuss]
A small issue I would like to clarify before supporting the publication of this document. In Section 1 you have...

  Implementers of …
[Ballot discuss]
A small issue I would like to clarify before supporting the publication of this document. In Section 1 you have...

  Implementers of this feature may also wish to implement the "Reflect
  Octets" feature, described in [I-D.ietf-ippm-twamp-reflect-octets],
  once it has been published as an RFC.  This feature allows a Control-
  Client to insert a locally-specified request number into the Request-
  TW-Session command (in octets originally designated MBZ=Must Be
  Zero), and a compliant Server will return the request number in its
  reply (Accept message).  The Reflect Octets feature makes multiple
  simultaneous session requests possible, and supports the operation of
  many simultaneous test sessions (similar to the goal of this memo).

Do I read this to mean that the working group is developing two
solutions to the same problem? One (the other) having wider
applicability.

Can you clarify the working group thinking on this?
2010-04-06
07 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2010-04-03
07 Alexey Melnikov
[Ballot comment]
3.2.  Start-N-Sessions Command with Individual Session Control

  The message is terminated with a single block HMAC, as illustrated
  above.

How is …
[Ballot comment]
3.2.  Start-N-Sessions Command with Individual Session Control

  The message is terminated with a single block HMAC, as illustrated
  above.

How is this calculated?
I suspect you meant HMAC as defined in Section 3.2 of RFC 4656,
but it would be good to say this explicitly somewhere in the document
(Somewhere around Introduction? HMAC is used in several places in
the document.)
2010-04-03
07 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2010-04-01
07 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre
2010-03-31
07 Lars Eggert State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert
2010-03-31
07 Lars Eggert Placed on agenda for telechat - 2010-04-08 by Lars Eggert
2010-03-31
05 (System) New version available: draft-ietf-ippm-twamp-session-cntrl-05.txt
2010-03-31
07 Lars Eggert Waiting for revision or RFC Ed Note for gen-art review.
2010-03-19
07 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Tina Tsou.
2010-03-15
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-03-10
07 Amanda Baber
IANA questions/comments:

- IANA has no "bit position" registry for TWAMP. Where exactly is
this "bit position" supposed to be registered? The TWAMP-Modes
registry is …
IANA questions/comments:

- IANA has no "bit position" registry for TWAMP. Where exactly is
this "bit position" supposed to be registered? The TWAMP-Modes
registry is not defined as a bit registry, but a numeric registry.
If it's meant as a bit registry then it needs to be fixed. Section
6.1 does seem to imply the registry is not set up correctly.

- The TWAMP-Control Command Numbers registry appears to only contain
space for 16 entries (0-15). If it's supposed to contain 256 as
specified in section 6.1 then this registry also needs to be
corrected.


Action 1:

Upon approval of this document, IANA will make the following assignments
in the "TWAMP-Control Command Numbers" registry at
http://www.iana.org/assignments/twamp-parameters/twamp-parameters.xhtml

Value Description Semantics Definition Reference
------ ----------------- --------------------- ---------
TBD(7) Start-N-Sessions Section 3.2
[RFC-ippm-twamp-session-cntrl-04]
TBD(8) Start-N-Ack Section 3.3
[RFC-ippm-twamp-session-cntrl-04]
TBD(9) Stop-N-Sessions Section 3.4
[RFC-ippm-twamp-session-cntrl-04]
TBD(10) Stop-N-Ack Section 3.5
[RFC-ippm-twamp-session-cntrl-04]


Action 2:

Upon approval of this document, IANA will make the following assignments
in the "TWAMP-Modes" registry at
http://www.iana.org/assignments/twamp-parameters/twamp-parameters.xhtml

Value Description Semantics Definition Reference
------ ----------------- --------------------- ---------
TBD(16) Individual Session Section 3.1
[RFC-ippm-twamp-session-cntrl-04]
Control bit position (4)


We understand the above to be the only IANA Actions for this document.
2010-03-03
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tina Tsou
2010-03-03
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tina Tsou
2010-03-01
07 Amy Vezza Last call sent
2010-03-01
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-02-28
07 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2010-02-28
07 Lars Eggert Ballot has been issued by Lars Eggert
2010-02-28
07 Lars Eggert Created "Approve" ballot
2010-02-28
07 Lars Eggert State Changes to Last Call Requested from AD Evaluation by Lars Eggert
2010-02-28
07 Lars Eggert Last Call was requested by Lars Eggert
2010-02-28
07 (System) Ballot writeup text was added
2010-02-28
07 (System) Last call text was added
2010-02-28
07 (System) Ballot approval text was added
2010-02-28
04 (System) New version available: draft-ietf-ippm-twamp-session-cntrl-04.txt
2010-02-19
07 Lars Eggert State Changes to AD Evaluation from Publication Requested by Lars Eggert
2010-02-19
07 Lars Eggert [Note]: 'Henk Uijterwaal (henk.uijterwaal(at)ripe.net) is the document shepherd.' added by Lars Eggert
2010-02-18
07 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document sheperd is Henk Uijterwaal. He would not have bothered to write
this note if he didn't believe that the document was ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

This is a small feature request. About half a dozen people have read the
document and confirmed that this request will work without affecting current
implementations. The request itself seems to be a useful enhancement.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of?

No, there are no such concerns.

(1.e) 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?

Decent, with some 6 members of the group reviewing it.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits?

All except a complaint about the boilerplate. This can be fixed by
the editor easily.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

Yes, draft-ietf-ippm-twamp-reflect-octets. This draft has an ETA
of Q1/2010.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes, it exists and appears to be complete and consistent

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A.

(1.k) 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
The IETF has completed its work on the core specification of TWAMP -
the Two-Way Active Measurement Protocol. This memo describes a new
feature for TWAMP, that gives the controlling host the ability to
start and stop one or more individual test sessions using Session
Identifiers. The base capability of the TWAMP protocol requires all
test sessions previously requested and accepted to start and stop at
the same time.

Working Group Summary
The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noticing.

Document Quality
Good
2010-02-18
07 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2010-02-18
07 Cindy Morgan [Note]: 'Henk Uijterwaal (henk.uijterwaal(at)ripe.net) is the document shepherd.' added by Cindy Morgan
2010-02-17
03 (System) New version available: draft-ietf-ippm-twamp-session-cntrl-03.txt
2009-10-23
02 (System) New version available: draft-ietf-ippm-twamp-session-cntrl-02.txt
2009-09-08
07 (System) Document has expired
2009-03-07
01 (System) New version available: draft-ietf-ippm-twamp-session-cntrl-01.txt
2008-10-27
00 (System) New version available: draft-ietf-ippm-twamp-session-cntrl-00.txt