P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)
draft-york-p-charge-info-08

[Ballot comment]
This one's been in progress for 16 years? Oh, wow ...

Is "private network" the right term to use in

  If an untrusted entity were inserted between the trusted entities, it
  could potentially interfere with the billing records for the call.
  If the SIP connections are not made over a private network, a
  mechanism for securing the confidentiality and integrity of the SIP
  connection MUST be used to protect the information.  One such
  mechanism could be TLS-encryption of the SIP signaling stream.

? I'm not sure what the attributes are that you're expecting. Even a reference to a definition of "private network" would be helpful.

Is

A.1.  P-Charging-Vector

  P-Charging-Vector is defined in Section 4.6 of [RFC7315] and used by
  the 3GPP to carry information related to the charging of a session.
  There are, however, some differences in the semantics associated with
  P-Charging-Vector and P-Charge-Info.  P-Charging-Vector is mainly
  used to carry information for correlation of multiple charging
  records generated for a single session.  On the other hand, P-Charge-
  Info is used to convey information about the party to be billed for a
  call.  Furthermore, P-Charging-Vector has a mandatory icid-value
  parameter that is a globally unique value to identify the session for
  which the charging information is generated.  Such a globally-unique
  identifier is not necessary when carrying information about the user
  to be billed when it is attached to the corresponding session-related
  signaling.

a privacy concern?

Are the Alternatives in Appendix A mutually exclusive from P-Charge-Info? Is it an error if multiple of these are present in a single SIP request? If that's not an error, which alternative has priority, or is that not deterministic?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-york-p-charge-info-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Header Fields registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new header field is to be registered among the Standard Headers as follows:

Header Name: P-Charge-Info
Compact Form:
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-08-13):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, draft-york-p-charge-info@ietf.org, mahoney@nostrum.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (P-Charge-Info - A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'P-Charge-Info - A Private Header Field (P-Header)
Extension to the
  Session Initiation Protocol (SIP)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This text documents the current usage of P-Charge-Info, an existing
  private Session Initiation Protocol (SIP) header field (P-Header)
  used to convey billing information about the party to be charged.
  This P-Header is currently used in production by several equipment
  vendors and carriers and has been in usage since at least 2007.  This
  document is submitted to request the registration of this header
  field with the Internet Assigned Numbers Authority (IANA).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-york-p-charge-info/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-york-p-charge-info/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD Evaluation of  draft-york-p-charge-info-07. I think this is on the right track, but I have some comments I would like to resolve prior to IETF last call.
————————————

Substantive Comments:

§2: Does this draft really need to use 2119/8174 keywords? It is supposed to describe current use, not define protocol. If it states a normative requirement that is counter to current use, is anyone going to pay attention?

If you choose to keep the keywords, please add a sentence along the lines of the following to section 2:

“While this document does not define a protocol, the key words describe requirements needed to interoperate existing usage.”

… and limit the use of key words to situations where that statement is true.

(Note that most of the rest of my comments involve normative key word usage. Much of that would be moot if the document were revised to not use the key words.)

§5: What is the value of documenting the alternatives? People are already using P-Charge-Info; if we found a better alternative would they change?

§6.2, last paragraph: “ Upon receipt of an INVITE request with the P- Charge-Info header field, such an entity SHOULD use the value present in P-Charge-Info as indicating the party responsible for the charges associated with the session.”

Why is this at SHOULD strength? I’d think it would be a MAY at best, or maybe even non-normative. For example, if I run such an entity, should I care about P-Charge-Info just because one of my customers started inserting it? I further note that this seems to conflict with MAYs in §6.2.1 and §6.2.2.

§6.2.1:

- 2nd paragraph: Why the SHOULDs/SHOULD NOTs? What breaks if you send P-Charge-Info to a UA, or a UA inserts it?
- 3rd paragraph: “ UA MAY use the content of the P-Charge-Info header field present in an INVITE”
That language seems to limit use to INVITE, which does not seem to be the intent.  Also, the two MAYs in this section seem to conflict with the aforementioned SHOULD in §6.2.

§6.2.2:
- ¶1: Does “ A SIP proxy that supports this extension and receives a request, typically a SIP INVITE, without the P-Charge-Info header field MAY insert a P-Charge-Info header field. “ imply that the proxy MUST NOT insert, replace, or modify a P-Charge-Info field if the received message already contained one? Along those lines, I assume there can only be one instance/value for P-Charge-Info. If correct, please state that explicitly.

-¶2: Similarly to in §6.2.1, is this paragraph intended to limit usage to INVITE requests?
- ¶4: The SHOULD in this paragraph seems in conflict with the related MUST NOT in §6.2.1

§9.1, ¶2: Why is the SHOULD not a MUST? The text already has an escape hatch for “private networks:>

§12.2: It seems like [RFC3261] and [RFC8217] should be normative references.


Editorial Comments:

§6.2.1, ¶2: “e.g.” should be followed by a comma.

§6.3: "typically just a SIP URI”: Should that be “SIP or TEL URI”? I note a TEL URI in the examples.

§7: Please avoid normative key words when restating external requirements. For example, consider “ [RFC8217] prohibits the use of addr-spec if it’s value would contain…”