Interworking SIP and Intelligent Network (IN) Applications
Note: This ballot was opened for revision 02 and is now closed.
Allison Mankin Former IESG member
Bert Wijnen Former IESG member
No Objection (2004-03-18)
There are quite a set of example that use lucent.com And that probably should use example.com
David Kessens Former IESG member
No Objection ()
Harald Alvestrand Former IESG member
No Objection (2004-03-16)
Reviewed for GEN-ART by Mark Allman.
Russ Housley Former IESG member
No Objection ()
Scott Hollenbeck Former IESG member
No Objection (2004-03-15)
The "Full Copyright Statement" has been truncated, but I suppose that the text will be replaced by the RFC Editor with something appropriate.
Ted Hardie Former IESG member
No Objection (2004-03-17)
My reading is the , , and  are all needed to make sense of the SIP/BCSM mapping. Only  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?
Jon Peterson Former IESG member
Steven Bellovin Former IESG member
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.