Hi Dale; Thanks for prompting this.
I did a thorough review of the draft before submitting to the IESG and I sent the following comments along with a draft with my suggested edits (all nits). After some discussions, it was found that some change in normative text can be beneficial. Authors can probably provide us with more details but Never the less below is the link to the new draft as well as to a diff. Diff: http://bliss-ietf.org/drafts/11a-diff.html Draft-11a: http://bliss-ietf.org/drafts/draft-ietf-bliss-call-completion-11_draft_a.txt Please provide comments if you have any issues with the changes and let me know if there is any issue with composing a proto-write up based on the draft referenced. Regards Shida ** E-mails I sent to the authors in July **** A lot of the fixes were an attempt to unify the terminology used. This would come up at some point and cleaning this up before submitting to IESG or AD review would probably be a good idea. For example, I tentatively chose caller's agent and callee's monitor as it indicates where the logical entity reside on the signaling path. Also, terminology like CC policy wasn't defined so I changed it to local policy of the callee's monitor etc.. Also some questions that need clarification. 1. Section 4.2 last paragraph. What is the intent of "optionally with the possibility to update the subscription."? What is optional? I couldn't see what you were trying to say here. 2. Furthermore terminology section can use some re-arrangement in terms of order in which it is described. I would start with the entities (caller/callee/caller's agent/callee's monitor) , followed by different state (cc recall, cc call), followed by the rest (cc event etc.) It would be easier to understand each terminology if you have them in groups and in an order which aids people to get familiar with the terminology. 3. Section 7.1 Why is inserting a call-info with "purpse=call-info" not a MUST when entity supports this specification? Also on the same paragraph, what is the "appropriate response"? 4. Section 7.1 "Implementations MUST accept CC operations in which the 'm' parameter is missing or has an.." All the values are optional, URI, purpose etc. so same should apply to all. IF this is not the case, URI and purpose should be changed to MUST insert.. 5. Section 7.2 I feel that following paragraph actually belongs to the section which describes the behavior of the caller's agent. "The caller's agent MUST be prepared to receive multiple responses to the SUBSCRIBE and to have multiple subscriptions established. The agent must also be prepared to have the SUBSCRIBE fail, in which case, CC cannot be invoked for this original call." 6. There is no mentioning of how to terminate the subscription. I know you just do what RFC3265 does, but may be this should be voiced out if it is the case. e.g. SHOULD terminate the the subscription according to RFC3265 etc. 7. When should "The callee’s monitor SHALL start a recall timer" ?? 8. As for the reference. I think the RFC3903(PUBLISH) SHOULD be added to a reference. I also think that RFC5359 can be an informational reference instead of normative. I will have another close look at the IANA registration section and will get back to you. I know that MIME registration should contain more information. Regards Shida ************************ Regards Shida On Sep 1, 2011, at 3:07 AM, Worley, Dale R (Dale) wrote: > What is the status of draft-ietf-bliss-call-completion? > > The last message I can find is > http://www.ietf.org/mail-archive/web/bliss/current/msg01188.html (6 > May 2011) in which Martin H. uploaded the -10 version. As far as I > can remember, everyone has commented on -09 and -10a (even myself) and > had their comments addressed. That comment cycle was a WGLC, so we > should be set to take it to the IESG. > > Dale > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
