Skip to main content

Last Call Review of draft-ietf-mmusic-proto-iana-registration-05
review-ietf-mmusic-proto-iana-registration-05-secdir-lc-montville-2016-02-25-00

Request Review of draft-ietf-mmusic-proto-iana-registration
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-02-26
Requested 2016-02-17
Authors Suhas Nandakumar
I-D last updated 2016-02-25
Completed reviews Genart Last Call review of -05 by Meral Shirazipour (diff)
Genart Telechat review of -06 by Meral Shirazipour
Secdir Last Call review of -05 by Adam W. Montville (diff)
Opsdir Last Call review of -05 by Sarah Banks (diff)
Assignment Reviewer Adam W. Montville
State Completed
Request Last Call review on draft-ietf-mmusic-proto-iana-registration by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 06)
Result Has nits
Completed 2016-02-25
review-ietf-mmusic-proto-iana-registration-05-secdir-lc-montville-2016-02-25-00
Hi,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This draft specifies the transport realization for seven additional Session
Description Protocol identifiers and creates a corresponding IANA registry for
such, and relies on previously written security considerations, as it does not
appear to introduce any new considerations.

Overall, this document is straightforward in purpose and is ready with nits.

Possibly minor nits:

The first use of “SDP” in the first section is not spelled out.  I know that it
is spelled out in the abstract, and I cannot recall what is/is not good form
here.  To me, it would be more helpful if SDP were spelled out one more time in
that first section (second paragraph of section 1).

In general, I favor writing for the reader over writing for the author.  As
such I do not prefer using RFC identifiers as a replacement for a proper title,
which would convey more meaning without dereferencing.  For example, in the
second sentence of the second paragraph of section 1: “[RFC4145] specifies a
general mechanism for…”  gets in the way of the primary purpose of the sentence
when the reader needs to look up that reference to gain a clue.  This is
especially true for readers new to the problem domain, which also means that
this nit may not apply (it may well be expected that readers of this particular
draft are not reasonably expected to be new to the domain).

Kind regards,

Adam