Considerations for Information Services and Operator Services Using SIP
draft-haluska-sipping-directory-assistance-11
Yes
(Robert Sparks)
No Objection
(Gonzalo Camarillo)
(Jari Arkko)
(Ron Bonica)
(Sean Turner)
Note: This ballot was opened for revision 11 and is now closed.
Robert Sparks Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2011-10-18)
Unknown
I suspect that parts of this document could have been acceptable for publication, but the document has tried to do too much and cover too much ground. To some extent, this can be seen from the mixed message about the purpose of the document. The Abstract says: This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers. But Section 1 says: Implementing Operator and Information Services with SIP will require the exchange of certain information, and possibly the use of specialized capabilities which are not normally required for other types of calls. This document aims to identify such information, and stimulate discussion about how this information could be exchanged. Existing mechanisms will be used where appropriate, and currently existing proposals will be favored over new extensions. That is a lot of different purposes, and some of them run flat up against core IETF work as Robert indicates. I think that if you had limited yourselves to This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, and to provide a set of Best Current Practices to facilitate interoperability. you would probably have found more suport for the document and possibly support from within the working group.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2011-10-20)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2011-10-18)
Unknown
I agree with Adrian that we should also ask for the opportunity to include a statement if the ISE decides to publish.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2011-10-17)
Unknown
I agree with the proposed 5742 response, i.e. to recommend not publishing at this time. I also have some comments below that the authors might want to take into account. - "MF" isn't defined/explained (p6, used twice), as are a bunch of other acronyms (ISUP, TNS, CIP, CSI...). Not sure which need definitions but I guess some at least do. - p22 - listening to "a scrambled version" of the call seems odd - is that a real service? what kind of "scrambling"? - 2nd last para of p29 says when you've no identity info, you "MAY be unable" to do stuff - would that be better with a "SHOULD or MUST NOT implement" since attempting to do so would presumably go against the caller's wishes or the inter-domain agreements between the various providers? - There are many occurrences of phrases like "in North America." (`grep America draft-haluska-* | wc` -> 38; Europe occurs twice and Asia not at all.) So many in fact, that I wonder if the title should be changed to reflect that - this really seems like a North American oriented document. (Having said that, I've no real clue as to whether the actual content is more broadly applicable or not.) - Section 9.16 seems to depend on sending an obfuscated URI for the "whisper" audio. That should raise a bunch of security considerations, but those are not addressed, at least in 9.16. There would also be questions as to when that audio can safely be deleted, and potential privacy concerns if it is not promptly deleted that don't seem to be addressed. - Title of 9.20 - s/With Holding/Withholding/ and similarly within the body of the section s/with held/withheld/ etc - The "intercept-*" sip URIs described in 11.4.1 seem odd. Wouldn't doing that require these to be specially registered in some IANA registry that every SIP UA and other SIP implementation knows about in order to prevent fairly nasty attacks? - I didn't read the "collect call" and 3rd party billing things very closely but they seem fairly ripe for fraud. A section showing why this is not the case would seem to be missing, especially as 11.5 says that collect calling could be done without human intervention. I guess I'd start thinking about attacking this by re-routing the RTP streams maybe but the point is that if the authors have thought through the potential for fraud, I'd have expected some text about that. - The security considerations basically says "look at the references and the rest is TBD" but in more words;-) That may be ok in a document like this, but its not very satisfactory that the proposed services have been defined down to the level of message flows but with no security analysis being provided.