Re: [BLISS] Status of draft-ietf-bliss-call-completion-10

[Shida Schubert <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bliss