Subject: [Sipping] Initial review of draft-ietf-sipping-service-identification-00.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 02 Oct 2007 14:27:39 +0300

Folks,

we would like to perform an initial review of the following document to 
ensure that we are on the right path:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identification-00.txt

We will also have some RAI and APPs folks external to SIPPING have a 
look at it with the same purpose.

So, if you would like to volunteer to perform an initial review of this 
document, please let the chairs know.

Thanks,

Gonzalo
SIPPING co-chair

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Mahesh <[email-masked]>
Date: Tue, 02 Oct 2007 19:12:23 +0530

hello Gonzalo,
I've been waiting for quite sometime for review of this draft.:-)

I would like to volunteer to do a intial review of this draft.
I do not know of the formal procedure to declare myself as volunteer .
 So i shall just go ahead and post my initial review comment below.
(if there is anything specific to be done to inform the Chairs pls let me
know)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~``

Starting with, let me discuss w.r.t the following definition from the draft
"Service  identification is the process of determining and/or signaling the
   specific use case that is driving the signaling being generated by a
   user agent."

Here, if the signaling is really able to signal the Use-Case that is driving
the Signaling then it would be Application Identification rather than just
just Communication Service Identification because the Use-Case
(defining theUser Experience) is modelled by the Application and not the
Communication Service.
But the draft title is "Identification of Communication Services".
Signaling/determining  a Communication Service does not neccessarily
amount to determining/signalling the Use Case which is driving the
signalling.

Basically, it is unclear as to what is meant by "Service Identification" in
this draft.

So i tried to seek answer in Section 3 which tries to define "Service". 
Here,
extract from RFC 4479(Presence Data Model) is referred to define a Service.
" Each presentity has access to a number of services.  Each of these
represents a point of reachability for communications that can be   used to
interact with the user."

There are two ways of interpreting this
    i1)"Point of reachability for Communications " can be WhiteBoard,
        Chess Game,Chatt Application  which are all different instances of
        Interaction with the User.
    i2)"Point of reachability for Communications" can be Messaging
        Service, CS Telephony, PS Telephony which can be used by
        Applications such as Game,Instant Messenger,WhiteBoard etc to enable
        interaction with the User.

It is more meaningful  if it were (i1), so that the Presentity Info conveys
exactly the kind of Use-Case/Interaction that a User can engage in with
another User.Which Communication Service would be used to achive the
Interaction/Use-Case may be irrelevant to the User.

Also, later on in Section 3 of the draft i find the following:
"Essentially, the service is the user-visible use case that is driving
   the behavior of the user-agents and servers in the SIP network."

I'm still not able to understand "Service" and hence "Service 
Identification"
from this draft because if "Service" is looked as as a user-visible
use case then there is ambiguity  in this draft as follows
    - The Title of  the draft is "Identification of Communication Service",
    - however the term "Service" is being used to refer to the User Visible
      Usecase by statement ==> "Service Identification is the process of
      determining and/or signaling the  specific use-case".
    - User Visible Use Case cannot be synonymous to Communication Service,
       in other words a Communication service may not be able to completely
       indicate/describe the User experience. For Example: by inidcating
       a Messaging Communication Service i cannot know if User is wants
       Gaming or Chatting.

regards
Mahesh

----- Original Message ----- 
From: "Gonzalo Camarillo" <[email-masked]>
To: "sipping" <[email-masked]>
Cc: "Mary Barnes" <[email-masked]>
Sent: Tuesday, October 02, 2007 4:57 PM
Subject: [Sipping] Initial review 
ofdraft-ietf-sipping-service-identification-00.txt

> We will also have some RAI and APPs folks external to SIPPING have a look 
> at it with the same purpose.
>

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 2 Oct 2007 11:37:29 -0500

Hi Mahesh,

This is fine.  I'll pull your comments into a .txt file and cache on the
SIPPING WG webpage on softarmor:
https://softarmor.com/sipping/process/wg-review/reviews/

