[sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-callinfo-spam-04: (with COMMENT)
Barry Leiba via Datatracker <noreply@ietf.org> Tue, 17 September 2019 06:50 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A2712004E; Mon, 16 Sep 2019 23:50:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipcore-callinfo-spam@ietf.org, Brian Rosen <br@brianrosen.net>, sipcore-chairs@ietf.org, br@brianrosen.net, sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.101.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <156870302255.17474.2260736817699792687.idtracker@ietfa.amsl.com>
Date: Mon, 16 Sep 2019 23:50:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/ok5KWSLG0EjL7hyqBppByE4khiA>
Subject: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-callinfo-spam-04: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 17 Sep 2019 06:50:23 -0000
Barry Leiba has entered the following ballot position for draft-ietf-sipcore-callinfo-spam-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a number of minor comments that I hope you'll consider. — Section 3 — SIP request MAY contain several Call-Info header instances of purpose "info", either as a single header with a comma-separated list of header values or separate headers, or some combination. Nit: Correctly used, “either” selects one of two choices, not from among three or more. I suggest this: NEW SIP request MAY contain several Call-Info header instances of purpose "info", as a single header with a comma-separated list of header values or as multiple headers, each with one or more header values. END If the entity inserting the header field does not have information it wants to link to, it MUST use an empty data URL [RFC2397] as a placeholder, as in "data:,". (The Call-Info header field syntax makes the URI itself mandatory.) Nit: The parenthesized bit struck me as oddly placed; I suggest this: NEW Because the Call-Info header field syntax makes the URI mandatory, if the entity inserting the header field does not have information it wants to link to, it MUST use an empty data URL (“data:,”) [RFC2397] as a placeholder. END — Section 4 — All of the parameters listed below are optional and may appear in any combination and order. Their ABNF is defined in Section 7. All except the 'type' parameter are optional. The third sentence contradicts the first (I’m guessing it’s a paste error). I suggest this: NEW Call-Info header field parameters are listed below. Their ABNF is defined in Section 7, and they may appear in any combination and order. The ‘type’ parameter is REQUIRED, and all others are OPTIONAL. END Or, if I guessed wrong about the ‘type’ parameter, the last sentence would be “All parameters are OPTIONAL.” source The source parameter identifies the entity, by host name, domain or IP address, that inserted the 'confidence', 'origin' and 'type' parameters. It uses the "host" ABNF syntax. Where is the “host” ABNF syntax defined? Perhaps a citation here would help. — Section 5 — generally based on the caller's telephone number or possibly an assertion by a trusted caller, as the content cannot be not known. What does “as the content cannot be not known” mean? Can you please rephrase this? — Section 8.1 — The first entry in the table is incorrectly formatted: it has the reference field first instead of last. — Section 9 — as otherwise spoofed calls would likely be mislabeled and thus increase the likelihood that the called party is mislead, “misled” Thus, this information MUST only be added calls with an attestation level of "Full Attestation" [RFC8588] or for calls where the SIP entity inserting the header knows to have correct calling number information, e.g., because the call originated within the same PBX or the same carrier and the operating entity ensures that caller ID spoofing is highly unlikely within their realm of responsibility. “only be added to calls” “or to calls” “knows it has correct calling number information” Actually, the sentence is too long anyway, so I suggest splitting it. How about this?: NEW Thus, this information MUST only be added to calls with an attestation level of "Full Attestation" [RFC8588] or to calls where the SIP entity inserting the header knows it has correct calling number information. An example of how it might know that is if the call originated within the same PBX or the same carrier, and the operating entity ensures that caller ID spoofing is highly unlikely within their realm of responsibility. END
- [sipcore] Barry Leiba's No Objection on draft-iet… Barry Leiba via Datatracker