Subject: [stir] certificates: short-lived or status

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 15 Mar 2017 20:33:08 +0000

In reaction to the IESG review, and as well, to our own general sense that we're still not ready to mandate any particular direction, we ended up pulling the real-time status check of OCSP out of the last version of stir-certificates. Figuring out how we want to manage certificate freshness, especially in light of certificates assigned to telephone numbers, is probably the last bit about the core STIR work, before we go on to extensions and so forth, that we need to tackle.

I'd like to spend some meeting time talking about two approaches, as well as any better ideas anybody comes up with for this. The first is roughly what was in the stir-certificates document previously, which is now captured in:

https://tools.ietf.org/html/draft-ietf-stir-certificates-ocsp-00

The other is an approach based on short-lived certificates, which would likely rely on ACME or something similar. I've mocked up a discussion draft for that:

https://tools.ietf.org/html/draft-peterson-stir-certificates-shortlived-00

... though it is still fairly content-free at the moment.

I think reviewing what we've done with stir-certs and these two approaches warrants some face-time discussion. Thoughts here on the list beforehand are welcome too.

Thanks,

Jon Peterson
Neustar, Inc.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Mar 2017 19:37:41 -0400

I would note that "freshness" is but one aspect of a certificate that you
need OCSP for.  The far more common use in the WebPKI is when the CA simply
screws up.

In any case, to recap the experience from the Web PKI, the trade-off space
has basically the following shape:

1. Do a live query [draft-ietf-stir-certificates-ocsp]
2. Make something with a short lifetime
2.a. Mandatory OCSP stapling
2.b. Short-lived certificates [draft-peterson-stir-certificates-shortlived]

The trade-off is basically between the sender/signer having to do queries
(to refresh OCSP or get a new cert) and recipient/verifier having to do
queries (to fetch OCSP).  (2.a) is a bad deal unless you have some legacy
need to use OCSP; otherwise it's just bloat relative to (2.b).

If you ask web people, you're likely to get a pretty strong preference for
(2), i.e., putting the burden on the sender, because (a) it's more
predictable and (b) it's offline with respect to call time, and thus much
less performance sensitive.  The web started out with (1) and it has turned
out to be totally unworkable, because the CAs can't operate OCSP servers
that are good enough to avoid seriously degrading the performance of
browsing experience.

The main push-back we get from server operators about (2) is that it
requires outbound connections from web servers -- load and downtime never
come up as issues.  Outbound connections shouldn't be an issue for STIR
signers, since they're likely to be making outbound connections all the
time anyway.  Even if not, it's a simple firewall rule to write to let out
connections to your CA.

--Richard

On Wed, Mar 15, 2017 at 4:33 PM, Peterson, Jon <[email-masked]>
wrote:

>
> In reaction to the IESG review, and as well, to our own general sense that
> we're still not ready to mandate any particular direction, we ended up
> pulling the real-time status check of OCSP out of the last version of
> stir-certificates. Figuring out how we want to manage certificate
> freshness, especially in light of certificates assigned to telephone
> numbers, is probably the last bit about the core STIR work, before we go on
> to extensions and so forth, that we need to tackle.
>
> I'd like to spend some meeting time talking about two approaches, as well
> as any better ideas anybody comes up with for this. The first is roughly
> what was in the stir-certificates document previously, which is now
> captured in:
>
> The other is an approach based on short-lived certificates, which would
> likely rely on ACME or something similar. I've mocked up a discussion draft
> for that:
>
> I think reviewing what we've done with stir-certs and these two approaches
> warrants some face-time discussion. Thoughts here on the list beforehand
> are welcome too.
>
> Thanks,
>
> Jon Peterson
> Neustar, Inc.
>
>
>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 15 Mar 2017 23:42:36 +0000

I do not see the need for short lived certs for a TN call setup service

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Mar 15, 2017, at 7:37 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

I would note that "freshness" is but one aspect of a certificate that you need OCSP for.  The far more common use in the WebPKI is when the CA simply screws up.

In any case, to recap the experience from the Web PKI, the trade-off space has basically the following shape:

