Subject: [Sipping] WGLC: draft-ietf-sipping-config-framework-09.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 10 Oct 2006 09:25:41 +0300

Folks,

we would like to working group last call (WGLC) the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-09.txt

We would like to recruit a few volunteers to serve as dedicated
reviewers (in addition to Roni, Martin, and Chistian, who already
reviewed the draft).

If you are interested and willing to review this draft, please send an
email to the SIPPING chairs.

As always, anyone else that gets a chance to review should also send
their feedback to the authors and copy the SIPPING mailing list.

This WGLC will end on October 31st, 2006.

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: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 27 Oct 2006 14:16:55 -0600

Gonzalo, Dan,

As indicated before, here are the comments on:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-
09.txt

Since the comments were the result of collective feedback, I have
included the originators of the comments. [Josh] refers to Josh
Littlefield ([email-masked]) and Nhut refers to Nhut Nguyen
([email-masked]). 

regards
Sumanth (on behalf of the comment originators)

#1

Overview:
--------

+ 1.1 [Page 6; need clarification]

<<
"With SIP the users and devices already are assigned globally routable
addresses.  In addition the firewall and NAT problems are already
presumably solved in the environments in which SIP user agents are to be
used."

[Sumanth] Was the intention to state that in SIP networks, users and
devices are 'globally reachable'? Globally routable address implies
something different

+ 1.2 [Page 7; Josh] Diagram on page 8 might make more sense as a simple
flow diagram, as depicted below:

                +------------------+   +----------------------+
   +------+     |Residential Router|   |SP Prof. Delivery Srvr|
   |Device|     | DHCP         SIP |   |   HTTPS         SIP  |
   +------+     +------------------+   +----------------------+
      |            |            |            |            |
 (1A) |<===DHCP===>|            |            |            |
      |            |            |            |            |
      |            |            |            |            |
      |     SUBSCRIBE/NOTIFY    |            |            |
 (1B) |<=local-network profile=>|            |            |
      |            |            |            |            |
      |            |            |            |            |
 (2) [User enters SP hostname]
      |            |            |            |            |
      |            |            |            |            |
 (3)  |-----------SUBSCRIBE/TLS device profile----------->|
      |            |            |            |            |
      |            |            |            |            |
 (4)  |<-------NOTIFY (on existing TLS connection)--------|
      |            |            |            |            |
      |            |            |            |            |
 (5A) |-------HTTPS GET device profile------>|            |
      |            |            |            |            |
      |            |            |            |            |
 (5B)[User enters UserID/password]
      |            |            |            |            |
      |            |            |            |            |
 (6)  |<-----HTTPS resp w/dev. profile-------|            |
      |            |            |            |            |
      |            |            |            |            |
 (7)  |-----Re-SUBSCRIBE (configured device profile)----->|
      |            |            |            |            |
      |            |            |            |            |
      |            |            |            |            |

+ 1.3 [General, Nhut]
Overview should probably indicate something about authentication of
entities obtaining profiles

#2:
Section 5.1
-----------

+ 2.1 [Page 8; clarification requested]
<<
5.  The device receives the NOTIFY request with the device profile URI.
The device prompts the user for the user ID and password provided by the
service provider.  The device does an HTTPS GET to retrieve the device
profile (see Section 8.4 and Section 7.8).
 
The profile delivery server challenges for Digest authentication. The
device re-sends the HTTPS GET with Digest credentials using
the user ID and password entered by the user.
 
[Sumanth, Josh] The statement seems to indicate that the Device Profile
is obtained via 'User Credentials'. Does this imply that the possession
of valid User credentials on the Service Provider's network would allow
the User to obtain any Device Profile (or is the Device Profile specific
to that User)? Given this is a Use Case, the assumption that this is
feasible is probably valid, but should probably be clarified (esp. given
the subtleties).

+ 2.2 [Page 8; clarification requested]
<<
The device receives the device profile from the HTTPS response,
re-SUBSCRIBEs using the device profile URI provided in the
profile.  The device profile also may contain URIs for the
default user's user and other profile SUBSCRIBE request URIs for
the SIP event package defined in Section 7.  The device uses
these URIs to retrieve user and other profiles in a similar way
to the device profile.  After retrieving these profiles the
device is fully functional in the service provider's SIP service.

[Josh, Sumanth] This I-D mentions a 'Default User' for a device. The
current understanding is that a device can use this 'Default User' to
obtain User Profile information in the absence of any other User. Is
this understanding right? If so, should we say something upfront?

#3

Section 5.2
-----------

+ 3.1 [Sumanth] This section needs to indicate that for Certificate
Validation, the Certificate Signer information should be present. This
can be accomplished using a PKI or some out of band mechanism.

#4

Section 6
---------
 
+ 4.1 [last paragraph; error?]
<<
The  device instance id is used to form the user id part of the URI for
subscribing to the device and local network profiles.

[Josh] This seems to contradicts 7.13.3 (as per change 1 in the current
I-D)?

#5
Section 7.2
-----------

5.1 [Page 13]
<<
The "network-user" parameter MUST be set when subscribing for device
profiles if the user's AOR is known. 
 
[Josh] Do we really need the 'network-user' for the device profile? Can
this be a SHOULD?
[Sumanth] I concur, is there a justification for the MUST?

5.2 [Page 14]
[Josh]
+ discussion of "network-user" parameter is both contradictory and
repetitive.  It needs to be cleaned up.
 
First it says "The "network-user" parameter MUST be set when subscribing
for device profiles if the user's AOR is known."  Later, at the bottom
of the page, it says "When the profile-type is "device", the user agent
SHOULD set the "network-user" parameter to the "user" profile resource
identifier if it is known.".

The justification for the network-user parameter is also repeated in
this section.  At the start:

<<
The URIs will not contain the user profile identifier.  For this  reason
the "network-user" parameter is needed to indicate the user  profile
resource identifier associated with the "device" or URI.

and near the bottom:
<<
Since the From field and SUBSCRIBE request URI indicate the "device"
profile resource identifier, the "network-user" parameter is needed to
indicate the additional resource identifier for the user associated with
this device.

General comments (Josh):
------- --------
+ The I-D seems to provide more information than required in certain
cases, e.g. 
<<
The data provided in the three types of profiles may overlap.  As an
example, the codecs that a user prefers to use, the codecs that the
device supports (and the enterprise or device owner wishes to use),
the codecs that the local network can support (and the network
operator wishes to allow) all may overlap in how they are specified
in the three corresponding profiles.  This policy for merging the
constraints across the multiple profile types can only unambiguously
be defined in the context of the profile syntax and semantics.  This
is out of scope for this document and will be defined in a subsequent
document(s) that define the data profile format.

One could simplify this by saying that data overlap across profiles is
out of scope. Just a thought, not a strong recommendation.

+ General formatting issues.  Many sections seem to have gained odd
formatting (indentation) resulting from edits.  For example, pages 13
and 14.  Is this intentional? If so, vertical spacing should offset
these paragraphs above and below.

+ s/localdomain/local domain/ on page 14

+ Example for 7.12 shows TCP Via header in SUBSCRIBE and UDP Via header 
in NOTIFY.  Does that make sense?  (Maybe so with a proxy, but I'm not
sure.)

+ Update XCAP reference (now -12, Oct. 06, -11 is expired)

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Tuesday, October 10, 2006 12:26 AM
To: sipping
Cc: Martin Dolly; Even, Roni; Daniel Petrie;
[email-masked]; Mary Barnes; Amy Pendleton
Subject: [Sipping] WGLC: draft-ietf-sipping-config-framework-09.txt

Folks,

http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-
09.txt

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