Skip to main content

Last Call Review of draft-mohali-dispatch-cause-for-service-number-12

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
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.