Re: [Gen-art] Genart last call review of draft-ietf-sipcore-originating-cdiv-parameter-05

[Alissa Cooper <[e-mail]>]

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, [e-mail] 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:[e-mail]] 
> Envoyé : mardi 6 novembre 2018 02:18
> À : MOHALI Marianne TGI/OLN
> Cc : [e-mail]; [e-mail]; IETF list; Vijay Gurbani; [e-mail]; 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 <[e-mail]> 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 <[e-mail]> 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:[e-mail]] Envoyé : lundi 5 
>> novembre 2018 18:14 À : MOHALI Marianne TGI/OLN Cc : [e-mail]; 
>> [e-mail]; [e-mail]; 
>> [e-mail]; Jean 
>> Mahoney; [e-mail] 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 <[e-mail]> 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:[e-mail]] Envoyé : lundi 5 
>> novembre 2018 17:45 À : MOHALI Marianne TGI/OLN Cc : [e-mail]; 
>> [e-mail]; [e-mail]; 
>> [e-mail]
>> 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 <[e-mail]> 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:[e-mail]] Envoyé : lundi 29 
>> octobre 2018 21:50 À : [e-mail] Cc : [e-mail]; 
>> [e-mail]; 
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art