Reviewer: Robert Sparks
Review result: Ready
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.