Re: [Sipping] Initial review of draft-ietf-sipping-service-identification-00

[Jonathan Rosenberg <[e-mail]>]

Spencer,

My revision of this document is extremely tardy. My apologies for the 
long delay in responding and in doing the update. Responses inline:

Spencer Dawkins wrote:
> Hi, Jonathan,
> 
> I am one of the "intial review to make sure we're one the right track" 
> reviewers for this draft. I hope this review is helpful.
> 
> This draft is on the right track. I have more nit-level comments than 
> anything else.
> 
> I also wanted to thank you for putting this together. It's one of the 
> most helpful things anyone has done lately to improve interaction with 
> other SDOs ("we're too busy telling other SDOs something is a bad idea 
> to write a draft explaining why"), and it's very clear for a 00 draft.
> 
> I have a couple of additional topics at the end of Section 6.
> 
> /Spencer:/for substantive comments, /Spencer (nit):/ for nits.
> 
> Thanks,
> 
> Spencer
> 
> Abstract
> 
>   This document considers the problem of service identification in the
>   Session Initiation Protocol (SIP).  Service identification is the
>   process of determining the user-level use case that is driving the
>   signaling being utilized by the user agent.  While seemingly simple,
>   this process is quite complex, and when not addressed properly, can
>   lead to fraud, interoperability problems, and stifling of innovation.
> 
> Spencer: is this ordering (fraud, interoperability problems, and 
> stifling of innovation) the right one?

This got rewritten a bit based on the apps review comments. It now reads:

             <t>This document considers the problem of service
	    identification in the Session Initiation Protocol
	    (SIP). Service identification is the process of
	    determining the user-level use case that is driving the
	    signaling being utilized by the user agent. This document
	    discusses the uses of service identification, and outlines
	    several architectural principles behind the process. It
	    identifies several perils associated with service
	    identification, including fraud, interoperability failures
	    and stifling of innovation.
	    </t>

the ordering reflects the section ordering and I do think it makes sense.

> 
>   This document discusses these problems and makes recommendations on
>   how to address them.
> 
> Spencer: It might be nice to give some indication of WHY the process is 
> complex...

Removed the 'complex' hyperbole in the rewritten abstract.

> 
> 1.  Introduction
> 
>   This breadth of applicability is SIPs greatest asset, but it also
> 
> Spencer (nit): s/SIPs/SIP's/

fixed

> 
>   introduces numerous challenges.  One of these is that, when an
>   endpoint generates a SIP INVITE for a session, or receives one, that
>   session can potentially be within the context of any number of
>   different use cases and endpoint types.  For example, a SIP INVITE
>   with a single audio stream could represent a Push-To-Talk session
> 
> Spencer (nit): got a reference for Push-to-Talk?

Not really... there is probably some OMA reference but I don't think its 
useful. In the modern era, google and wikipedia are better than any 
reference I could give.


> 
>   between mobile devices, a VoIP session between softphones, or audio-
>   based access to stored content on a server.
> 
> 2.  Terminology
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119 [1].
> 
> Spencer: I'm questioning the use of NOT RECOMMENDED in the security 
> section (I don't think it is really 2119 language), and if that's 
> changed, there are no other uses of 2119 language in this document.

I removed this section and made the document informational.

> 
> 3.  Services and Service Identification
> 
>   The problem of identifying services within SIP is not a new one.  The
>   problem has been considered extensively in the context of presence.
>   In particular, the presence data model for SIP [3] defines the
>   concept of a service as one of the core notions that presence
>   describes.  Services are described in Section 3.3 of RFC 4479, which
>   has this to say on the topic:
> 
>   3.3.  Service
> 
> Spencer (extreme nit): it's probably good to drop the "3.3", since 
> you've already given the detailed reference in the previous paragraph, 
> and it's misleading at first glance. Yeah, this insertion is indented. 
> Yeah, I was still confused.

The apps review said the same thing. I removed the quoted text and just 
referenced RFC 4479.

> 
> 4.1.  IPTV vs. Multimedia
> 
>   IP Television (IPTV) is the usage of IP networks to access
>   traditional television content, such as movies and shows.  SIP can be
>   utilized to establish a session to a media server in a network, which
>   then serves up multimedia content and streams it as an audio and
>   video stream towards the client.  Whether SIP is ideal for IPTV is,
>   in itself, a good question.  However, such a discussion is outside
>   the scope of this document.
> 
> Spencer (nit): the "whether/however" text in this paragraph could 
> reasonably be moved to Section 4, because it's applicable to multiple 
> example services...

I think its fine here.

> 
>   Consider multimedia conferencing.  The user accesses a voice and
>   video conference at a conference server.  The user might join in
>   listen-only mode, in which case the user receives audio and video
>   streams, but does not send.
> 
> 4.3.  Configuration vs. Pager Messaging
> 
>   However, MESSAGE is sometimes used for the delivery of content to a
>   device for other purposes.  For example, some providers use it to
>   deliver configuration updates, such as new phone settings or
>   parameters, or to indicate that a new version of firmware is
>   available.  Though not designed for this purpose, MESSAGE gets used
>   since, in existing wireless networks, SMS are used for this purpose,
> 
> Spencer (nit): "SMS" is singular - s/SMS are/SMS is/, which is also more 
> correct...

fixed

> 
>   and MESSAGE is the SIP equivalent of SMS.
> 
> 5.  Using Service Identification
> 
>   It is important to understand what the service identity would be
>   utilized for, if known.  The discussions in Section 4 give some hints
>   to the possible usages.  Here, we explicitly discuss them.
> 
> Spencer: I may be having pronoun problems ("them"?), but if this 
> paragraph says "hints to the possible usages of service identity", I am 
> confused - I didn't see anything that looked like that. Maybe "The 
> description of possible services in Section 4 provide a basis for 
> discussing how service identity could be used in this section"?

Reworded to:

<t>
It is important to understand what the service identity would be
utilized for, if known. This section discusses the primary uses. These
are application invocation in user agents and the network, Quality of
Service authorization, service authorization, accounting and billing,
service negotiation, and device dispatch.
</t>


> 
> 5.2.  Application Invocation in the Network
> 
>   Another usage of a service identifier would be to cause servers in
>   the SIP network to provide additional processing, based on the
>   service.  For example, an INVITE issued by a user agent for IPTV
>   would pass through a server that does some kind of content rights
>   management, authorizing whether the user is allowed to access that
>   content.  On the other hand, an INVITE issued by a user for
>   multimedia conferencing would pass through a server providing
>   "traditional" telephony features, such as outbound call screening and
>   call recording.  It would make no sense for the INVITE associated
>   with IPTV to have outbound call screening and call recording applied,
>   and it would make no sense for the multimedia conferencing INVITE to
>   be processed by the content rights management server.  Indeed, in
>   these cases, its not just an efficiency issue (invoking servers when
> 
> Spencer (nit): s/its/it's/

fixed

> 
>   not needed), but rather, truly incorrect behavior can occur.  For
>   example, if an outbound call screening application is set to block
>   outbound calls to everything except for the phone numbers of friends
>   and family, an IPTV request that gets processed by such a server
>   would be blocked (as its not targeted to the AOR of a friend or
> 
> Spencer (nit): s/its/it's/

fixed

> 
>   family member).  This would block a user's attempt to access IPTV
>   services, when that was not the goal at all.
> 
> 5.5.  Accounting and Billing
> 
>   Service authorization and accounting/billing go hand in hand.
>   Presumably, one of the primary reasons for authorizing that a user
> 
> Spencer (nit): I think you can drop the "presumably"... :-)

dropped.

> 
>   can utilize a service is that they are being billed differently based
>   on the type of service.  Consequently, one of the goals of a service
>   identity is to be able to include it in accounting records, so that
>   the appropriate billing model can be applied.
> 
> 5.6.  Negotiation of Service
> 
>   As an example, s user can do both the game and the voice chat service
>   of Section 4.2.  They initiate a session to a target AOR, but the
>   devices used by that user can only support voice chat.  Consequently,
> 
> Spencer: this wasn't quite clear enough to me - s/Consequently/The 
> called device responds based on its service capability and/?

clarified to say:

chat. The called device returns, in its call acceptance, an indication
that only voice chat can be used. Consequently, voice chat gets
utilized for the session.

> 
>   voice chat gets utilized for the session.
> 
> 6.  Key Principles of Service Identification
> 
>   In this section, we describe some of the key principles of performing
>   service identification.
> 
> Spencer: this is totally presentation-layer, but it would help me to 
> "get it" if you collected the principles scattered throughout this 
> section, and put them together in one list (probably at this point in 
> the document). I'm saying this because I think they are really 
> important, and they would "stand alone", even if the explanatory text is 
> included in subsequent subsections. Think "numbered list"...

I reworked this a bunch. The new organization has each principle as a 
section title and they are enumerated in the top-level sections. I think 
its clearer now.

> 
> 6.1.  Services are a By-Product of Signaling
> 
>   This is ultimately an expression of the principle of DWIM vs. DWIS
>   (Do-What-I-Mean vs. Do-What-I-Say).  Explicit signaling is DWIS - the
>   user is asking for a service by invoking the signaling that results
>   in the desired effect.  A service identifier is DWIM - an unspecific
>   request for something that is ill-defined and non-interoperable.
> 
> Spencer: this is slightly harsher than I understand the situation to be 
> - perhaps "A service identifier is DWIM - the user is asking for a 
> service but is including information that isn't necessary to result in 
> the desired effect, and there is no direct connection between the 
> service identifier that the user provides and the service the user 
> receives"?

No - its DWIM because there is no well-defined interpretation of what 
the service ID means. Whereas, the signaling itself is very clear on 
what the behavior of the system is supposed to be. I rewrote this bit; 
hopefully it is clearer now.

> 
> 6.2.  Perils of Explicit Identifiers
> 
>   Clearly, if the signaling message itself contains enough information
>   to identify the service, inclusion of an extra field to say the same
>   thing is going to be redundant.  Redundancy by itself is not a big
>   deal.  However, redundancy can lead to other,more significant
>   problems.
> 
> Spencer (nit): s/other,more/other, more/

fixed

> 
> 6.2.1.  Fraud
> 
>   First and foremost, it can lead to fraud.  If a provider uses the
> 
> Spencer (nit): s/it/the user of a service identifier/

'it' is actually referring to 'explicit service identifiers'.

> 
>   service identifier for billing and accounting purposes, or for
>   authorization purposes, it opens an avenue for attack.  The user can
>   construct the signaling message so that its actual effect (which is
>   the service the user will receive), is what the user desires, but the
>   service identity (which is what is used for billing and
>   authorization) doesn't match, and indicates a cheaper service, or one
> 
> Spencer: this text doesn't seem quite right - "the signaling and service 
> identity (which is what is used for billing and authorization) don't 
> match, and the service identifier indicates ..."?

I reworded this. Now reads:

<t>
Explicit service identifiers can lead to fraud. If a provider uses the
service identifier for billing and accounting purposes, or for
authorization purposes, it opens an avenue for attack. The user can
construct the signaling message so that its actual effect (which is
the service the user will receive), is what the user desires, but the
user places a service identifier into the request (which is what is
used for billing and authorization) that identifies a cheaper service,
or one that the user is authorized to receive. In such a case, the
user will be billed for something they did not receive.
</t>

<t>
If, however, the domain administrator derived the service identifier
from the signaling itself, the user
cannot lie. If they did lie, they wouldn't get the desired service.
</t>

> 
>   that the user is authorized to receive.  If, however, the service
>   identity used by the domain admistrator is derived from the signaling
>   itself, the user cannot lie.  If they did lie, they wouldn't get the
>   desired service.
> 
>   Consider the example of IPTV vs. multimedia conferencing.  If
>   multimedia conferencing is cheaper, the user could send an INVITE for
>   an IPTV session, but include a service identifier which indicates
>   multimedia conferencing.  They get the service associated with IPTV,
> 
> Spencer (nit): s/They get/The user gets/

fixed

> 
>   but at the cost of multimedia conferencing.
> 
>   This same principle shows up in other places.  For example, in the
>   identification of an emergency services call [6].  It is desirable to
>   give emergency services calls special treatment, such as being free,
>   authorized even when the user cannot otherwise make calls, and to
>   give them priority.  If emergency calls where indicated through
>   something other than the target of the call being an emergency
>   services URN [7], it would open an avenue for fraud.  The user could
>   place any desired URI in the request-URI, and indicate that the call
>   is an emergency services call.  This could would then get special
>   treatment, but of course get routed to the target URI.  The only way
>   to prevent this fraud is to consider an emergency call as any call
>   whose target is an emergency services URN.  Thus, the service
>   identification here is based on the target of the request.  When the
>   target is an emergency services URN, the request can get special
>   treatment.  The user cannot lie, since there is no way to separately
>   indicate this is an emergency call, besides targeting it to an
>   emergency URN.
> 
> Spencer: somewhere around here, you might add something like "if the 
> network operator must verify the service identity verification using 
> signaling, the service identifier provides no additional value beyond 
> the signaling."

This is now explicitly talked about in a section that discusses redundancy.

> 
> 6.2.2.  Systematic Interoperability Failures
> 
>   How can inclusion of an explicit service identifier cause loss of
>   interoperability?  When such an identifier is used to drive
>   functionality - such as dispatch on the phones, in the network, or
>   QoS authorization, it means that the wrong thing can happen when this
>   field is not set properly.  Consider a user in domain 1, calling a
>   user in domain 2.  Domain 1 provides the user with a service they
>   call "voice chat", which utilizes voice and IM for real time
>   conversation, driven off of a buddy list application on a PC.  Domain
>   2 provides their users with a service they call, "text telephony",
>   which is a voice service on a wireless device that also allows the
>   user to send text messages.  Consider the case where domain 1 and
>   domain 2 both have their user agents insert a service identifiers
>   into the request, and then use that to derive QoS authorization,
>   accounting, and invocation of applications in the network and in the
>   device.  The user in domain 1 calls the user in domain 2, and inserts
>   the identifier "Voice Chat" into the INVITE.  When this arrives at
>   the proxy in domain 2, the service is unknown.  Consequently, the
>   request does not get the proper QoS treatment.  When it gets
>   delivered to the User Agent of the user in domain 2, the user agent
>   does not see a service it understands, and so consequently, does not
> 
> Spencer: this is probably clear to everyone but me ... but I'm confused 
> between "does not get the proper QoS treatment" and "does not see a 
> service it understands" - are you talking about two different failures 
> here?

No, this is mixing the two. I removed the call failure part and just 
talked about qos here.


  If your point is "I told you to do GROMMET service and you don't
> know what that is, so you fail the call, but if you had ignored what I 
> told you and looked at the signaling, the call would have succeeded", 
> maybe dropping the proxy/QoS treatment side trip would be clearer.

I kept that sidetrip since it illustrates the subtle failures that can 
happen.

> 
>   know to dispatch the request to the right application software.
>   Thus, this call has completely failed, even when it could have
>   succeeded.  This illustrates the following key point:
> 
> ...
> 
>      Usage of explicit service identifiers in the request will result
>      in inconsistencies with results of any SIP negotiation that might
> 
> Spencer: s/with/between the service identifier and the/

fixed

> 
>      otherwise be applied in the session.
> 
>   Of course, there are cases where negotiating to a common baseline is
>   not what is desired.  SIP provides tools (such as Require), to force
>   the call to fail unless the desired capabilities are supported.
>   However, this is not recommended as a general rule [4].
> 
> Spencer: again, totally presentation-layer, but this paragraph isn't 
> particularly helpful to me - the section would be clearer if the 
> paragraph was deleted completely.

deleted

> 
> 6.2.3.  Stifling of Service Innovation
> 
>   The probability that any two pair of service providers end up with
>   the same set of services, and give them the same names, becomes
>   decreasingly small as the number of providers grow.  Indeed, it would
>   almost certainly require a centralized authority to identify what the
>   services are, how they work, and what they are named.  This, in turn,
>   leads to a requirement for complete homogeneity in order to
>   facilitate interconnection.  Two providers cannot usefully
>   interconnect unless they agree on the set of services they are
>   offering to their customers, and each do the same thing.  This is, in
> 
> Spencer: well, if I've followed you to this point, there's no 
> requirement for each provider to do the same thing, right? because 
> there's no connection between what you say you're asking for and what 
> you ask for in the signaling, soooo... If I tell you "I'm invoking the 
> GROMMET service" and you say "cool, dude, I'll ignore that completely 
> and read the signaling", everything works fine, right? You just have to 
> agree you won't choke when I say "I'm invoking the GROMMET service". :-)

the problem is when a domain is dependent on the existence of a service 
identifier it knows about, to do various side effects that are needed to 
make it work. I added a sentence making that clear.


> 
>   a very real sense, anathema to the entire notion of SIP, which is
>   built on the idea that heterogeneous domains can interconnect and
>   still get interoperability:
> 
>      Metcalfe's law, when combined with explicit service identifiers,
>      will stifle the ability of providers to develop new SIP services,
>      since they have no hope of interconnecting them with anyone else.
> 
> Spencer: slightly overstated, perhaps? "since they cannot interconnect 
> new SIP services without the agreement of other providers", and maybe 
> even "other, competing providers"?

i deleted this entire paragraph anyway

> 
>   Normally, this service would be backwards compatible with a regular
>   audio-video endpoint, which would just reject the third media stream.
>   However, because a large network has been deployed that is expecting
>   to see the token, "multimedia conversation" and its associated audio+
>   video service, it is nearly impossible for the new provider to roll
>   out this new service.  If they did, it would fail completely, or
>   partially fail, when their users call users in other provider
>   domains.
> 
> Spencer: I'm thinking this document is missing something I've heard a 
> lot of discussion about - the idea that there are various "levels" of 
> service, and we don't have any clue how to mix-and-match service 
> identifiers. If you have an audio+video+avatar service and a 
> push-to-talk service, how do you offer an 
> audio+video+avatar+push-to-talk service? We know how to do this based on 
> signaling (conceptually, when PTT signaling actually reflects what 
> happens in PTT), but how do we tell the other end what to do using 
> service identifiers?

I think thats implied in the whole discussion about sip's ability to 
negotiate fine grained capabilities for a session.

> 
> Spencer: you may not want to go into too much more detail about a 
> fundamentally bad idea, but there is also a problem with the service 
> identifier namespace - flat? hierarchical?
> 
> If 3GPP has a "push-to-talk" and Nintendo has a "push-to-talk" 
> capability for gamers that doesn't work the same way, what happens then?
> 
> If I have "3GPP/push-to-talk" and you have "Nintendo/push-to-talk" and 
> they DO work the same way, can we communicate?

This is easily solved using traditional namespace hierarchies, so I 
don't think it needs discussion.

> 
> 8.  Security Considerations
> 
>   Oftentimes, the service associated with a request is utilized for
>   purposes such as authorization, accounting, and billing.  When
>   service identification is not done properly, the possibility of
> 
> Spencer: perhaps clearer if "possibility of unauthorized service use and"?

fixed

> 
>   network fraud is introduced.  It is for this reason, discussed
>   extensively in Section 6.2.1, that the usage of explicit service
>   identifiers inserted by a UA is NOT RECOMMENDED.
> 
> Spencer: NOT RECOMMENDED here does not look like 2119 text to me - it 
> looks like caps-for-emphasis.

changed to lower caps

> 
> 9.  IANA Considerations
> 
>   There are no IANA considerations associated with this specification.
> 
> Spencer: "IANA is requested to drop silently all requests for a service 
> identifier registry" :-)

lol. Sadly, those requests are in fact coming in. They are using the 
media feature tags.

Thanks,
Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com
_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP