Draft:  draft-ietf-sipping-config-framework-08.txt
Reviewer: Dolly, Martin C, ALABS [mdolly@att.com]
Review Date:  Wednesday 6/7/2006 3:11 PM
Review Deadline: 5/24/2006
Status: post WGLC | WGLC | Interim review | Initial review | Expert Review 

Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. 

Review:
Section 3 and then Global: replace roaming with nomadic. The definition
still holds

Section 5.2, list item 4, should refer to step 6, not step 7, above.
Change "perminent" to "permanent"

Need to define "instance id". Used in Section 6 for the first time.

Section 7, last paragraph: Change MAY to MUST or SHOULD.
These profile MIME types specified in the Accept header
   along with the profile types specified in the Event header parameter
   "profile-type" MAY be used to specify which profiles get delivered
   either directly or indirectly in the NOTIFY requests.

Section 7, Modify last sentence to reflect that it will be addressed in
the profile data sets.
The data provided in the four 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.

Section 7, Change the SHOULDs to MUSTs
The "network-user" parameter SHOULD be set when subscribing for
   device and local network profiles if the user's AOR is known.  When
   the profile-type is "device" or "local-network", the SUBSCRIBE URI
   addresses the device or local network profile delivery server.  As
   the SUBSCRIBE request URI for the "device" or "local-network" profile
   must contain the device identity, it cannot contain the user profile
   identifier.  The "network-user" parameter is used to indicate the
   user profile resource identifier.  The SUBSCRIBE server SHOULD
   authenticate the subscriber to verify the resource identifier in the
   "network-user" parameter if the profile provided is specific to the
   user (e.g. granting policies or privileges beyond those of an
   anonymous user).  If the value of the "profile-type" parameter is not
   "device" or "local-network", the "network-user" parameter has no
   defined meaning and is ignored.  If the "network-user" parameter is
   provided in the SUBSCRIBE request, it MUST be present in the NOTIFY

Section 7, Change the SHOULDs to MUSTs in the next paragraph starting
with "The entity that is subscribing..."

Section 7,  toward end of page 13, Change "anonymous user" to "default
user"

Section 7, define indicator that the profile has been successfully
applied by the UA, and not just acknowledge the receipt.

Section 7.6, 3rd para., I do not think it should be recommended to
accept a subscription from an unknown user or device. One needs to be
(should be) a valid subscriber before the activation process occurs.

Expand UUID.

Section 8.4, 1st para, change "server SHOULD secure" to "server MUST
secure"