Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)
RFC 5618

[Ballot discuss] I believe that this is a clear and well written document and I am prepard to cast a 'Yes' vote in the ballot ...

[Ballot discuss]
I believe that this is a clear and well written document and I am prepard to cast a 'Yes' vote in the ballot, but it looks to me that there is a problem in the IANA Consideration section:

6.1.  Registry Specification

  IANA is requested to create a TWAMP-Modes registry.  TWAMP-Modes are
  specified in TWAMP Server Greeting messages and Set-up Response
  messages consistent with section 3.1 of [RFC4656] and section 3.1 of
  [RFC5357], and extended by this memo.  Modes are currently indicated
  by setting single bits in the 32-bit Modes Field.  However, more
  complex encoding may be used in the future.  Thus, this registry can
  contain a total of 2^32 possible assignments.

I think that this relaxation of the rules that allows to set multiple bits in the Modes field conflicts with the definition of the field in section 3.1 of RFC 4656:

>  The first 29 bits MUST be zero.  A
  client MUST ignore the values in the first 29 bits of the Modes
  value.  (This way, the bits are available for future protocol
  extensions.  This is the only intended extension mechanism.)

We are now using the 4th bit, so the client cannot ignore more than 28 bits. The MUST in 4656 seems to be too strict and needs to be amended at the first opportunity. I would suggest that a short discussion about this is inserted in the document, and that the header also mentions that RFC 4656 will be updated at the approval of the document.

IANA comments: NOTE: The registration procedure should be "IETF Review" rather than "IETF Consensus," per RFC5226. Upon approval of this document, IANA will create the ...

IANA comments:

NOTE: The registration procedure should be "IETF Review" rather than
"IETF Consensus," per RFC5226.

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

Registry Name: TWAMP-Modes
Registration Procedures: IETF Review
Initial contents of this registry will be:

Value Description Reference
-------- ------------ ----------
0 Reserved [RFC-ippm-more-twamp-01]
1 Unauthenticated [RFC4656] Section 3.1
2 Authenticated [RFC4656] Section 3.1
4 Encrypted [RFC4656] Section 3.1
8 Unauth. TEST protocol, Encrypted CONTROL [RFC-ippm-more-twamp-01] Section 3.1
16-2^31 Unassigned

We understand the above to be the only IANA Action for this document.

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

> (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?
>
> The document shepherd is Henk Uijterwaal <henk@ripe.net>. I have
> personally
> reviewed this document and would not have bothered to write this
> note if I
> didn't feel it was ready for the IESG.
>
> (1.b) Has the document had adequate review both from key WG
> members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?
>
> I believe the document has received sufficent review from WG members.
> This is a small extension to a thoroughly reviewed protocol. I have
> no
> concerns about the depth or breadth of reivews for this document.
>
> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar
> with
> AAA, internationalization or XML?
>
> 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?
>
> None.
>
> Has an IPR disclosure related to this document been filed?
>
> No.
>
> (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?
>
> This is an extension to an existing protocol (TWAMP, RFC 5357). The
> issue
> came up when the TWAMP protocol was close to completion. As the WG
> wanted
> to finish TWAMP, it was decided to put possible extensions in another
> document. TWAMP is actively being used by several groups these days,
> none of them raised any issues with the document. The document
> authors are
> both involved with 2 of the implementations of the protocol and would
> have flagged any issues.
>
> (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?
>
> There are the following issues:
>
> ** It looks like you're using RFC 3978 boilerplate. You should
> update this
> to the boilerplate described in the IETF Trust License Policy
> document
> (see http://trustee.ietf.org/license-info), which is required
> from
> December 16, 2008. Version 1.34 of xml2rfc can be used to
> produce
> documents with boilerplate according to the mentioned Trust
> License
> Policy document.
>
> It is not clear to me if this is correct, as the document was
> submitted
> before Nov 10 (i.e. pre-5378).
>
> == Missing Reference: '0-31' is mentioned on line 257, but not
> defined
>
> This looks like an error in the tool.
>
> == Unused Reference: 'RFC2434' is defined on line 292, but no
> explicit
> reference was found in the text
>
> ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
>
> This reference can go.
>
>
> Has the document met all formal review criteria it needs
> to, such
> as the MIB Doctor, media type and URI type reviews?
>
> None of these are necessary.
>
> (1.h) Has the document split its references into normative and
> informative?
>
> Yes, the informative reference section can be removed on publication
> as
> there are none.
>
> Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state?
>
> No.
>
> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document?
>
> There is an IANA considerations section, it is 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?
>
> Not applicable.
>
> (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 TWAMP - the Two-Way Active
> Measurement Protocol. This memo describes a simple extension to
> TWAMP, the option to use different security modes in the TWAMP-
> Control and TWAMP-Test protocols.
>
>
>
> Working Group Summary
> Was there anything in WG process that is worth noting?
> For
> example, was there controversy about particular points or
> were there decisions where the consensus was particularly
> rough?
>
> This document was discussed at various IETF meetings in 2008. There
> was no controversy in the WG process. Consensus was smooth.
>
> Document Quality
> Are there existing implementations of the protocol?
>
> Yes, at least 3 vendors are implementing TWAMP.