The trade-off is basically between the sender/signer having to do queries (to refresh OCSP or get a new cert) and recipient/verifier having to do queries (to fetch OCSP).  (2.a) is a bad deal unless you have some legacy need to use OCSP; otherwise it's just bloat relative to (2.b).

If you ask web people, you're likely to get a pretty strong preference for (2), i.e., putting the burden on the sender, because (a) it's more predictable and (b) it's offline with respect to call time, and thus much less performance sensitive.  The web started out with (1) and it has turned out to be totally unworkable, because the CAs can't operate OCSP servers that are good enough to avoid seriously degrading the performance of browsing experience.

The main push-back we get from server operators about (2) is that it requires outbound connections from web servers -- load and downtime never come up as issues.  Outbound connections shouldn't be an issue for STIR signers, since they're likely to be making outbound connections all the time anyway.  Even if not, it's a simple firewall rule to write to let out connections to your CA.

--Richard

On Wed, Mar 15, 2017 at 4:33 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

https://tools.ietf.org/html/draft-ietf-stir-certificates-ocsp-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dstir-2Dcertificates-2Docsp-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=RPvZjXuy_wnl9IwmrPj4Y6KsACaINE1guHTRyh5Eki4&e=>

https://tools.ietf.org/html/draft-peterson-stir-certificates-shortlived-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpeterson-2Dstir-2Dcertificates-2Dshortlived-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=NdnWiTSJii5i3j1NaEkrF56dhUYNP0kFJXCtqr_sPdg&e=>

Thanks,

Jon Peterson
Neustar, Inc.

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=xBPq9-hmuqFdGVD3GNxGolnkagSy3snLiWRrLaXOzX4&e=>

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=xBPq9-hmuqFdGVD3GNxGolnkagSy3snLiWRrLaXOzX4&e=

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Mar 2017 19:47:48 -0400

So you're trusting the folks issuing certificates to be perfectly reliable,
and service providers never to use a cert for a number that's been ported
away?

On Wed, Mar 15, 2017 at 7:42 PM, DOLLY, MARTIN C <[email-masked]> wrote:

> *Martin C. Dolly*
> Cell: +1.609.903.3360
> Email: [email-masked] <[email-masked]>*
>
>
>
> On Mar 15, 2017, at 7:37 PM, Richard Barnes <[email-masked]> wrote:
>
>> In reaction to the IESG review, and as well, to our own general sense
>> that we're still not ready to mandate any particular direction, we ended up
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dstir-2Dcertificates-2Docsp-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=RPvZjXuy_wnl9IwmrPj4Y6KsACaINE1guHTRyh5Eki4&e=>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpeterson-2Dstir-2Dcertificates-2Dshortlived-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=NdnWiTSJii5i3j1NaEkrF56dhUYNP0kFJXCtqr_sPdg&e=>
>>
>> I think reviewing what we've done with stir-certs and these two
>> approaches warrants some face-time discussion. Thoughts here on the list
>> beforehand are welcome too.
>>
>> Thanks,
>>
>> Jon Peterson
>> Neustar, Inc.
>>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=xBPq9-hmuqFdGVD3GNxGolnkagSy3snLiWRrLaXOzX4&e=>
>>
>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_stir&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=
> G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_
> OhohUYV7gr17x0&s=xBPq9-hmuqFdGVD3GNxGolnkagSy3snLiWRrLaXOzX4&e=
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2017 23:48:39 +0000

> time anyway.  Even if not, it's a simple firewall rule to write to let out

(2) also helps for privacy reasons. (1) would mean the
callee sending a cleartext OCSP query containing the
callers number. (In some cases.)

And FWIW, I'm not sure how the trade-offs between (2a)
and (2b) would apply in the case of stir. (2a) would
be more bytes unless (2b) has one more intermediate CA
cert for some reason, but that could happen so the
trade-offs would need a bit of exploring. The RP may
also have an easier time with (2a) as it is maybe
easier to insist on a fresh stapled OCSP response than
it is to decide when a still-valid cert is too old.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2017 23:49:52 +0000

> callers number. (In some cases.)

Sorry - s/containing/identifying/ in the above is more
correct.

