Hi all, Thanks Vijay for the GenArt review. I've just submitted a v-06 to address your comments and here is my feedbacks: https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/ >Minor: > >- S1.3: I am not sure I follow the logic in the problem statement. Who > is the "diverting" user? The user to who the call was destined? If so, > best to say that explicitly. (To be sure, I looked into rfc5502 as well, > and it does not define "diverting" user either.) A bit below (in S4), you > use the term "served" user to refer to the diverting user. All in all, the > terminology here could be refined. I suspect that the "originating" user > is the callee. > > Concretely, I think that the first paragraph of S1.3 should be re-written, > perhaps with a figure (?) to explain the call flow, or at least some > context using Alice, Bob and Carol as the example in S7.1 does (I suspect > that Carol is the "diverting" user here). [MM] Indeed, I can see that for people not very aware of IETF and 3GPP vocabulary for call diversion service, it can be confusing. I prefer not to add a call flow in the problem statement section but I did some updates in the wording and inserted the Alice, Bob and Carol users for a better understanding. >Nits, typos: > >- S4, step 3: s/user an INVITE that/user as an INVITE that/ > Also, the "secase" and "regstate" parameters are what you are standardizing > this I-D, as such you mention this before S4 so the reader knows that > these are the new parameters. Same for "orig-cdiv" parameter. [MM] Nits is corrected. About your comment, actually, this I-D is only standardizing "orig-cdiv" parameter. This is the reason why "sescase" and "regstate" appear, as part of a normal session establishment and before any call diversion while the new parameter can appear only when this event occurs (as added by this I-D).. I hope it's clearer for you. I hope it's ok. Best regards, Marianne -----Message d'origine----- De : Vijay Gurbani [mailto:vijay.gurbani@xxxxxxxxx] Envoyé : lundi 29 octobre 2018 21:50 À : gen-art@xxxxxxxx Cc : sipcore@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-sipcore-originating-cdiv-parameter.all@xxxxxxxx Objet : Genart last call review of draft-ietf-sipcore-originating-cdiv-parameter-05 Reviewer: Vijay Gurbani Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sipcore-originating-cdiv-parameter-?? Reviewer: Vijay K. Gurbani Review Date: 2018-10-29 IETF LC End Date: 2018-10-26 IESG Telechat date: Not scheduled for a telechat Summary: This draft is on the right track but has open issues, described in the review. Major issues: 0 Minor issues: 1 Nits/editorial comments: 1 Minor: - S1.3: I am not sure I follow the logic in the problem statement. Who is the "diverting" user? The user to who the call was destined? If so, best to say that explicitly. (To be sure, I looked into rfc5502 as well, and it does not define "diverting" user either.) A bit below (in S4), you use the term "served" user to refer to the diverting user. All in all, the terminology here could be refined. I suspect that the "originating" user is the callee. Concretely, I think that the first paragraph of S1.3 should be re-written, perhaps with a figure (?) to explain the call flow, or at least some context using Alice, Bob and Carol as the example in S7.1 does (I suspect that Carol is the "diverting" user here). Nits, typos: - S4, step 3: s/user an INVITE that/user as an INVITE that/ Also, the "secase" and "regstate" parameters are what you are standardizing this I-D, as such you mention this before S4 so the reader knows that these are the new parameters. Same for "orig-cdiv" parameter. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
