Test Vectors for Session Traversal Utilities for NAT (STUN)
RFC 5769

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

Lars Eggert No Objection

(Magnus Westerlund; former steering group member) Yes

(Chris Newman; former steering group member) No Objection

(Cullen Jennings; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

Christian Vogt's review:

I was asked to do a review of draft-ietf-behave-stun-test-vectors-03 for
IESG evaluation, and I found the document to be ready for publication:

This document provides samples of STUN messages that have been found to
cause interoperability problems across implementations.  The goal is to
help making implementations standard-conform and interoperable.
Overall, the document is certainly ready for publication.  Just a minor
editorial improvement suggestion below.

In section 2, the document states:

    In this document, ASCII white spaces (U+0020) are used for padding
    within the first three messages - this is arbitrary.  Similarly,
    the last message uses nul bytes for padding. [...]

For the sake of clarity, there should be a statement about the possible
values that a padding byte may take.  I understand the text above to
mean that padding bytes can take any value.  Suggest re-wording to:  "In
general, padding bytes may take any value.  For the sample messages in
this document, ASCII white spaces (U+0020) were used for padding in the
first three messages, and null bytes were used for padding in the last
message."

(Mark Townsley; former steering group member) No Objection

(Pasi Eronen; former steering group member) (was Discuss, No Objection) No Objection

A clarifying question: is the user name in Section 2.4 before
SASLprep processing or after? (or does it matter for this string?)

It would be useful to show the password in Section 2.4 also
after SASLprep processing (it seems this particular string
is changed by SASLprep)

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Tim Polk; former steering group member) No Objection

I am comfortable with the technical content in this draft, but find the Abstract and body of the
text internally inconsistent.  It seems that the scope kept expanding as the authors progressed
through the document, but never revised the front matter.

Specifically, the Abstract implies that there are only two STUN attributes that can appear in
STUN messages.  The Introduction indicates that there are two STUN attributes that include
hashes in STUN messages, and that these are in the sample messages.  Section 2, Test
Vectors, notes that the three most problematic STUN attributes are FINGERPRINT,
MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS and the document has test vectors for
each of these attributes. An additional message covers STUN authentication with long term
credentials.

From the Abstract and Introduction, I am afraid the reader will not realize the full scope of
the test vectors and may not perform some appropriate tests.  I would suggest a quick scrub
to consistently present the actual scope of the given test vectors.