Editorial comment: Since “originating after CDIV” is effectively used as a compound adjective, it would be better to hyphenate it, as in “originating-after-CDIV session”. That might also make it less confusing to people unfamiliar with the terminology. (Such a change can wait to be handled along with any IESG review comments.) Thanks! Ben. > On Nov 6, 2018, at 12:57 AM, Vijay Gurbani <vijay.gurbani@xxxxxxxxx> wrote: > > Dear Marianne: OK, if the context of "originating after CDIV" is well understood by the folks working in this area, then I am fine with leaving it as is. > Thanks. > - vijay > > On Mon, Nov 5, 2018 at 11:51 AM <marianne.mohali@xxxxxxxxxx> wrote: > Dear Vijay, > > > > Actually, the « originating » is not qualifying something by itself in this sentence, it has to be understood as a global wording for the new defined session case which is "originating after CDIV" which is different for an “originating call leg”. > > > > If you don’t mind, I would prefer to keep this wording as it is because it is used although the I-D and quoted in the Introduction section in the following sentence: > > "The sessioncase-param parameter of the P-Served-User header field is extended with the "orig-cdiv" parameter for this "originating after CDIV" session case." > > > > Marianne > > > > De : Vijay Gurbani [mailto:vijay.gurbani@xxxxxxxxx] > Envoyé : lundi 5 novembre 2018 18:14 > À : MOHALI Marianne TGI/OLN > Cc : gen-art@xxxxxxxx; sipcore@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-sipcore-originating-cdiv-parameter.all@xxxxxxxx; Jean Mahoney; ben@xxxxxxxxxxx > Objet : Re: Genart last call review of draft-ietf-sipcore-originating-cdiv-parameter-05 > > > > Dear Marianne: Thank you, again, for attending to my comment. > > > > Note that you still have a dangling verb "originating" in the sentence. The verb is not qualifying anything: > > > > For this use case, this document creates a new parameter ("orig-cdiv") for > the originating after CDIV session case to be embedded in the P-Served-User > header field. > > > > In my email, I had suggested adding "call leg" after the "originating" above. Otherwise, the sentence above is incomplete ... "originating" what? > > > > Thanks. > > > > > > On Mon, Nov 5, 2018 at 11:04 AM <marianne.mohali@xxxxxxxxxx> wrote: > > Thanks Vijay for your last feedback. I’m fine with your proposal and have updated the I-D accordingly (v-07): > https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/ > > BR, > Marianne > > De : Vijay Gurbani [mailto:vijay.gurbani@xxxxxxxxx] > Envoyé : lundi 5 novembre 2018 17:45 > À : MOHALI Marianne TGI/OLN > Cc : gen-art@xxxxxxxx; sipcore@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-sipcore-originating-cdiv-parameter.all@xxxxxxxx > Objet : Re: Genart last call review of draft-ietf-sipcore-originating-cdiv-parameter-05 > > Dear Marianne: Thank you for attending to my comments. > > I am fine with the text you added for S1.3. > > Regarding "secase" and "regstate" being existing parameters, ok. However, since the I-D is defining the "orig-cdiv" parameter, I still think it makes sense to mention this before S4. You already have the text at the end of S1.3 (the current sentence appears ambiguous). Let me suggest an edit: > > OLD: > For this use case, this document creates a new parameter for the > originating after CDIV session case to be embedded in the P-Served- > User header field. > > NEW: > For this use case, this document creates a new parameter ("orig-cdiv") for the > originating call leg to be embedded in the P-Served-User header field. > Thanks. > > On Mon, Nov 5, 2018 at 10:30 AM <marianne.mohali@xxxxxxxxxx> wrote: > 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. > > _________________________________________________________________________________________________________________________ > > 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. > > _________________________________________________________________________________________________________________________ > > 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. >
Attachment:
signature.asc
Description: Message signed with OpenPGP
