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

Removed document from Independent Stream

Was originally brought to the IESG for a conflict review consistent with RFC5742. The IESG responded requesting the ISE "Do Not Publish". Explanation of this can be seen in the material in the IESG Comments and History tabs.

Notify list changed from jhaluska@telcordia.com,  rberkowi@telcordia.com, proder2@telcordia.com, wdownum@telcordia.com, Richard.Ahern@bellsouth.com, ncostantino@soleocommunications.com, chris.blackwell@verizon.com, james.j.mellinger@verizon.com, rfc-ise@rfc-editor.org to james.j.mellinger@verizon.com, proder2@telcordia.com, rfc-ise@rfc-editor.org, ncostantino@soleocommunications.com, wdownum@telcordia.com, rberkowi@telcordia.com

[Ballot comment]
I cleared my Discuss understanding that Robert will add a note to the 5742 recommendation.

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.

[Ballot discuss]
I'm not sure I understand why a document that says "here's one way of using IETF protocols for " and "here are some unmet requirements for " can be considered as harmful for an IETF working group, even if that working group is focusing on the same space. I think a note with pointer to the IETF work would be more reasonable reaction in this case.

But I don't work in this field, so maybe I'm missing something obvious.

[Ballot comment]
I'm not sure I understand why a document that says "here's one way of using IETF protocols for " and "here are some unmet requirements for " can be considered as harmful for an IETF working group, even if that working group is focusing on the same space. I think a note with pointer to the IETF work would be more reasonable reaction in this case.

But I don't work in this field, so maybe I'm missing something obvious.

[Ballot comment]
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.

[Ballot discuss]
As this docuent stands, I support Robert's 5742 review. According to
5742, I think Robert's feedback to the ISE should include the request
that the IESG should be allowed to add an IESG note to the document
in the event that the ISE decides to publish it.

I also think it would be helpful (although not required by 5742) to
clarify "at this time." Does the IESG forsee a time at which publication
would be OK?

[Ballot comment]
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.

The draft draft-draft-haluska-sipping-directory-assistance-11.txt
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

From its abstract:
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.

It was reviewed by Hadriel Kaplan, recommended to me as someone
with a really good understanding of SIP. Hadriel made quite extensive
comments; John Haluska has worked with him to correct misunderstandings
and generally improve the draft.

Thanks, Nevil (ISE)

State Change Notice email list has been changed to jhaluska@telcordia.com,  rberkowi@telcordia.com, proder2@telcordia.com, wdownum@telcordia.com, Richard.Ahern@bellsouth.com, ncostantino@soleocommunications.com, chris.blackwell@verizon.com, james.j.mellinger@verizon.com, rfc-ise@rfc-editor.org from jhaluska@telcordia.com,  rberkowi@telcordia.com, proder2@telcordia.com, wdownum@telcordia.com, Richard.Ahern@bellsouth.com, paul.lumlung@qwest.com, ncostantino@soleocommunications.com, chris.blackwell@verizon.com, james.j.mellinger@verizon.com, rfc-ise@rf

State Change Notice email list have been change to jhaluska@telcordia.com,  rberkowi@telcordia.com, proder2@telcordia.com, wdownum@telcordia.com, Richard.Ahern@bellsouth.com, paul.lumlung@qwest.com, ncostantino@soleocommunications.com, chris.blackwell@verizon.com, james.j.mellinger@verizon.com, rfc-ise@rfc-editor.org from jhaluska@telcordia.com,  rberkowi@telcordia.com, proder2@telcordia.com, wdownum@telcordia.com, Richard.Ahern@bellsouth.com, paul.lumlung@qwest.com, ncostantino@soleocommunications.com, chris.blackwell@verizon.com, james.j.mellinger@verizon.c

State Change Notice email list have been change to jhaluska@telcordia.com,  rberkowi@telcordia.com, proder2@telcordia.com, wdownum@telcordia.com, Richard.Ahern@bellsouth.com, paul.lumlung@qwest.com, ncostantino@soleocommunications.com, chris.blackwell@verizon.com, james.j.mellinger@verizon.c from jhaluska@telcordia.com, ipr@ietf.org., rberkowi@telcordia.com, proder2@telcordia.com, wdownum@telcordia.com, Richard.Ahern@bellsouth.com, paul.lumlung@qwest.com, ncostantino@soleocommunications.com, chris.blackwell@verizon.com, james.j.mellinger@verizon.c