Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 15 Mar 2018 08:48:51 -0500

Hi all,

This draft received no feedback during WGLC. We need at least some 
indication that WG participants have read the draft. If you have read it 
and you think that the draft is ready, please explicitly state that on 
list.

Thanks!

Jean

On 2/19/18 3:02 PM, A. Jean Mahoney wrote:
> Hi all,
> 
> Working Group Last Call starts today for 
> draft-ietf-sipcore-originating-cdiv-parameter.
> 
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/ 
> 
> 
> Although this draft has received WG support, this draft has not received 
> much in the way of feedback. Please provide feedback to the sipcore 
> mailing list by Monday, March 5th.
> 
> Thanks!
> 
> Jean
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Mar 2018 15:05:20 +0000

Hi,

I have read it previously, but I will re-read it today :)

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of A. Jean Mahoney
Sent: 15 March 2018 15:49
To: [email-masked]
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter

Hi all,

This draft received no feedback during WGLC. We need at least some indication that WG participants have read the draft. If you have read it and you think that the draft is ready, please explicitly state that on list.

Thanks!

Jean

On 2/19/18 3:02 PM, A. Jean Mahoney wrote:
> Although this draft has received WG support, this draft has not 
> received much in the way of feedback. Please provide feedback to the 
> sipcore mailing list by Monday, March 5th.
> 
> Thanks!
> 
> Jean
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Mar 2018 11:43:03 -0400

> and you think that the draft is ready, please explicitly state that on 

I have read the document.

In terms of form I think this document is ready.

I do find it somewhat disturbing that the document is so very 
IMS-dependent. It feels like it ought to be a 3gpp document rather than 
an IETF document. You can't really fully understand this document 
without a detailed understanding of the functioning of IMS. (My very old 
understanding of IMS is sufficient for me to get the gist of it, but not 
the details.)

This has to be an IETF document because it is revising a sip header 
field. IMO it would be better to simply say that this is only applicable 
in an IMS environment and leave all the details of how it works to IMS 
documents. But that is a question of style. So I won't object to the 
document in the current form.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Mar 2018 17:55:13 +0000

Hi,

I have reviewed the document, and technically I have no issues.

However, do have some editorial comments that the author may want to consider:

---

Q1:

In general, you may want to check that you use consistent terminology. For example, you sometimes say "AS", sometimes "Application Server". My suggestion is to say "AS (Application Server)" on first occurrence, and thereafter "AS".

---

Q2:

In general, in many place of the document you say things like "The P-Served-User header field is defined in [RFC5502]". I think it is enough to simply say "The P-Served-User header field [RFC5502]" 

---

Q3:

In the Abstract, I think some of the sentences should move location. In addition, you repeat some of the things twice.

I suggest something like the following:
 
   "The P-Served-User header field [RFC5502] is used to convey the identity of the served user and
   the session case that applies to this particular communication session and application invocation."
   This specification defines a new P-Served-User header field parameter, "orid-cdiv".  
   The parameter conveys the session case used by a proxy when handling an originating 
   session after Call Diversion (CDIV) services has been invoked for the served user. 

---

Q4:

Since the draft also fixes the ABNF in RFC 5502, I think it would be good to indicate that already in the Abstract and Introduction.

Similarly, the document seems to clarify some of the RFC 5502 procedures, so that would also be good to mention.

---

Q5:

In Section 1.1:

s/The P-Served-User header field was defined in [RFC5502] to address/ The P-Served-User header field [RFC5502] was defined in to address/

---

Q6:

In Section 1.1, the text says that the P-Served-User header field was defined to "address an issue", but it doesn't say what the "issue" is. I suggest to simply say what the header field was defined based on a requirement from 3GPP, in order to convey blah blah blah.

---

Q7:

In Section 2, do you need to first sentence in the first paragraph? Isn't that covered in the Applicability section?

---

Q8:

In Section 2:

s/For a terminating call, when receiving the initial INVITE request, the S-CSCF will determine that.../When the S-CSCF receives the initial INVITE request for a terminating call, it will determine that...

---

Q9:

In Section 2, I think it would be more clear to describe the different steps taken by the S-CSCF and AS using a numbered bullet list. Then you may not need all the "Next", "After that", etc.

---

Q10:

In Section 2, the last part starts with:

"This document also provides the following guidance that reminds or clarifies the P-Served-User handling that are missing in [RFC5502]:"

I think this text should be in a separate section: "Clarification of RFC 5502 procedures", or something.

---

Q11:

In Section 2:

s/is forbidden to be repeated/MUST NOT be repeated

---

Q12:

In Section 2, you say "tagged thanks to the mp-param header". I suggest to use another word than "thanks to". "using" perhaps?

---

Q13:

In Section 2:

s/The PServedUser-value remains/The P-Served-User header field value remains

---

Q14:

Would it be good to put the "Applicability" section BEFORE the current Section 2?

---

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of A. Jean Mahoney
Sent: 15 March 2018 15:49
To: [email-masked]
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter

Hi all,

Thanks!

Jean

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Mar 2018 08:29:43 -0400

> and you think that the draft is ready, please explicitly state that on 

I support approving this draft.

I have read this draft during some of its previous periods of
discussion, including the period leading up to WGLC (around 2 Feb 2018).
At that time I noted that while the proposed syntax is not as regular as
I'd like, the proposed syntax is already deployed in the real world, and
the best cost/benefit is to not change it.

Also, I have a suggestion for improving how the syntax is presented.
The current (-01) ABNF includes:

 sessioncase-param        = 1("sescase" EQUAL 1("orig" / "term")/ orig-cdiv)
 registration-state-param = "regstate" EQUAL 1("unreg" / "reg")

whereas it is more conventional to express that in this manner:

 sessioncase-param        = "sescase" EQUAL ("orig" / "term") / orig-cdiv
 registration-state-param = "regstate" EQUAL ("unreg" / "reg")

Dale