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

From: "Elwell, John" <[email-masked]>
Date: Tue, 06 Feb 2007 11:52:58 +0000

Sumanth,

Sorry I missed your deadline by one day. Also I have not reviewed the entire
document, but only the initial sections.

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.

Secondly it seems to me that we haven't got the terminology consistent yet.
In particular, I see various uses of "service" and "subscription" (and
variations), which need to be straightened out.

Specific comments:

Section 1, last paragraph. We start talking about modifying profiles here,
without having used the term profile in the preceding paragraph on
provisioning.

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.

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".

Section 3.1 "Profile Notification Component (PNC), responsible for enrolling
Clients in Profile event subscriptions..." Are enrollment and subscription
two separate procedures or the same? If the same, use a single term, e.g.,
"...responsible for accepting profile event subscriptions from clients..."
However, we should only use the term "subscription" in the context of a SIP
subscription, otherwise it gets confusing.

Section 3.1, figure. I don't think it is helpful to introduce different
profile types in the figure annotations without having described them first.

Section 3.1, figure, "Provides 'Client'(e.g. allowed Users) & 'User'(such as
Services) profile" and "Provides 'Local Network' profile data (e.g. STUN
Server Address)" The definition of service provider is fairly general, but
these annotations in the figure seems to imply it is a provider of profiles.
I guess this is made clear in the text much further down, but it is
confusing to see it in the figure without it already having been explained.

Section 3.1 "The observations above show a need for a clear distinction
between different Profile Types".  I think what it shows is the need for a
device to obtain configuration information from different sources. We can
choose to call a set of configuration information from a particular source a
profile. The device needs therefore to obtain multiple profiles.

Section 3.2, descriptions of Profile Discovery etc. These sound like
definitions, but we already have definitions of most of these terms in the
terminology section. So if the formal definition is in the terminology
section, here we should word them in a way that does not suggest they are
formal definitions.

Section 3.2 "Profile Enrollment:  The process by which a Client makes itself
known to a PDS.  While enrolling, the Client provides identity information
and requested Profile Type(s) for profile retrieval."  Again it is not clear
to me why we need to separate enrollment and subscription.

Section 3.2 "SUBSCRIBE session". What is a "SUBSCRIBE session"? Can't we
just use "subscription" or "SUBSCRIBE-initiated dialog"? In SIP, the word
"session" has a different meaning.

Section 3.3. In contrast to 3.2 we have some definitions that are not
present in the Terminology section.

Section 3.3 "User Profile:  Contains configuration data related to the
specific User, as required to reflect that User's preferences and the
particular services subscribed to."  I am not sure about the concept of
subscription here (in SIP, subscription has a particular meaning). Can't we
just replace "and the particular services subscribed to" by "and
entitlements".

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?

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.

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?

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.

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)?

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.

Section 4.2, figure "User A attempts services". I think it is attempting
subscription to the event package - that is all.

Section 4.2, item C, "The Client initializes the User interface for
services". What services?

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.

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?

Section 5.1.1 "the user part of the "From" field MUST be the Identifier that
the Client will use to request the 'device' Profile Type". Why is this
needed if we are only requesting network profile? A network PDS is unlikely
to have any knowledge of particular devices.

Section 5.1.1 "a user AOR, if known to the Client MUST be provided in the
"network-user" event header parameter". Again, why is this needed if we are
only requesting the network profile?

Section 5.1.1 "the uniqueness of the From field provides an important
capability" As far as the network is concerned, isn't the IP address a
sufficient distinction between devices?

John

> -----Original Message-----
> From: Sumanth Channabasappa [mailto:[email-masked]] 
> Sent: 30 January 2007 20:15
> To: sipping
> Subject: RE: [Sipping] draft-ietf-sipping-config-framework-10
> 
> Folks,
> 
> As indicated earlier, -v10 was a draft update and we have received
> limited comments thus far (thanks to those who provided comments). If
> there are additional comments that participants want to 
> share, it would
> be beneficial to receive them by Feb 5, 2007 to address them 
> in a timely
> manner. If you have not reviewed -v10 as yet, this email is a 
> request to
> please do so (as a note, please check the open items for things not
> completely addressed in this rev).
> 
> If you wish to participate in offline discussions, please 
> send and email
> to the co-chairs, the author or myself.
> 
> Thanks!
> - S
> 
> 
> 
> -----Original Message-----
> From: Sumanth Channabasappa 
> Sent: Wednesday, January 24, 2007 1:55 PM
> To: sipping
> Subject: [Sipping] draft-ietf-sipping-config-framework-10
> 
> Folks,
> 
> Now that v10 is available online
> (http://www.ietf.org/internet-drafts/draft-ietf-sipping-config
> -framework
> -10.txt), here is a brief summary of the changes in this version
> (reproduced in part from section 12.1).
> 
>    Changes incorporated by the author:
>    o  Incorporated numerous edits and corrections from 
> CableLabs review
>    o  Used better ascii art picture of overview from Josh Littlefield
>    o  Fixed the normative text for network-user so that it is now
>       consistant: MAY provide for device profile, MUST provide for
>       local-network profile
> 
>    Changes incorporated by the editor:
>    o  Restructured document based on a) Keith's recommendations in
>       the email dated 11/09/2006 and responses (Peter, 
> Sumanth, Josh) b)
>       subsequent discussions by the ad-hoc group consisting of the
>       editor, the author, expert contributors (Peter Blatherwick, Josh
>       Littlefield, Alvin Jiang, Jason Fischl, Martin Dolly, Cullen
>       Jennings) and the co-chairs 
>    o  Modified the contents of various sections as part of the
> restructuring 
>       efforts (notably: Overview, Introduction, Framework 
> Requirements &
> 
>       Security)
>    o  Revised Use cases and added detailed examples
> 
> This (-v10) is preliminary update and we plan to address the 
> open items
> (listed in section 11; for example, the security section could use
> expert reviews) in the upcoming weeks. This is being 
> presented to obtain
> feedback from the WG. Additionally, if folks wish to participate in
> offline discussions or sign up as expert reviewers please let myself,
> the author or the co-chairs know. 
> 
> Comments and feedback will be appreciated (thanks to Cullen 
> and Henning
> for early feedback on the mailing list).
> 
> 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
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 7 Feb 2007 10:35:28 -0700

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