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.