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 rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-02-26
Requested 2016-02-17
Other Reviews Genart Last Call review of -05 by Meral Shirazipour (diff)
Genart Telechat review of -06 by Meral Shirazipour
Opsdir Last Call review of -05 by Sarah Banks (diff)
Review State Completed
Reviewer Adam Montville
Review review-ietf-mmusic-proto-iana-registration-05-secdir-lc-montville-2016-02-25
Posted at https://www.ietf.org/mail-archive/web/secdir/current/msg06394.html
Reviewed rev. 05 (document currently at 06)
Review result Has Nits
Draft last updated 2016-02-25
Review completed: 2016-02-25

Review
review-ietf-mmusic-proto-iana-registration-05-secdir-lc-montville-2016-02-25

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