Draft:  draft-ietf-sipping-config-framework-12.txt
Reviewer: Shida Schubert [shida@ntt-at.com]
Review Date: 7/8/2007
Review Deadline: 7/9/2007 (extended original WGLC date from 6/25/2007)
Status:  WGLC

Summary:
----------------------------------------
 - I find the organization of the draft quite 
   confusing, there are a lot of new terms 
   introduced, normative texts are not organized 
   in a way for implementors to easily figure out 
   what they need to implement and there are some 
   text that need definite clarification. I strongly 
   feel that the draft needs some cleaning up before 
   it is ready for publication.

 - Some normative text for the spec to work seems to 
   be missing. Especially surrounding user profile 
   there is no normative text presented. 

 - For editorial comments and clarification requests 
   I sent the word file directly to the author.


General Comments:
----------------------------------------
 - This was mentioned in the last IETF, but 
   the abstraction of the process creates somewhat 
   of a confusion. All along until I reached a 
   section on how "enrollment" is conducted I 
   was unsure whether it was going to utilize 
   "SUBSCRIBE and NOTIFY". I believe if you are 
   going to keep it as is, the fact that enrollment 
   is done using "SUBSCRIBE" SHOULD be mentioned 
   in the beginning, so you don't leave the reader 
   wondering how enrollment is done until he or she 
   reaches the section where you finally explain how 
   it is done. 

 - There are many terminologies that are used indicating 
   the same things. "enrollment" <> "subscription" for 
   example, terminologies used should be consistent all 
   through the document. 

 - The attempt to abstract the procedure is not consistent, 
   enrollment and subscription/subscribe is used alternatively, 
   notification, NOTIFY and acceptance are used alternatively 
   as well. It is very confusing because many terms are flying 
   around and I like to see consistent usage of term. 

 - There are a lot of terminologies introduced in the 
   draft that I am unfamiliar with, familiar terminologies 
   should be used as much as possible. 
   e.g. "intermediary" instead of "SIP infrastructure element".
        "reference" instead of "content indirection information".

 - Some terminologies are used extensively without any definition 
   until later in the draft. Those definitions should be listed 
   in the terminology section.

 - What is called requirements in the draft really is 
   a normative text for each of the entities involved 
   in the framework. The text should be treated as such.

 - The normative text is described in the sequence of the event, 
   and not categorized by the entity involved in the framework. 
   For implementors, I believe it's always more clear when you 
   categorize the normative text by the entity(UA/PDS/Proxy).

 - Also normative text is scattered across many sections and 
   may be difficult for the implementors to figure out exactly 
   what they need to watch for, implement etc. 

 - I find the separate security section (Not security consideration 
   but a security section in the midst of the normative texts), very 
   confusing. It SHOULD either be consolidated with the part of 
   normative text where it is influenced or be consolidated in the 
   security consideration.

 - Security section is confusing because it breaks down the SIP 
   security especially TLS usage into small granularity that seems
   unnecessary and terms it with a term such as 'server identity verified TLS session' and 
      'next-hop entity verified TLS session'. 

 - There are terms that are used which are never explained what they 
   are.. "framework-specified identity', "deviceAoR" and many more(I counted 
   about 10).