Interworking SIP and Intelligent Network (IN) Applications
draft-gurbani-sin-02

[Ballot comment]
If this were a standards track document, my evaluation would be a DISCUSS, because the Security Considerations section is inadequate.  It says that some messages "must be secured", but says nothing of what sort of security is needed.  It says nothing of authorization requirements or mechanisms for the SIN service, let alone how SIP-level authentication information is conveyed across the IN so that a remote SIP proxy can make its own authorization decisions.  And it speaks of using  SIP security "if the need be", without explaining how that decision is made, or what the risks are if any of these security mechanisms are not used.

For Section 3.4, see draft-burger-sipping-netann for a way to do announcements in SIP.  (Note: that's not a standards-track document.)

Nit: "egress" is not a verb.

[Ballot comment]
My reading is the [2], [8], and [9] are all needed to make sense of the SIP/BCSM
mapping.  Only [2] is normative, though; I'd suggest that all three of these would
need to be normative.

Have we asked Scott Bradner to check with ITU-T on this, or is otherwise known to
be something they've reviewed?

[Ballot comment]
My reading is the [2], [8], and [9] are all needed to make sense of the SIP/BCSM
mapping.  Only [2] is normative, though; I'd suggest that all three of these would
need to be normative.

Have we asked Scott to check with ITU-T on this, or is otherwise known to
be something they've reviewed?

[Note]: 'On several occasions the SIP and SIPPING WGs stated that this was not an end-run.  Issues remained:  no SIP-ite could review the IN stuff; what org will think we''re end-running them when it comes out?  Some diligence did not identify one, but TSV has been burned before.  New  iesg / rfc-ed model means these issues have much less weight on IETF.' added by Allison Mankin