Draft: draft-ietf-sipping-config-framework-09.txt Reviewer: Sumanth Channabasappa [sumanth@cablelabs.com] Review Date: Friday 10/27/2006 3:17 PM CST Review Deadline: 10/31/2006 Status: WGLC Summary: This draft is on the right track but has open issues and nits, described in the review. Note: ----- Since the comments were the result of collective feedback, I have included the originators of the comments. [Josh] refers to Josh Littlefield (joshl@cisco.com) and Nhut refers to Nhut Nguyen (nnguyen@sta.samsung.com). Comments: --------- #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)