Review of draft-mohali-dispatch-cause-for-service-number-12
Robert Sparks <firstname.lastname@example.org> Thu, 22 December 2016 19:07 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8340712947C; Thu, 22 Dec 2016 11:07:40 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Robert Sparks <email@example.com>
Subject: Review of draft-mohali-dispatch-cause-for-service-number-12
Date: Thu, 22 Dec 2016 11:07:40 -0800
Cc: firstname.lastname@example.org, email@example.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2016 19:07:40 -0000
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.
- Review of draft-mohali-dispatch-cause-for-service… Robert Sparks
- Re: Review of draft-mohali-dispatch-cause-for-ser… jmh.direct