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

From: Richard Shockey <[email-masked]>
Date: Tue, 08 May 2018 20:35:23 -0400

Who wants this?   What is the use case or business case for this as a PASSporT?  

I’m actually curious?

It has certainly taken way to long for Dan York’s draft to float through the convoluted IETF process but why? 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of "Asveren, Tolga" <[email-masked]>
Date: Tuesday, May 8, 2018 at 2:45 PM
To: "[email-masked]" <[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

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] https://www.ietf.org/mailman/listinfo/stir

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 9 May 2018 06:28:06 +0000

Thanks for the questions.

i- draft-york-p-charge-info will be sent for IESG processing soon. There are no pending technical/nit issues. If I may say, the reason for the delay is the “usual IETF backlog”. This draft is used in practice, considered needed by various organizations, e.g. FCC, TCC (JJ.90 30).

ii- P-Charge-Info conveys sensitive information about billing so its assertion is critical to avoid fraud therefor the need for a PASSporT extension. Several operators I had conversed as part of commercial projects were seeing this as a “natural extension” for P-Charge-Info. Do you think it shouldn’t be asserted? If so, why?

Thanks,
Tolga

From: stir <[email-masked]> On Behalf Of Richard Shockey
Sent: Tuesday, May 8, 2018 8:35 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
________________________________

I’m actually curious?

—

Richard Shockey

Shockey Consulting LLC

www.shockey.us<http://www.shockey.us>

www.sipforum.org<http://www.sipforum.org>

richard<at>shockey.us

PSTN +1 703-593-2683

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

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>

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

---

From: Keith Drage <[email-masked]>
Date: Thu, 24 May 2018 15:44:25 +0100

Just to be clear, the underlying protocol document is not a SIPCORE WG 
item, but being progressed as as an individual draft.

New SIP header fields can be created by such an individual draft in 
accordance with RFC 5727:

"

        The proposed header field MUST be of a purely informational
        nature and MUST NOT significantly change the behavior of SIP
        entities that support it.  Header fields that merely provide
        additional information pertinent to a request or a response are
        acceptable; these header fields are thus expected to have few, if
        any, implications for interoperability and backwards
        compatibility.  Similarly, header fields that provide data
        consumed by applications at the ends of SIP's rendezvous
        function, rather than changing the behavior of the rendezvous
        function, are likely to be providing information in this sense.
        If the header fields redefine or contradict normative behavior
        defined in Standards Track SIP specifications, that is what is
        meant by significantly different behavior.  Ultimately, the
        significance of differences in behavior is a judgment call that
        must be made by the expert reviewer.

"
However individual drafts tend to make slow progress without WGs to 
drive them.

I have no opinion on whether STIR should have support, but would 
question whether a WG standards track item should be defined to support 
protocol that was not progressed as a WG item and is an informational RFC.

regards

Keith

On 09-May-18 1:35 AM, Richard Shockey wrote:
> It has certainly taken way to long for Dan York’s draft to float 
> through the convoluted IETF process but why?
>
> —
>
> Richard Shockey
>
> Shockey Consulting LLC
>
> *From: *stir <[email-masked]> on behalf of "Asveren, Tolga" 
> <[email-masked]>
> *Date: *Tuesday, May 8, 2018 at 2:45 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[stir] draft-asveren-stir-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.
>
> _______________________________________________ stir mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/stir
>
>
>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 25 May 2018 16:49:50 +0000

i- P-Charge-Info header is used over a decade in US by Tier-1’s and also in some other geographies, e.g. Japan. The reason why there was a relatively recent push to get it RFCed was mainly due to FCC.
ii- draft-york-p-charge-info-07  indeed is a non-WG item. I don’t know whether that would cause problems as questioned by Keith. Any feedback on this is appreciated.
iii- draft-york-p-charge-info-07 is now in AD-evaluation phase and I am in the process to address the comments.
iv- If used, P-Charge-Info has sensitive information and it being verified, if possible, is a natural expectation IMHO. Therefore, I submitted draft-asveren-stir-p-charge-info.

Thanks,
Tolga

From: stir <[email-masked]> On Behalf Of Keith Drage
Sent: Thursday, May 24, 2018 10:44 AM
To: [email-masked]
Subject: Re: [stir] draft-asveren-stir-p-charge-info

Just to be clear, the underlying protocol document is not a SIPCORE WG item, but being progressed as as an individual draft.

New SIP header fields can be created by such an individual draft in accordance with RFC 5727:

"

       must be made by the expert reviewer.
"
However individual drafts tend to make slow progress without WGs to drive them.

I have no opinion on whether STIR should have support, but would question whether a WG standards track item should be defined to support protocol that was not progressed as a WG item and is an informational RFC.

regards

Keith

I’m actually curious?

—

Richard Shockey

Shockey Consulting LLC

richard<at>shockey.us

PSTN +1 703-593-2683

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

Thanks,
Tolga

