Subject: [Sipping] SIPPING-RT review of draft-ietf-sipping-config-framework-08.txt

From: "Even, Roni" <[email-masked]>
Date: Wed, 10 May 2006 18:58:20 +0300

My view of the status of this draft is that this draft is on the right track but has open issue, described in the review. 

The issue I would like to address is:

The decomposition to four separate profile types may look logically correct but it may cause inconsistent clients or profile data implementations. The problem with data overlap is mentioned in section 4.2. According to the text the merging semantics should be in the profile syntax but by having four different profiles with no hints about how to define the merging it may be problematic. Also by not having a general rule it will be a problem for clients to figure out how to merge. Maybe there should be a recommendation on merging order here. My recommendation is to have a reference to the guidelines to writing profiles.

Other editorial and nits:

1.      The examples in section 7.2 looks like partial messages both the SUBSCRIBE and mostly the NOTIFY. In the table following the example for NOTIFY you need to have for profile-type device, the network-user as a "s".

2.      Section 7.3 " This package defines no new use of the SUBSCRIBE request body." Does this mean that there are no request bodies in the SUBSCRIBE or that there are bodies specified elsewhere that can be used.

3.      in the example in section 7.12 maybe add the network-user in the subscribe and notify.

4.      There are two acknowledgment sections 

Nits

1.	In the abstract add commas "The objective is to define a means for automatically providing profile data, a user agent needs to be functional, without user or administrative intervention."
2.	In 5.1 first bullet item " profie" "profile" and in bullet 7 " retriving" to "retrieving" 
3.	In 5.2 bullet 3 "certficate" to "certificate"
4.	In section 6 3rd paragraph " The one thing that is does know is it's instance id" change to " The one thing that it does know is its instance id"
5.	In section 7.2 " adminstration" to " administration", " be know to the the configuration" to " be known to the configuration", " assocated" to " associated"
6.	In 7.6 " conections" to " connections"
7.	In 7.7 " integrety" to "integrity" 
8.	In 8.1.2 and 8.1.3 " persistantly" to " persistently"
9.	In 10.1 "certficate" to " certificate"
10.	In 10.2 "interoperablity" to "interoperability" also  retrieive to retrieve, retreival to retrieval, authenication to authentication

Roni

*******************************************************************

Roni Even

Polycom 

Tel: +972-3-9251200

Mobile: +972-54-5481099

Fax: +972-3-9211571

email: [email-masked]

_______________________________________________
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: Daniel Petrie <[email-masked]>
Date: Thu, 11 May 2006 11:27:03 -0700 (PDT)

Hi Roni:
Thanks for the review comments.
see below:

--- "Even, Roni" <[email-masked]> wrote:

> My view of the status of this draft is that this draft is on the
> right track but has open issue, described in the review. 
> 
>  
> 
> The decomposition to four separate profile types may look logically
> correct but it may cause inconsistent clients or profile data
> implementations. The problem with data overlap is mentioned in
> section 4.2. According to the text the merging semantics should be in
> the profile syntax but by having four different profiles with no
> hints about how to define the merging it may be problematic. Also by
> not having a general rule it will be a problem for clients to figure
> out how to merge. Maybe there should be a recommendation on merging
> order here. My recommendation is to have a reference to the
> guidelines to writing profiles.
I agree with your issues above concerning the profiles.  However I
consider these to be out of scope for this document.  These are issues
to be documented in:
draft-petrie-sipping-profile-datasets:
http://www.softarmor.com/wgdb/docs/draft-petrie-sipping-profile-datasets-03.txt

> Other editorial and nits:
Thanks you for the edits and nits.  I will work these into the
next revision of the  draft.

Cheers,
Dan
> 
>  
> 
> 1.      The examples in section 7.2 looks like partial messages both
> the SUBSCRIBE and mostly the NOTIFY. In the table following the
> example for NOTIFY you need to have for profile-type device, the
> network-user as a "s".
> 
> 2.      Section 7.3 " This package defines no new use of the
> SUBSCRIBE request body." Does this mean that there are no request
> bodies in the SUBSCRIBE or that there are bodies specified elsewhere
> that can be used.
> 
> 1.	In the abstract add commas "The objective is to define a means for
> automatically providing profile data, a user agent needs to be
> functional, without user or administrative intervention."
> 4.	In section 6 3rd paragraph " The one thing that is does know is
> it's instance id" change to " The one thing that it does know is its
> instance id"
> 5.	In section 7.2 " adminstration" to " administration", " be know to
> the the configuration" to " be known to the configuration", "
> assocated" to " associated"
> 10.	In 10.2 "interoperablity" to "interoperability" also  retrieive
> to retrieve, retreival to retrieval, authenication to authentication

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

---

From: "Dale R. Worley" <[email-masked]>
Date: Sun, 28 May 2006 22:53:43 -0400

On Thu, 2006-05-11 at 11:27 -0700, Daniel Petrie wrote:
> > section 4.2 [7.2? -- DRW]. According to the text the merging semantics should be in

> consider these to be out of scope for this document.

It might be helpful to the reader to insert an explanation of why the
fact that the I-D does not specify how to resolve overlap problems will
not inhibit use of this mechanism in practice.  Otherwise, people might
postpone using this system, thinking it is incomplete, which is the
*last* thing we want.

Dale