[sipcore] Doc Shepherd review of draft-ietf-sipcore-originating-cdiv-parameter

["A. Jean Mahoney" <[e-mail]>]

Hi Marianne,

Thanks for addressing all of the feedback so far. In preparation for the 
Doc Shepherd Write-up, I have run idnits, gone through the ID Checklist, 
and made my own pass through the draft. I have the following feedback 
below --

Thanks!

Jean

-------------------------------------------------
Minor issues:

idnits found issues in the Abstract, disclaimers, and key words:

idnits: "The draft header indicates that this document updates RFC5502, 
but the abstract doesn't seem to directly say this.  It does mention 
RFC5502 though, so this could be OK."

   This issue can be fixed with a few tweaks:
   - Delete the first mention of RFC5502 (citations are not allowed
     in Abstracts)
   - s/This document updated RFC5502/This document updates RFC 5502/
   - s/ABNF in RFC5502/ABNF in RFC 5502/ (When RFCs are mentioned
     rather than cited, they should have the form "RFC NNNN" rather
     than "RFCNNNN")


idnits: "The document seems to lack a disclaimer for pre-RFC5378 work..."

I found some reuse of RFC5502 text in the Abstract and in Section 1.2. 
You can contact Elburg to see if he is willing to grant the BCP78 rights 
to the IETF Trust, or you can include text from Section 6.c.iii from 
https://trustee.ietf.org/documents/IETF-TLP-5_001.html. If you are using 
xml2rfc, you would set the 'ipr' attribute on the 'rfc' tag to 
"pre5378Trust200902". See Appendix A of RFC7749 for more info.


idnits: "The document seems to lack both a reference to RFC 2119 and the 
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 
keywords."

To fix this, the following section needs to be added after the Introduction:

2.  Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in
    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here.


Section 5.2.  ABNF

Add the following to address errata ID 4648:

       This document allows choosing between addr-spec and name-addr when
       constructing the header field value. As specified in RFC 8217,
       the "addr-spec" form MUST NOT be used if its value would contain
       a comma, semicolon, or question mark [RFC8217].


Section 6.  IANA Considerations

Append the following after "sub-registry" (in paragraphs 2 and 3): 
"within the "Session Initiation Protocol (SIP) Parameters" registry: "


Section 7.  Call Flow Examples

It would be nice if each step had a brief sentence describing what is 
happening.


10.1 Normative References

Add references to RFC2119 and RFC8174 (for keywords), RFC3324 (for Trust 
Domain definition), RFC8217 (ABNF clarification).

Move RFC 5502 from Informational References to this section.



---------------------------------------------------
Nits:

Abstract:  s/services has been/services have been/


Section 1.1.  General

p 1. s/information on the IMS/information on session cases and the IMS/

p 3. s/correct the syntax/corrects the syntax/
      s/some examples and/some examples, and/


Section 1.2.  Basic Use Case

p 2. Current:
                                                      ...and apply the
    corresponding actions such as forward the request to an AS.  At its
    turn, the AS has to go through a similar process of determining who
    is the current served user, what is his/her "registration state" and
    on which "session case" is the session.

    Suggested:
                                                   ...and applies the
    corresponding actions such as forwarding the request to an AS.
    The AS then goes through a similar process of determining who
    is the current served user, what is his/her "registration state", and
    what is the "session case" of the session.

p 3. s/the is/there is/
      s/realized but/realized, but/
      s/poses some/pose some/


Section 1.3.  Problem Statement

p 1. s/In case of/In the case of/
      s/case and the terminating/case, and the terminating/
      s/Receiving the call/When the AS receives the call/
      s/remains the same and/remains the same, and/

    Current:

           ..., there is no possiblity for a proxy to trigger
    an originating service for the diverting user or for an AS
    to execute...

    Suggested:

              ..., the S-CSCF cannot trigger an originating
    service for the diverting user, nor can an AS execute...


Section 2.  Applicability

p 1. s/Trust Domain for/Trust Domain [RFC3324] for the/


Section 3.  Proxy behavior and parameter handling

no 3. Current:

    3.  The S-CSCF starts the analysis of filter criteria and triggers
        the served user AS for the terminating services to be executed by
        including in the INVITE request the P-Served-User header field
        with the "sescase" parameter set to "term" and the regstate to
        the corresponding value;

    Suggested:

    3.  The S-CSCF analyzes the filter criteria. It then sends to the
        AS of the served user an INVITE that includes the P-Served-User
        header field with the "sescase" parameter set to "term" and
        the "regstate" set to the corresponding value in order to
        trigger execution of terminating services;

no 4.  s/The received Request-URI is then replaced/The AS replaces the 
received Request-URI/

no 5.  s/parameter by the/parameter with the/

no 6.  s/request over to/request to/

no 7.  s/and will perform/and performs/


Section 4.  Clarifications of RFC 5502 procedures

p 1.  s/guidance that reminds and clarifies the/guidance for the 
handling of the/

bullet 1.
    s/This header MUST NOT/The P-Served-User header field MUST NOT/
    s/that P-Served-User/that the P-Served-User/

bullet 2.  Current:

    o  Whether the "regstate" parameter is removed or not by the S-CSCF
       when processing the orginating after CDIV session case is out of
       the scope of this document.  In one hand, it can either be
       considered that the S-CSCF is able to store the previous regstate
       value and that the same value applies or that the "regstate" is
       not relevant after a diverting service.  On the other hand, the
       regstate can be combined to the orig-cdiv session case...

   Suggested:

    o  Whether the S-CSCF removes the "regstate" parameter when it
       processes the orig-cdiv session case is out of the scope of
       this document.  The S-CSCF could store the previous regstate
       value and that the same value applies, or the "regstate" may
       not be relevant after a diverting service, or the
       regstate could be combined with the orig-cdiv session case...


Section 5.1.  General

p 2.  Current:

    Because this document extends the existing sessioncase-param
    parameter in a special way and that it has been identified errors in
    the syntax of the P-Served-User header field [RFC5502], this document
    corrects and extends the header at the same time.

    Suggested:

    Because this document extends the existing sessioncase-param
    parameter, and because errors have been identified in
    the syntax, this document corrects and extends the
    P-Served-User header field.

p 3. s/release 11/Release 11/
      s/keep a/to maintain/


Section 7.1. Call diversion case

p 1.  Current:

    The following call flow shows a session establishement for Alice
    calls Bob which has a call diversion when busy towards Carol.

    Suggested:

    The following call flow shows a session establishment when Alice
    calls Bob, who has a call diversion service that diverts to Carol
    when Bob is busy.