Vijay, thank you for your review. Marianne, thank you for your responses. I entered a No Objection ballot.
Alissa > On Nov 6, 2018, at 1:30 AM, marianne.moh...@orange.com wrote: > > Ok no problem, I keep it in mind for a further update of the I-D. > > Marianne > > -----Message d'origine----- > De : Ben Campbell [mailto:b...@nostrum.com] > Envoyé : mardi 6 novembre 2018 02:18 > À : MOHALI Marianne TGI/OLN > Cc : gen-art@ietf.org; sipc...@ietf.org; IETF list; Vijay Gurbani; > draft-ietf-sipcore-originating-cdiv-parameter....@ietf.org; A. Jean Mahoney > Objet : Re: Genart last call review of > draft-ietf-sipcore-originating-cdiv-parameter-05 > > 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.gurb...@gmail.com> 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.moh...@orange.com> 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.gurb...@gmail.com] Envoyé : lundi 5 >> novembre 2018 18:14 À : MOHALI Marianne TGI/OLN Cc : gen-art@ietf.org; >> sipc...@ietf.org; i...@ietf.org; >> draft-ietf-sipcore-originating-cdiv-parameter....@ietf.org; Jean >> Mahoney; b...@nostrum.com 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.moh...@orange.com> 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-p >> arameter/ >> >> BR, >> Marianne >> >> De : Vijay Gurbani [mailto:vijay.gurb...@gmail.com] Envoyé : lundi 5 >> novembre 2018 17:45 À : MOHALI Marianne TGI/OLN Cc : gen-art@ietf.org; >> sipc...@ietf.org; i...@ietf.org; >> draft-ietf-sipcore-originating-cdiv-parameter....@ietf.org >> 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.moh...@orange.com> 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-p >> arameter/ >> >>> 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.gurb...@gmail.com] Envoyé : lundi 29 >> octobre 2018 21:50 À : gen-art@ietf.org Cc : sipc...@ietf.org; >> i...@ietf.org; >> draft-ietf-sipcore-originating-cdiv-parameter....@ietf.org >> 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. >> > > > _________________________________________________________________________________________________________________________ > > 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. > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
