Draft:  draft-ietf-sipping-config-framework-08.txt
Reviewer: Even, Roni [roni.even@polycom.co.il]
Review Date: Wednesday 5/10/2006 10:56 AM CST
Review Deadline: 5/23/2006
Status: post WGLC  

Summary: 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 guidelines to writing profiles specifying what should be defined in a profile.

 

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