S.

---

From: Richard Shockey <[email-masked]>
Date: Wed, 15 Mar 2017 20:26:20 -0400

With limited exceptions I don’t see issuing certificates for individual TN’s at all..at least not for the immediate future.

— 

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 Richard Barnes <[email-masked]>
Date: Wednesday, March 15, 2017 at 7:47 PM
To: "DOLLY, MARTIN C" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Peterson, Jon" <[email-masked]>
Subject: Re: [stir] certificates: short-lived or status

So you're trusting the folks issuing certificates to be perfectly reliable, and service providers never to use a cert for a number that's been ported away?

Martin C. Dolly

AT&T

Cell: +1.609.903.3360

Email: [email-masked]

--Richard

On Wed, Mar 15, 2017 at 4:33 PM, Peterson, Jon <[email-masked]> wrote:

Thanks,

Jon Peterson

Neustar, Inc.

_______________________________________________ stir mailing list [email-masked] https://www.ietf.org/mailman/listinfo/stir

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 15 Mar 2017 23:58:59 +0000

That's why we have governance and the threat of punishment by the Feds

Martin C. Dolly

On Mar 15, 2017, at 7:47 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 15, 2017 at 7:42 PM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:
I do not see the need for short lived certs for a TN call setup service

Martin C. Dolly

--Richard

Thanks,

Jon Peterson
Neustar, Inc.

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 15 Mar 2017 23:13:53 -0400

What threat of punishment? There is none in the proposed rules.

On Mar 15, 2017 7:58 PM, "DOLLY, MARTIN C" <[email-masked]> wrote:

Martin C. Dolly

AT&T

Cell: +1.609.903.3360

Email: [email-masked]

On Mar 15, 2017, at 7:47 PM, Richard Barnes <[email-masked]> wrote:

On Wed, Mar 15, 2017 at 7:42 PM, DOLLY, MARTIN C
<[email-masked]> wrote:

Martin C. Dolly

AT&T

Cell: +1.609.903.3360

Email: [email-masked]

The trade-off is basically between the sender/signer having to do queries (to refresh OCSP or get a new cert) and recipient/verifier having to do queries (to fetch OCSP).  (2.a) is a bad deal unless you have some legacy need to use
OCSP; otherwise it's just bloat relative to (2.b).

If you ask web people, you're likely to get a pretty strong preference for (2), i.e., putting the burden on the sender, because (a) it's more predictable and (b) it's offline with respect to call time, and thus much less performance
sensitive.  The web started out with (1) and it has turned out to be totally unworkable, because the CAs can't operate OCSP servers that are good enough to avoid seriously degrading the performance of browsing experience.

The main push-back we get from server operators about (2) is that it requires outbound connections from web servers -- load and downtime never come up as issues.  Outbound connections shouldn't be an issue for STIR signers, since they're
likely to be making outbound connections all the time anyway.  Even if not, it's a simple firewall rule to write to let out connections to your CA.

--Richard

On Wed, Mar 15, 2017 at 4:33 PM, Peterson, Jon
<[email-masked]> wrote:

In reaction to the IESG review, and as well, to our own general sense that we're still not ready to mandate any particular direction, we ended up pulling the real-time status check of OCSP out of the last version of stir-certificates. Figuring out how
we want to manage certificate freshness, especially in light of certificates assigned to telephone numbers, is probably the last bit about the core STIR work, before we go on to extensions and so forth, that we need to tackle.

Thanks,

Jon Peterson

Neustar, Inc.

stir mailing list

[email-masked]

stir mailing list

[email-masked]

---

From: Alex Bobotek <[email-masked]>
Date: Wed, 15 Mar 2017 23:07:02 -0700

It would be a mistake to consider even all _national_ authorities trustworthy.  Analytics systems will need to consider issuer chain as well as individual certificate reputation trustworthiness.  There are too many stories of bought passports.

Regards,

Alex

From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Wednesday, March 15, 2017 5:26 PM
To: Richard Barnes <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: [email-masked]; Peterson, Jon <[email-masked]>
Subject: Re: [stir] certificates: short-lived or status