FYI, there's a guidelines file on that directory as well: 
https://softarmor.com/sipping/process/wg-review/sipping-review-guideline
s.html

There is a template, but it's no big deal for us to pull your
information into that format:
https://softarmor.com/sipping/process/wg-review/review-template.txt

Thanks,
Mary. 

-----Original Message-----
From: Mahesh [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2007 8:42 AM
To: Gonzalo Camarillo; sipping
Cc: Barnes, Mary (RICH2:AR00); [email-masked]; Vinod Cherian
Joseph
Subject: Re: [Sipping] Initial review
ofdraft-ietf-sipping-service-identification-00.txt

hello Gonzalo,

(if there is anything specific to be done to inform the Chairs pls let
me

Starting with, let me discuss w.r.t the following definition from the
draft "Service  identification is the process of determining and/or
signaling the
   specific use case that is driving the signaling being generated by a
   user agent."

Here, if the signaling is really able to signal the Use-Case that is
driving the Signaling then it would be Application Identification rather
than just just Communication Service Identification because the Use-Case
(defining theUser Experience) is modelled by the Application and not the
Communication Service.
But the draft title is "Identification of Communication Services".
Signaling/determining  a Communication Service does not neccessarily
amount to determining/signalling the Use Case which is driving the
signalling.

Basically, it is unclear as to what is meant by "Service Identification"
in this draft.

So i tried to seek answer in Section 3 which tries to define "Service". 
Here,
extract from RFC 4479(Presence Data Model) is referred to define a
Service.
" Each presentity has access to a number of services.  Each of these
represents a point of reachability for communications that can be   used
to
interact with the user."

There are two ways of interpreting this
    i1)"Point of reachability for Communications " can be WhiteBoard,
        Chess Game,Chatt Application  which are all different instances
of
        Interaction with the User.
    i2)"Point of reachability for Communications" can be Messaging
        Service, CS Telephony, PS Telephony which can be used by
        Applications such as Game,Instant Messenger,WhiteBoard etc to
enable
        interaction with the User.

It is more meaningful  if it were (i1), so that the Presentity Info
conveys exactly the kind of Use-Case/Interaction that a User can engage
in with another User.Which Communication Service would be used to achive
the Interaction/Use-Case may be irrelevant to the User.

I'm still not able to understand "Service" and hence "Service
Identification"
from this draft because if "Service" is looked as as a user-visible use
case then there is ambiguity  in this draft as follows
    - The Title of  the draft is "Identification of Communication
Service",
    - however the term "Service" is being used to refer to the User
Visible
      Usecase by statement ==> "Service Identification is the process of
      determining and/or signaling the  specific use-case".
    - User Visible Use Case cannot be synonymous to Communication
Service,
       in other words a Communication service may not be able to
completely
       indicate/describe the User experience. For Example: by inidcating
       a Messaging Communication Service i cannot know if User is wants
       Gaming or Chatting.

regards
Mahesh

----- Original Message ----- 
From: "Gonzalo Camarillo" <[email-masked]>
To: "sipping" <[email-masked]>
Cc: "Mary Barnes" <[email-masked]>
Sent: Tuesday, October 02, 2007 4:57 PM
Subject: [Sipping] Initial review 

> ensure that we are on the right path:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identific
ation-00.txt
> We will also have some RAI and APPs folks external to SIPPING have a
look

---

From: [email-masked]
Date: Wed, 10 Oct 2007 23:27:42 -0400

From: Gonzalo Camarillo <[email-masked]>

I think this is a fine document, and gives a clear exposition of what
we have seen as both the "arguments for service identification" and
"arguments against service identification", and what results when the
valid arguments are sorted out from the illusory ones.

However, I think that there's a point of view that needs to be looked
at, one which is closer to how telco networks are now built:

"A service is what is provided by an application server."

