Subject: Re: [stir] Call For Adoption of draft-peterson-stir-servprovider-oob

From: Sean Turner <[email-masked]>
Date: Thu, 6 Aug 2020 00:46:38 -0400

I support adoption. It’s a concise 8-pager (albeit missing security considerations :).

spt

> On Jul 31, 2020, at 11:35, Russ Housley <[email-masked]> wrote:
> 
> Please take a look at draft-peterson-stir-servprovider-oob. Please indicate whether you support adoption of this document by the STIR WG.  Please respond before 23 August 2020.  If you support adoption, please indicate whether you would review or implement.
> 
> This document can be found in the datatracker at https://datatracker.ietf.org/doc/draft-peterson-stir-servprovider-oob/
> 
> Russ & Robert
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Aug 2020 15:44:04 -0500

+1 on both points.

Ben.

> On Jul 31, 2020, at 10:56 AM, Mary Barnes <[email-masked]> wrote:
> 
> I support the adoption and am willing to review.
> 
> Regards,
> Mary. 
> 
> On Fri, Jul 31, 2020 at 10:36 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> This document can be found in the datatracker at https://datatracker.ietf.org/doc/draft-peterson-stir-servprovider-oob/ <https://datatracker.ietf.org/doc/draft-peterson-stir-servprovider-oob/>
> 
> Russ & Robert
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Russ Housley <[email-masked]>
Date: Sun, 23 Aug 2020 17:03:08 -0400

Few people have spoken, but everyone that did speak was supportive.  So, this document is adopted by the STIR WG as the staring point for protocol work on the out-of-band conveyance of PASSporTs by service providers.

Russ

> On Jul 31, 2020, at 11:35 AM, Russ Housley <[email-masked]> wrote:
>

---

From: Piotr Gregor <[email-masked]>
Date: Mon, 24 Aug 2020 11:59:55 +0100

I am also reviewing this document (and draft-ietf-stir-oob), cause it's
relevant to software defined telecoms, like us (SignalWire).
Trying to figure out how businesses like us best fit into this (how they
can provide STIR-Shaken to their clients) and willing to help!

all the best,
Piotr

-- 
  *|*  Ask me about SignalWire Work <https://signalwire.com/products/work>, 
our new digital office alternative.

---

From: Piotr Gregor <[email-masked]>
Date: Tue, 25 Aug 2020 01:08:48 +0100

I believe there is an error in draft-ietf-stir-oob-07, here in section 9 it
is said that call originates for destination 2.222.555.2222
but then 2.222.222.2222 appears in places I highlighted:

9 <https://tools.ietf.org/html/draft-ietf-stir-oob-07#section-9>.
Example HTTPS Interface to the CPS
(...)
   Assume that an authentication service has created the following
   PASSporT for a call to the telephone number 2.222.555.2222

(...)
   Through some discovery mechanism (see Section 10
<https://tools.ietf.org/html/draft-ietf-stir-oob-07#section-10>), the
authentication
   service discovers the network location of a web service that acts as
   the CPS for 2.222.555.2222.

(...)
   Having concluded the numbered steps in Section 8.1
<https://tools.ietf.org/html/draft-ietf-stir-oob-07#section-8.1>,
including
   acquiring any token (per Section 6.1
<https://tools.ietf.org/html/draft-ietf-stir-oob-07#section-6.1>)
needed to store the PASSporT at
   the CPS, the authentication service then stores the encrypted
   PASSporT:

Rescorla & Peterson    Expires September 10, 2020              [Page 20]

------------------------------

  <https://tools.ietf.org/html/draft-ietf-stir-oob-07#page-21>Internet-Draft
             STIR Out-of-Band                  March 2020

      POST /cps/2.222.555.2222/ppts HTTP/1.1
      Host: cps.example.com
(...)

   The web service assigns a new location for this encrypted PASSporT in
   the collection, returning a 201 OK with the location of
   /cps/2.222.222.2222/ppts/ppt1.

^^^^^^^^^^^^^^^^^^^^^^

->>>>>>>>>>>>> should be /cps/2.222.555.2222/ppts/ppt1

Now the authentication service can
   place the call, which may be signaled by various protocols.  Once the
   call arrives at the terminating side, a verification service contacts
   its CPS to ask for the set of incoming calls for its telephone number
   (2.222.222.2222).

^^^^^^^^^^^^^^^^^^^^^^^^^^^

->>>>>>>>>>>>> should be 2.222.555.2222

GET /cps/2.222.555.2222/ppts Host: cps.example.com This returns to the
verification service a list of the PASSporTs currently in the collection,
which currently consists of only /cps/2.222.222.2222/ppts/ppt1.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

->>>>>>>>>>>>> should be /cps/2.222.555.2222/ppts/ppt1

  The verification service then sends a
   new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields:

(...)

cheers,

Piotr