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 <[email protected]> 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:[email protected]]
> Envoyé : lundi 29 octobre 2018 21:50
> À : [email protected]
> Cc : [email protected]; [email protected];
> [email protected]
> 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.
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
