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

[Vijay Gurbani]

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  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.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
>
> .
>
> 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.
>

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

[marianne.mohali]

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.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

.

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 

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

[marianne.mohali]

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.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  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.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

.

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 

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

[marianne.mohali]

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 
mailto: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-parameter/

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 
mailto: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-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 

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

[Vijay Gurbani]

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  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.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  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.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
>
> .
>
> 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 

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

[Vijay Gurbani]

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  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  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.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  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" 

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

[Ben Campbell]

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  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  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  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.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  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, 

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

[marianne.mohali]

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  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  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  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  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