Considerations for Information Services and Operator Services Using SIP
draft-haluska-sipping-directory-assistance-11

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

(Robert Sparks) Yes

(Jari Arkko) (was Discuss, No Objection) No Objection

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2011-10-18)
No email
send info
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.

(Stephen Farrell) No Objection

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

(Pete Resnick) No Objection

Comment (2011-10-18)
No email
send info
I agree with Adrian that we should also ask for the opportunity to include a statement if the ISE decides to publish.

(Sean Turner) No Objection