Subject: [Sipping] Review Comments on: draft-ietf-sipping-config-framework-08.txt

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Wed, 7 Jun 2006 15:11:15 -0500

Hello,
 
Below are my review Comments on:
draft-ietf-sipping-config-framework-08.txt.

Cheers,

Martin

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"

_______________________________________________
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: Dan Petrie <[email-masked]>
Date: Tue, 13 Jun 2006 20:53:07 -0700 (PDT)

Hi Martin:
Thank you for your comments.  I am in the process of rolling
your comments in.  There were a few of your comments that I
had some questions and issues.  My comments are inline:

Cheers,
Dan

> draft-ietf-sipping-config-framework-08.txt.

<snip>

>    provided in the SUBSCRIBE request, it MUST be present in the
I am not sure I agree or understand why these should be MUSTs.
I can image some isolated cases where you may not want user
agents to provide the network-user parameter or where you 
might not want to authenticate.  These would be unusual cases,
but in safe sandboxes it might be acceptable.

> with "The entity that is subscribing..."
This paragraph does not contain normative text.  It is an
explaination of the normative stance in the prior paragraph.

> applied by the UA, and not just acknowledge the receipt.
I am not sure I understand.  Are you suggesting that we need
a mechanizm to provide feedback when the profile has successfully
been applied?

> (should be) a valid subscriber before the activation process occurs.
This is a policy decision.  The subscription can be used as the
mechanism to indicate that the phone/user wants to become a valid
subscriber.  In an enterprise this is a convenient mechanism.  In
a service provider scenario, it may be considered to vulnerable to
DOS.

> Section 8.4, 1st para, change "server SHOULD secure" to "server MUST
Same issue as with above changes of SHOULD to MUST on the 
application of security.

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