[sipcore] AD Evaluation of draft-ietf-sipcore-originating-cdiv-parameter-03

Ben Campbell <ben@nostrum.com> Fri, 07 September 2018 20:50 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC526130DDB; Fri, 7 Sep 2018 13:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYgCqsdHkXsl; Fri, 7 Sep 2018 13:50:42 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0C312F18C; Fri, 7 Sep 2018 13:50:39 -0700 (PDT)
Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w87KoZXO036963 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 7 Sep 2018 15:50:38 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95]
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CD151BA0-A26A-478C-80E4-F0F4186F0179"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <A02C7351-F6E8-4DBA-8DFB-B5037CAD66EA@nostrum.com>
Date: Fri, 07 Sep 2018 15:50:33 -0500
Cc: sipcore@ietf.org
To: draft-ietf-sipcore-originating-cdiv-parameter.all@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/wZpss38X9duSEY3kxhJDx2B9Bos>
Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-originating-cdiv-parameter-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Sep 2018 20:50:44 -0000

Hi,

This is my AD Evaluation of draft-ietf-sipcore-originating-cdiv-parameter-03.

The draft is mostly in good shape. I have a small number of substantive comments, and some editorial comments. I would like to resolve the substantive comments prior to IETF Last Call.

Thanks!

Ben.

-------------------------------

Substantive Comments:

- Is it possible to add a short explanation of “session case”? Right now, the draft refers to 5502, but that RFC calls out to 29.228 for the definition. I think reviewers are going to find the lack of a “local” definition confusing; most will probably not drill all the way down to 29.228. I’m not asking for a lot of detail, but I think a few sentences are in order. I recognize that RFC 5502 did not do this, but I think that is a deficiency in that RFC.

§4, step 3:

Likewise, I don’t think the average non-3GPP IETF reader will understand “filter criteria” in this context. Can there be a few sentences describing it? (such as in 5502?)

§5,

- first bullet: Is the real change that the field MUST NOT contain _different_ values, or it MUST NOT contain _multiple_ values?
- 2nd bullet: It’s not clear to me what is guidance about 5502 is being offered here; this sounds more like a disclaimer about things being out of scope for this draft. Does it really belong in the bullet list?

§7, updates to the P-Served-User header field parameters:
Why do the sescase and regstate lines need to be updated to include RFCXXXX?

§9: “... it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity.”

Can you say something more concrete here? How would one go about doing that? Should an AS or S-CSCF remove any cdiv parameters that it did not insert? What if a client were to insert the parameter?

Editorial Comments:

§1.2:

- Is “allocates” the correct word for assigning an S-CSCF to a user? In my mind, “allocate” connotes reserving a resource, perhaps in a way that makes it unavailable to others. Perhaps “assigns” would be better?

- 2nd paragraph:
s/ “allocated for” / “allocated to”.
s/  “HSS (Home Subscriber Server)” / “Home Subscriber Server (HSS)”
Please expand AS on first use.

§1.3:
- " first considered as a terminating session case” - Considered by what? Also, is “considered” the correct term? Perhaps something more concrete like “treated” would make more sense?

§3: " inside a Trust Domain [RFC3324] for P-Served-User header field.”
Missing article before “P-Served-User”

§4,
- step 3: " It then sends to the AS”
I suggest “sends the request to the AS”
- step 6: I suggest striking the word “specifically”

§7: The IANA considerations should either be the 2nd to last or last section. (IANA considerations and Security considerations should be the last two sections.)