—

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 Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 15, 2017 at 7:47 PM
To: "DOLLY, MARTIN C" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Peterson, Jon" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] certificates: short-lived or status

Thanks,

Jon Peterson
Neustar, Inc.

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

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 16 Mar 2017 09:03:20 -0400

Given the proclivity to use Bond themes,
it might be useful to take stock of what
seems like Never Say Die and the STIR/
SHAKEN gambit.

It is rather clear that given what is occurring
in different jurisdictions around the world,
STIR/SHAKEN has a chance of somewhere
close to zero to be implemented on even a
limited scale.  Talking about "governance"
seems delusional.

The only thing the FCC is doing is proposing
allowing regulated carriers to block traffic
at their customer's request. That is the best
possible outcome after what will be a long
comment and reply proceeding period, if not
additional litigation on multiple causes of
action.

Given the overwhelming negative responses
about STIR/SHAKEN in the CRTC proceeding
comment period ending yesterday - especially
by Canadian industry, it seems highly unlikely
they are going to be implementing anything
along the lines of STIR/SHAKEN.
https://services.crtc.gc.ca/pub/ListeInterventionList/Default-Defaut.aspx?

And then there is the rest of the world whose
views seem to range between outright rejection and
pursuit of probabilistic rather than ancient deterministic
(e.g., STIR/SHAKEN) solutions.  That was the
reaction at the ETSI CYBER#9 meeting a few
weeks ago.  It is also reflected in the latest draft
on the subject into the upcoming ITU-T SG17 meeting.
Indeed, there are multiple other inputs - especially
by Alibaba - that point to a shift to probabilistic
options.  Indeed, that is where the innovations
are occurring - and the FCC NPRM/NOI fortuitously
allows for them.  Canada being a progressive nation
seems likely to encourage them as well.

The emerging enhanced/extensible versions of
CNAM that facilitate probabilistic solutions are
where the focus seems likely.  (I'm still waiting
for the ATIS' version to be make publicly available.
It seems like don't want anyone so see it.)

--tony

ps. STIR/SHAKEN looks rather like the old CCITT
clinging onto the ancient past. :-)

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 16 Mar 2017 13:48:30 +0000

+1

From: Alex Bobotek [mailto:[email-masked]]
Sent: March 16, 2017 1:07 AM
To: Richard Shockey <[email-masked]>; Richard Barnes <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: [email-masked]; Peterson, Jon <[email-masked]>
Subject: Re: [stir] certificates: short-lived or status

Regards,

Alex

From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Wednesday, March 15, 2017 5:26 PM
To: Richard Barnes <[email-masked]<mailto:[email-masked]>>; DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Peterson, Jon <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] certificates: short-lived or status

—

Richard Shockey

Shockey Consulting LLC

richard<at>shockey.us

PSTN +1 703-593-2683

Thanks,

Jon Peterson
Neustar, Inc.

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Richard Shockey <[email-masked]>
Date: Thu, 16 Mar 2017 10:34:26 -0400

+1 as well.   No one is going to lack for work in the months and years ahead. But we have to start somewhere.

From: stir <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Thursday, March 16, 2017 at 9:48 AM
To: Alex Bobotek <[email-masked]>, Richard Shockey <[email-masked]>, Richard Barnes <[email-masked]>, "DOLLY, MARTIN C" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Peterson, Jon" <[email-masked]>
Subject: Re: [stir] certificates: short-lived or status

+1 

Regards,

Alex

 

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

Martin C. Dolly

AT&T

Cell: +1.609.903.3360

Email: [email-masked]

--Richard

Thanks,

Jon Peterson

Neustar, Inc.

---

From: Richard Shockey <[email-masked]>
Date: Thu, 16 Mar 2017 10:44:49 -0400

FYI folks the actual comments on CRTC Consultation 2017-4 are here.

There are only 26 or so.  I haven’t read through all of them but most of the comments are pretty predictable.  “Its early etc.” “Its premature.”  