stir mailing list

[email-masked]<mailto:[email-masked]>

---

From: Keith Drage <[email-masked]>
Date: Sat, 26 May 2018 14:22:50 +0100

Just to restate, I am not expressing an opinion either for or against this.

I note that your document currently contains no normative references. I 
would have assumed that draft-york would have to be a normative 
reference (it is currently missing from the reference section, and there 
is apparently no section entitled normative references), and therefore 
at the very least, this would have to be an approved downref from a 
standards track document to an informational document.

But you may know differently!

regards

Keith

On 25-May-18 5:49 PM, Asveren, Tolga wrote:
>
> i- P-Charge-Info header is used over a decade in US by Tier-1’s and 
> also in some other geographies, e.g. Japan. The reason why there was a 
> relatively recent push to get it RFCed was mainly due to FCC.
>
> ii- draft-york-p-charge-info-07  indeed is a non-WG item. I don’t know 
> whether that would cause problems as questioned by Keith. Any feedback 
> on this is appreciated.
>
> iii- draft-york-p-charge-info-07 is now in AD-evaluation phase and I 
> am in the process to address the comments.
>
> iv- If used, P-Charge-Info has sensitive information and it being 
> verified, if possible, is a natural expectation IMHO. Therefore, I 
> submitted draft-asveren-stir-p-charge-info.
>
> Thanks,
>
> Tolga
>
> *From:*stir <[email-masked]> *On Behalf Of *Keith Drage
> *Sent:* Thursday, May 24, 2018 10:44 AM
> *To:* [email-masked]
> *Subject:* Re: [stir] draft-asveren-stir-p-charge-info
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> question whether a WG standards track item should be defined to 
> support protocol that was not progressed as a WG item and is an 
> informational RFC.
>
> regards
>
> Keith
>
>     www.shockey.us <http://www.shockey.us>
>
>     www.sipforum.org <http://www.sipforum.org>
>
>     richard<at>shockey.us
>
>     *From: *stir <[email-masked]>
>     <mailto:[email-masked]> on behalf of "Asveren, Tolga"
>     <[email-masked]> <mailto:[email-masked]>
>     *To: *"[email-masked]" <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>
>     on/kicking off discussions about the corresponding STIR support as
>     it is used to carry sensitive information for billing.
>
>     [email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/stir
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 26 May 2018 20:31:01 +0000

I am all ears for guidance from experts whether it should be a normative reference and if so whether it being a non-WG item would cause any issues.

Thanks,
Tolga

From: stir <[email-masked]> On Behalf Of Keith Drage
Sent: Saturday, May 26, 2018 9:23 AM
To: [email-masked]
Subject: Re: [stir] draft-asveren-stir-p-charge-info

I note that your document currently contains no normative references. I would have assumed that draft-york would have to be a normative reference (it is currently missing from the reference section, and there is apparently no section entitled normative references), and therefore at the very least, this would have to be an approved downref from a standards track document to an informational document.

regards

Keith

Thanks,
Tolga

From: stir <[email-masked]><mailto:[email-masked]> On Behalf Of Keith Drage
Sent: Thursday, May 24, 2018 10:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] draft-asveren-stir-p-charge-info

"

regards

Keith

I’m actually curious?

—

Richard Shockey

Shockey Consulting LLC

richard<at>shockey.us

PSTN +1 703-593-2683

Thanks,
Tolga

stir mailing list

stir mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 May 2018 17:55:28 +0000

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

Thanks,
Tolga

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 28 May 2018 20:35:38 +0000

Please see inline for comments/answers.

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

Hi,

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?
[TOLGA] draft-asveren-stir-p-charge-info does not add new functionality for P-Charge-Info per se. It merely add verification capability for it.

Q2: You should describe in what kind of environments this is needed.
[TOLGA]Noted and will add it in the next version -among other things-.

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.
[TOLGA]thanks for the feedback. I don’t have a problem with that and would follow what is required from procedures perspective and will change it to “Informational”.

        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.
 [TOLGA] I think this depends on what is meant by “supporting pci PASSPortT”. An entity can still remove it if it is aware of “pci” but does not support it in terms of adding/verifying pci Identity. OTOH, an entity completely unaware of “pci” wouldn’t be able to do so. I will add some text about this.

              Is there something missing between “or” and “by”?
[TOLGA] “added or by” => “added or modified by”

Regards,

Christer

Thanks,
Tolga

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 May 2018 08:04:26 +0000

Hi,

True, but it is not documenting existing implementations anymore.

I was also going to comment on the fact that you don’t reference the york draft, but Keith already brought that up :)

        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.
 [TOLGA] I think this depends on what is meant by “supporting pci PASSPortT”. An entity can still remove it if it is aware of “pci” but does not support it in terms of adding/verifying pci Identity. OTOH, an entity completely unaware of “pci” wouldn’t be able to do so.

Correct – that is the use-case I had in mind.

Regards,

Christer