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.

The base Sip specification (RFC 3261) includes an Alert-Info header field
that may reference an audio file to be rendered to the user as a ring tone
or ringback tone. Draft-ietf-salud-alert-info-urns updates RFC 3261 to
allow the Alert-info feel to include a URN that indicates the type of ring
tone or ringback tone that is appropriate for the current call, and then
the user agent can use this URN to select an appropriate alert to render to
the user (e.g., based on the capabilities of user's device and the user's
preferences).

>From a security point of view, the mechanism specified in this document is
very desirable, since it eliminates the potential security concerns
associated with a request to fetch and render an arbitrary audio file
provided by a (potentially untrusted) remote system.

This document is generally ready for publication. I agree with the authors
that specified usage of the new alert URN namespace does not raise
significant new security concerns. However, I have one minor concern about
the security considerations text, which I discuss below.

The authors correctly note that the use particular alert indicators (that
might reasonably be provisioned within this namespace) may introduce
privacy concerns. For example, the alert-info value might reasonably
include information about the calling party, the calling party's location
(e.g., local vs international) or the calling party's device. (Note that in
many cases there will be as much or more information about the calling
party in other SIP headers, but it is definitely worth noting that this is
a header field where privacy-relevant information may reside.)

Therefore, the security considerations text goes on to say "Such provision
SHALL always be explicitly authorized by the party (caller or callee) the
information in the 'alert' URN refers to."

I find the above text somewhat confusing, and I would appreciate it the
authors could add a bit of text to clarify what they mean. Does this
sentence mean that if I am implementing a User-Agent that I MUST NOT
include any URN in the alert-info field without an explicit authorization
from the user? Or perhaps it means that certain categories of alert URNs
(the privacy-relevant ones) MUST NOT be included in the alert-info field
without an explicit authorization from the user? (If this is the case, then
obviously a bit of guidance is needed with regards to which types of alert
URNs require explicit user authorization).

Furthermore, I believe that the above sentence means that if I am
implementing a proxy that I MUST NOT add any alert URN to an outgoing (or
incoming) call without explicit authorization from the user. (Or again,
perhaps it only means certain privacy-relevant alert URNs). I think this
paragraph would be more clear if there were separate normative statement
for the behavior of proxies and user agents.

That is, for these type of privacy considerations, I think it is very
helpful to be very clear/explicit about what information various entities
are allowed to put into this header field (without authorization from the
user).

As I final note, it might be reasonable to add a sentence that
reminds implementers that due to the potential privacy implications of the
alert-info header field that when this header is included (or perhaps when
certain categories of alert URNs are placed in this header field), the SIP
message SHOULD be protected via TLS. However, I understand that: (1) There
are a number of practical impediments to the use of TLS to protect SIP
traffic; and (2) Given the privacy-relevant information that is likely
contained in other SIP headers, the recommendation to use TLS is in now
ways specific to the presence of the alert-info field. Therefore, although
I think a reminder to use TLS when possible might be appropriate, I can
understand why the authors might reasonably chose to leave out such text.