Subject: RE: [Sipping] draft-ietf-sipping-config-framework-10

From: "Elwell, John" <[email-masked]>
Date: Thu, 08 Feb 2007 08:17:24 +0000

Sumanth,

Thanks for your explanations. I am sorry my comments were not detailed
enough, but that was due to lack of time. In the next version, in addition
to providing clarification in line with some of my detailed comments, I hope
there will be some up-front explanation of simpler scenarios (even start
with simpler scenarios and then explain some of the additional capabilities
aimed at more complex scenarios). Perhaps that is already there, but it
didn't come over at first read. I look forward to your next revision, which
I will try to review in more detail and in the light of the explanations you
have given.

John

> -----Original Message-----
> From: Sumanth Channabasappa [mailto:[email-masked]] 
> Sent: 07 February 2007 17:35
> To: Elwell, John
> Cc: [email-masked]
> Subject: RE: [Sipping] draft-ietf-sipping-config-framework-10
> 
> John,
> 
> The posted version (-v10) was a first draft from the design 
> team and was
> meant to obtain feedback from the WG, so your email helps - 
> thanks (the
> deadline was mostly a request to help us address comments in a timely
> manner)! I have attempted to address a few of comments in 
> this email and
> will be requesting other members of the design team to 
> address the rest
> (and to keep me honest)!
> 
> Specific responses can be found inline (marked with [S])...
> 
> 
> In general I find it hard to read and understand, and I can't help
> feeling that this is an over-complex solution. This is due in part to
> the fact that we have three different profile types, and it 
> is not clear
> to me that this is needed in a lot of deployments. The use cases you
> give are certainly not all that compelling, and I can't help feeling
> that a much simpler solution would serve a large proportion 
> of cases and
> would be a lot more attractive to implement.
> [S] The Use Cases present a couple of complex deployments 
> with the hope
> that other Use Cases can easily be envisioned, especially simple ones.
> They are compelling based on the feedback obtained from the 
> design team
> (IMHO) - and hopefully helpful to understanding the general 
> framework -
> but we are open to suggestions and any simplification that 
> can also take
> care of the presented Use Cases (and are actively pursuing 
> that). See in
> particular open items listed in sec 11, items 2 and 4. I 
> would strongly
> recommend that you provide more details to the design team in this
> regard.
> 
> Now, the profile types are indicative of profile data categorization
> (and the profile data sources). The intention is not to force the
> retrieval of all the profile types, but to provide a framework that
> allows for the necessary profiles to be retrieved (e.g., a client may
> not be provided with a local-network profile). The I-D also 
> allows folks
> to define new profile types.
> 
> 
> 
> Section 2, definition of client. This definition seems to 
> include things
> like gateways and media servers. Is this the intention? The concept of
> user may differ for gateways, for example.
> [S] Yes, this was the intention. We may want to explain this clearly.
> 
> 
> Section 3, definition of device.  I see no point in using two terms
> (device and client) for the same thing. I prefer "device", because SIP
> has its own use for "client".
> [S] The usage of 'client' (specific usage in the I-D) was to 
> allow for a
> wider variety of entities (e.g., software-based entities) to be
> represented. I will check with the design team on this.
>  
> 
> Section 4.1. I don't think this example is compelling. Why 
> would a data
> service provider provide a SIP-based PDS when it is not a SIP service
> provider?
> [S] There were a few Use Cases presented for this. For example, if an
> enterprise network allows users to use SIP based devices (such as
> dual-mode mobile devices) within their network, but do not provide SIP
> services themselves, they may still want to provide local network
> configuration information (e.g., STUN/TURN addresses and 
> such) to enable
> such services within their perimeter. The alternative is WiFi hotspots
> or even home networks that have special configuration for SIP based
> communication to be realized. This is not always the case, 
> however, and
> a deployment can use it as need be (this may have to be 
> stated upfront,
> will check on that).
> 
> 
> Section 4.1, item B, "The Client proceeds to request the 
> 'local-network'
> Profile Type. The PDS in the local network responds, allowing 
> the Client
> to retrieve the local-network profile". We should describe 
> here how the
> client address the request to the PDS.
> [S] This is detailed in the later sections when we describe 
> each step in
> further detail. We did not want to duplicate the information.
> 
> 
> Section 4.1, item C, "based on the subscription status". What
> subscription status is this? Why would a device (as opposed to a user)
> have to 'subscribe' prior to being able to be used? How does 
> the device
> identify itself to the PDS so that its 'subscription' can be verified?
> [S] Perhaps we need to explain that more clearly or eliminate nuances.
> To answer your specific question, there are architectures where the
> 'device' and the 'user' are two separate entities and have separate
> identities (and possibly credentials). Examples I can think of are GSM
> devices which have different identifiers for the handset and the User
> (identity tied to the SIM) or PacketCable clients where the 
> devices are
> identified independent of the user. In simple cases, this is true of
> certain enterprise networks where IP phones have their own 
> identity (and
> credentials) and can cater to any user who can 'login'. Thus, the
> 'device' identifies itself to get IP access and provide basic 
> services,
> but anyone who wants them to act on their behalf (i.e., behave as if a
> IP Phone was their own) can do so. 
> 
> 
> Section 4.1, item D, "The Client retrieves the User profile (this can
> contain information such as service profiles to be 
> retrieved". What is a
> service profile? I thought we just had network, device and user
> profiles.
> [S] This may need to be clarified. There is a separate I-D for the
> 'application' profile type (defined outside of the framework) 
> and should
> probably not be mentioned here. We will look at rewording this.
> 
> 
> Section 4.1, item D, "The Client then starts providing services." What
> is meant by "providing services". Normally a server provides services,
> not the client. Does it just mean that the device commences normal
> operation (e.g., registering with a SIP server)?
> [S] This may need some clean up. The objective was to say that client
> can start normal operation. 
> 
> 
> Section 4.2 "SIP Service Provider A provides the local network
> connectivity, 'local-network' and 'device' profiles for the 
> Client.  The
> Service Provider also provides 'user' profiles for existing
> subscribers".  Why is this necessarily a SIP service provider? I would
> imagine that the device would perform SIP registration with Service
> Provider B (on a per user basis) and would not register with Service
> Provider A. So to call it a SIP Service Provider is misleading. OK, in
> this case if there are some users who happen to be supported by this
> provider, then I guess it is a SIP service provider, but if all users
> are supported by other service providers then it is not.
> [S] This is just the assumption in the Use Case and is not 
> reflective or
> all scenarios. 
> 
> 
> Section 5.1 "The first step to obtaining a profile is PDS Discovery.
> This is accomplished by creating a profile subscription using 
> the Event
> Package described in Section 6, and preparing for Profile Enrollment."
> This is circular - you have to discover the PDS before you 
> can submit a
> subscription request to it.
> [S] The design team is attempting to clean this up. Discovery 
> of the PDS
> is not an act in itself. It involves creating a subscription that is
> aimed at a PDS (i.e., profile source).
> 
> 
> Section 5.1, second paragraph "Client identifier". I think we need to
> say something here about what this is and how a PDS would use 
> it. Taking
> a MAC address as an example, is this likely to be meaningful to the
> Device Profile PDS?
> [S] This is explained in detail in 5.1.2.1, no?
> 
> 
> Again, your detailed comments are much appreciated. I would 
> also request
> you to participate in the design team discussions to add value to this
> effort.
> 
> Thanks!
> - S
> 
> 

_______________________________________________
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