Architecturally, it seems that telco networks tend to be built where
each endpoint delegates most of its functionality to a number of
application servers.  When originating a call, the endpoint has a way
of choosing which AS will operate on its behalf.  At the terminating
end, the call is routed to the AS which handles the identified
service, which then invokes the proper functionality of the
terminating endpoint.  In addition, the ASs on both ends function
essentially as B2BUAs, not proxies, that is, they are largely
non-transparent to signaling from the endpoints.

In order to make this work, telcos have agreed on a small number of
fairly narrowly standardized services.  This allows the demultiplexing
of the incoming call stream into the ASs to be done in a simple
manner, and also reduces the work that ASs do to negotiate call setup.

In moving to the SIP philosophy as described in this I-D, telcos are
going to have to change their networks.  The crucial change is the
process of demultiplexing incoming calls, which will now have to be
done based on an overall, "intelligent" evaluation of the offered call
rather than a simple lookup of a service identifier.

How difficult will this change be to achieve?

And is this a proper topic to discuss in the I-D?

Dale

---

From: Eric Burger <[email-masked]>
Date: Mon, 15 Oct 2007 07:45:18 -0500

I would offer two observations.

First, I would to explore the concept "the endpoint has a way of choosing
which AS will operate on its behalf."  If what you mean is the endpoint
routes a request to a specific AS by addressing it with the AS' AOR, then I
fully agree.  This is the mechanism by which, for example, conferencing,
messaging, IPTV, call center, etc., etc. works.

If what you mean is the endpoint pre-loads the target address of an
intermediary AS (B2BUA) in the process of addressing a further endpoint,
then I would like to think this through.  In particular, I would offer for
most networks, the endpoint has no clue what the address of a given AS is.
For example, if I am using a pre-paid service, how would I know the address
of my pre-paid AS?  What happens when that AS moves around?  If the network
wishes to "add value" by "transparently" adding a service, then the network
can make that determination at its ingress or egress proxies.  In the
pre-paid case, the network will most likely intercept my call at the ingress
proxy and invoke the pre-paid AS.  In fact, the Service Identification draft
explains why the network MUST NOT rely on the endpoint to indicate (address
the AS) this service: the endpoint will undoubtedly lie.

Second, I would offer the statement "telcos are going to have to change
their networks" is a non sequitur.  We are talking about networks that are
just being built.  There is nothing to change, unless we are talking about
he migration from SS7/PSTN to SIP/IP.  In the latter case, the network
operators are dramatically changing their networks, by definition.  In fact,
why are they changing their networks?  To reap the benefits of SIP.  Thus,
it would be counter intuitive for a service provider to spend all of this
money to reap the benefits of SIP and then to turn around and opt out from
the POSSIBILITY of reaping the benefits of SIP.

If for no other reason to inoculate themselves from a shareholder lawsuit, I
would offer we need to publish this draft to explain why we are not going to
ever standardize a service indicator header.

> And is this a proper topic to discuss in the I-D?

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: [email-masked]
Date: Mon, 15 Oct 2007 11:40:07 -0400

From: Eric Burger <[email-masked]>

   of my pre-paid AS?

I believe that what now happens is rather the reverse, the endpoint
choses a "service identification" out of a very small set, and depends
on the network to route the request to the AS which will be the
endpoint's agent for carrying out the communication.

   What happens when that AS moves around?

Roughly, I expect that every ingress proxy in the network is updated
to know the new address.

While it's true that the network is entirely new, what I meant was
"The telcos are going to have to change how they design and think
about networks.", which is a lot more difficult than just spending a
few billion dollars to assemble a new network that looks very much
like the old network.

As you say, this change in network design will be necessary to reap
the benefits of SIP (as opposed to being able to advertise that they
have a SIP network).

   If for no other reason to inoculate themselves from a shareholder
   lawsuit, I would offer we need to publish this draft to explain why
   we are not going to ever standardize a service indicator header.

I think such a draft is a good idea.  But I'm not sure that we've
explained the decision in a way that is understandable from the point
of view of people whose entire knowledge base is of a different
network architectural style.

Dale