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

From: Dan Petrie <[email-masked]>
Date: Sun, 5 Nov 2006 17:21:22 -0800 (PST)

Sumanth, Josh and Nhut:
Thank you very much.  You have made some very constructive comments
that I have done my best to resolve and incorporate in the draft (post
09).  See comments inline.

Cheers,
Dan

> 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
Yes, globally routable is the wrong term here.  The point was that SIP
already provides a mechanism to address the route messaging to the
users and end points needing configuration.

> 
>  
> 
> + 1.2 [Page 7; Josh] Diagram on page 8 might make more sense as a
simple
> flow diagram, as depicted below:
Thank you this is much clearer.  An ASCII artist I am not.
> 
>                 +------------------+   +----------------------+
>    +------+     |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
Added.

> 
> 
> 
> #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).
Good point.  I have added text.
>  
> + 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?
Yes, I got a number of comments on defining the data content which is
mostly out of scope of this document.  I hope that I have resolved this
by adding a paragraph in the data model section that makes some
recommendations on the data contents to be defined in another document.
>  
>  
> 
> #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.
Added.
> 
>  
> #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)?
Yes.  Thank you, I missed that in the last set of edits.
>  
>  
> 
> #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?
Actually, this should be a MAY for the device profile.  network-user in
the device profile subscription is an indication of an a request by the
user agent to make the given user the default user for the device.  It
is a MUST for the local-network
profile.

> 
> 
> 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.".
Thanks.  I will make these consistant: MAY for device profile, MUST for
local-network profile.

> 
> 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.
Deleted.
>>>
>  
>  
> 
> 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.
The discussion of data overlap and merging is in here mainly as the
framework intensionally is designed to allow it.  This paragraph is
here to resolve issues that someone else brought up on the discussion
of overlap for this document.  However the
solution to resolving overlap is out of scope for this document.
It is something that we discuss and solve in the profile-data-sets
draft.
> 
> 
> + 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.
Yes, the extra indentation is for rational for statements in the  prior
paragraph, typically normative statements.  Thanks for pointing our the
vertical spacing issues.
> 
>  
> + s/localdomain/local domain/ on page 14
done
> 
> 
> + 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.)
Good catch.  They are both TCP now.
> 
>  
> + Update XCAP reference (now -12, Oct. 06, -11 is expired)
Done
> 
> 
> 
>  
> 
> -----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,
> 
> 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

SIPez LLC  
SIP VoIP, IM and Presence Consulting  
http:/www.sipez.com  
tel: +1 (617) 273-4000

_______________________________________________
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