Subject: Re: [stir] draft-asveren-stir-p-charge-info

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 19 Jul 2018 12:31:12 +0000

Hi Christer,

My apologies that your Q2 below didn’t register with me as an “existential question” (from specification’s perspective) but rather as a “this needs to be included for completeness” type of comment.

Some views were expressed during the meeting yesterday but I think one critical statement was missing (mea culpa):
P-Charge-Info is used in environments where STIR/SHAKEN will be utilized. So, I think it is fair to say that if To/From header can’t be guaranteed to be trusted and therefore needs to be verified according to STIR procedures, the same would be true for P-Charge-Info as well.

Thanks,
Tolga

From: Christer Holmberg <[email-masked]>
Sent: Monday, May 28, 2018 1:55 PM
To: Asveren, Tolga <[email-masked]>; [email-masked]
Subject: RE: [stir] draft-asveren-stir-p-charge-info

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hi,

I have some questions regarding this. Some of the questions have also been raised by Keith (or are at least related):

Q1: As the purpose of draft-york-p-charge-info is document existing implementations and usage of the PCI header field, the first question is whether we should define “enhancements” and new usages of the PCI header field?

Q2: You should describe in what kind of environments this is needed.

Q3: As draft-york-p-charge-info is to be published as an Informational RFC, should draft-asveren-stir-p-charge-info also be Informational? A PASSporT extension is “Specification Required”, so I assume an Informational RFC qualifies.

Q4: The text in Section 4.3 says:

   "An entity dropping P-Charge-Info MUST drop the corresponding Identity

   header with "ppt" parameter value of "pci”."

        First, I assume you mean “an entity supporting the pci PASSporT”?

        Second, entities that only support the PCI header field, but not the pci PASSporT, will not remove the corresponding Identity header field. I think you need some text about that.

Q5: The text in section 3 says:

              "If P-Charge-Info header is added or by the…”

              Is there something missing between “or” and “by”?

Regards,

Christer

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of "Asveren, Tolga" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 8, 2018 at 2:45 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [stir] draft-asveren-stir-p-charge-info

I just submitted draft-asveren-stir-p-charge-info:

https://www.ietf.org/internet-drafts/draft-asveren-stir-p-charge-info-00..txt<https://www.ietf.org/internet-drafts/draft-asveren-stir-p-charge-info-00.txt>

It defines a new claim type for P-Charge-Info.

P-Charge-Info is going through the last steps of becoming a RFC in SIPCore WG and I though it would be a good idea to start working on/kicking off discussions about the corresponding STIR support as it is used to carry sensitive information for billing.

And here is the link for P-Charge-Info draft:

https://tools.ietf.org/html/draft-york-p-charge-info-07

Feedback/ideas/suggestions are appreciated.

Thanks,
Tolga
_______________________________________________ stir mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/stir