In any event the CRTC has done a fine job here laying out some of the ongoing issues and they should be congratulated for doing so.  The current FCC proceeding ( CG Docket No 17-59 ) is an excellent first start on the Do Not Originate list but IMHO is by no means the last word on the subject. We haven’t heard from our British friends but I have confidence we will eventually. ☺ 

CIRA which is .CA is already lining up to act as the Trust Anchor in Canada.

https://services.crtc.gc.ca/pub/ListeInterventionList/Default-Defaut.aspx?en=2017-4&dt=i&lang=e&S=C&PA=C&PT=NC&PST=A

As for ITU-T,  I’m just not going there. 

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Tony Rutkowski <[email-masked]>
Organization: Yaana Technologies
Reply-To: <[email-masked]>
Date: Thursday, March 16, 2017 at 9:03 AM
To: Alex Bobotek <[email-masked]>, Richard Shockey <[email-masked]>, Richard Barnes <[email-masked]>, "DOLLY, MARTIN C" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Peterson, Jon" <[email-masked]>
Subject: [stir] reality check

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 16 Mar 2017 10:54:48 -0400

Hi Rich,

This has been worked for the past 20+ years.
It's not exactly a clean slate, and PKI vendors
have about 30 years of experience trying to
make things work.  The engage daily in the
CA/B Forum.

There are innumerable venues, providers,
solution vendors, legal systems, agencies,
users, and interested parties involved.  The
FCC alone has been at this for the past 15
years, and the ITU even longer.  Not sure
who the "we" is here. :-)

-t

---

From: Richard Shockey <[email-masked]>
Date: Thu, 16 Mar 2017 10:51:04 -0400

We haven’t seen the final Report and Order yet. ☺  Stay tuned.

Yes Virginia there really are protocol police.  See 47 U.S.C Title II  ( as frequently amended)   

See also 

http://laws-lois.justice.gc.ca/eng/acts/T-3.4/

From: stir <[email-masked]> on behalf of Tony Rutkowski <[email-masked]>
Date: Wednesday, March 15, 2017 at 11:13 PM
To: "DOLLY, MARTIN C" <[email-masked]>
Cc: Richard Barnes <[email-masked]>, <[email-masked]>, "Peterson, Jon" <[email-masked]>
Subject: Re: [stir] certificates: short-lived or status

Martin C. Dolly

AT&T

Cell: +1.609.903.3360

Email: [email-masked]

Martin C. Dolly

AT&T

Cell: +1.609.903.3360

Email: [email-masked]

--Richard

Thanks,

Jon Peterson

Neustar, Inc.

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 16 Mar 2017 11:02:56 -0400

No Rich, there are few protocols in this
sector that are specified by the FCC, and
it is delusional to think that they are going
to stick yours in 47 CFR. (That's where the
regulations exist.)  If you read the proposed
rules, they only deal with providing authority
for regulated carriers to block.

Maybe you can get Trump to write an Executive
Order for you and we can move to "alt" land. :-)

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 16 Mar 2017 11:04:50 -0400

You may not want to, but the rest of the
world does.  There are relevant treaty
provisions involved, and it is their numbering
standard.  You are already there. :-)  --tony

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 16 Mar 2017 20:40:22 -0400

Commission agenda was just published
with docket designation for NOI/NPRM.

Get your keyboards humming.  ECFS filings
are already being submitted!

-t

---

From: Richard Shockey <[email-masked]>
Date: Thu, 16 Mar 2017 20:53:09 -0400

Indeed. And BTW its pretty easy to file.  You create a letter and address it to.

Ms. Marlene H. Dortch 

Secretary 

Federal Communications Commission 

445 12th Street SW 

Washington, DC 20554 

Add RE the Docket which in this case is CG 17-59 and ta da.  They have a perfectly complicated website but even a IETF protpcol professional can eventually figure it out.  

If it’s a problem I or Henning can certainly help you out. ☺ 

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Tony Rutkowski <[email-masked]>
Organization: Yaana Technologies
Reply-To: <[email-masked]>
Date: Thursday, March 16, 2017 at 8:40 PM
To: "[email-masked]" <[email-masked]>, <[email-masked]>
Subject: [stir] CG Docket No. 17-59

-t