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