Last Call Review of draft-mohali-dispatch-cause-for-service-number-12
review-mohali-dispatch-cause-for-service-number-12-secdir-lc-sparks-2016-12-22-00
Request | Review of | draft-mohali-dispatch-cause-for-service-number |
---|---|---|
Requested revision | No specific revision (document currently at 14) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2017-01-18 | |
Requested | 2016-12-14 | |
Authors | Marianne Mohali , Mary Barnes | |
I-D last updated | 2016-12-22 | |
Completed reviews |
Secdir Last Call review of -12
by Robert Sparks
(diff)
Genart Last Call review of -12 by Joel M. Halpern (diff) Opsdir Last Call review of -12 by Lionel Morand (diff) |
|
Assignment | Reviewer | Robert Sparks |
State | Completed | |
Request | Last Call review on draft-mohali-dispatch-cause-for-service-number by Security Area Directorate Assigned | |
Reviewed revision | 12 (document currently at 14) | |
Result | Ready | |
Completed | 2016-12-22 |
review-mohali-dispatch-cause-for-service-number-12-secdir-lc-sparks-2016-12-22-00
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. Document : draft-mohali-dispatch-cause-for-service-number-12 Summary: Ready for publication as an Informational RFC This document adds a value to use with the SIP "cause" URI parameter that means 'This URI is like it is because a service number translation service produced it'. Its key value is added when the URI appears in the sequence of URIs in the History-Info header field, letting a subsequent service, or recipient's user agent (particularly when the recipient is someone in a call center ) know more about who the caller was really trying to reach. This document doesn't change the security landscape for use of the cause URI parameter or the History-Info header mechanics. The only information it adds for consideration is that a number translation service was used. The History-Info mechanism (RFC7044) has significant security and privacy considerations. This document points strongly to that document, which points to the SIP Privacy mechanism (RFC3323). Again, adding this cause number does not add new considerations for the use of that mechanism. There has been a lot of discussion about whether this document should proceed as Informational, mostly rooted in the IANA registation policy for the registry containing the "cause" URI parameter. (This document asks to add itself as a reference to that existing registration). The shepherd's writeup does a good job of explaining why Informational is appropriate.