Interworking SIP and Intelligent Network (IN) Applications
RFC 3976

Note: This ballot was opened for revision 02 and is now closed.

(Allison Mankin) Yes

(Harald Alvestrand) No Objection

Comment (2004-03-16)
No email
send info
Reviewed for GEN-ART by Mark Allman.

(Ted Hardie) No Objection

Comment (2004-03-17)
No email
send info
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?

(Scott Hollenbeck) No Objection

Comment (2004-03-15)
No email
send info
The "Full Copyright Statement" has been truncated, but I suppose that the text will be replaced by the RFC Editor with something appropriate.

(Russ Housley) No Objection

(David Kessens) No Objection

(Bert Wijnen) No Objection

Comment (2004-03-18)
No email
send info
There are quite a set of example that use
      lucent.com
And that probably should use
      example.com

(Steven Bellovin) Abstain

Comment (2004-03-17)
No email
send info
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.

(Jon Peterson) Abstain