Skip to main content

Telechat Review of draft-ietf-tram-stunbis-16
review-ietf-tram-stunbis-16-artart-telechat-saint-andre-2018-04-02-00

Request Review of draft-ietf-tram-stunbis
Requested revision No specific revision (document currently at 21)
Type Telechat Review
Team ART Area Review Team (artart)
Deadline 2018-04-03
Requested 2018-02-20
Authors Marc Petit-Huguenin , Gonzalo Salgueiro , Jonathan Rosenberg , Dan Wing , Rohan Mahy , Philip Matthews
I-D last updated 2018-04-02
Completed reviews Genart Last Call review of -15 by Dale R. Worley (diff)
Secdir Last Call review of -16 by Matthew A. Miller (diff)
Genart Telechat review of -16 by Dale R. Worley (diff)
Artart Telechat review of -16 by Peter Saint-Andre (diff)
Assignment Reviewer Peter Saint-Andre
State Completed
Request Telechat review on draft-ietf-tram-stunbis by ART Area Review Team Assigned
Reviewed revision 16 (document currently at 21)
Result Ready w/nits
Completed 2018-04-02
review-ietf-tram-stunbis-16-artart-telechat-saint-andre-2018-04-02-00
Section 1 states:

   Implementations and deployments of a STUN usage using TLS or DTLS
   should follow the recommendations in [RFC7525].

Wouldn't the security considerations be a better location for that text?

And given that this specification cites RFC 8174, I suggest changing
"should" to "SHOULD".

(I suggest that the authors review the usage of lowercase and uppercase
requirements keywords, because there might be inconsistencies, e.g., in
the first paragraphs of Section 6.1 and Section 6.2.)

In Section 4, please consider spelling out "SIP" on first use and
including a reference to RFC 3261.

The first paragaraph of Section 6.2.3 restates recommendations from RFC
7525; why not simply reference that specification?

Section 6.3.4 states:

   o  If the error code is 500 through 599, the client MAY resend the
      request; clients that do so MUST limit the number of times they do
      this.

It is reasonable to provide guidance as to the number of re-sends?

Section 9.1.1 and other sections invoke the OpaqueString profile of the
PRECIS FreeformClass; it might be helpful to mention that the profile is
used to handle Unicode characters outside the ASCII range, and that no
changes result if only ASCII characters are used.

In Section 14.2, please consider spelling out "ALG" on first use.

A reference to RFC 6151 seems appropriate regarding the fact that this
specification retains the use of MD5; in particular, the usage here is
actually HMAC-MD5, which is still sanctioned by RFC 6151.