[stir] AD Review: draft-ietf-stir-oob

[Adam Roach <[e-mail]>]

This is my AD review for draft-ietf-stir-oob. I will be requesting
that it be put in IETF last call shortly.

Thanks to everyone involved for taking the work to work out and document the
thinking so far on an out-of-band mechanism. I have no substantive comments,
and only a small number of editorial suggestions, below. Please treat 
these as
any other IETF last call comments.

/a


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

§1:

 >  do use SIP do not always carry SIP signaling end-to-end. Xalls from

Nit: "Calls"

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

§1:

 >  This specification therefore builds on the PASSporT [RFC8225]
 >  mechanism and the work of [RFC8224] to define a way that a PASSporT
 >  object created in the originating network of a call can reach the
 >  terminating network even when it cannot be carried end-to-end in-band
 >  in the call signaling.  This relies on a new service defined in this
 >  document called a Call Placement Service (CPS) that permits the
 >  PASSporT object to be stored during call processing and retrieved for
 >  verification purposes.

This is still phrased as if the remainder of this document is a complete
specification of mechanism rather than the more limited scope described
in the paragraph that follows it. Perhaps:

s/This specification/The techniques described in this document/
s/define a way/describe a way/

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

§5.2:

 >  A call originates with an enterprise PBX that has both Internet
 >  access and a built-in gateway to the PSTN, which communicates through
 >  traditional telephone signaling protocols.  The PBX immediately drops
 >  the call to the PSTN

The colloquial use of "drops" in this context can be confusing. (I had to
re-read to ensure that it meant "routes" rather than "aborts"). Perhaps
"...immediately routes the call..."

The same comment applies to §5.3.

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

§5.3:

 >  If
 >  so, it can retrieve the PASSporT and, when it creates a SIP INVITE
 >  for this call, add a corresponding Identity header per [RFC8224].

Nit: "...Identity header field..."

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

§5.5:

 >  the SIP call with an Identity header.  As a fallback in case the call

Nit: "...Identity header field."

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

§6.2:

 >  This requires the retargeting entity to generated
 >  encrypted PASSporTs that show a secure chain of diversion:

Nit: "...to generate..."

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

§8.1:

 >  or more credentials that can be used to sign for that identity, be it
 >  a domain or a telephone number or something other identifier.  For

Nit: "...or some other identifier."

 >  Identity header field value of the SIP request - though SIP would
 >  carry cleartext version rather than an encrypted version sent to the

Nit: "...carry a cleartext..."

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

§8.3:

 >  could receive a call with an Identity header, extract a PASSporT from
 >  the Identity header, and store that PASSporT at a CPS.

Nit: "...Identity header field..." (twice)

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

§9:

 >  As an rough example, we show a Call Placement Service implementation

Nit: "...a rough..."

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

§10:

 >  This document does not prescribe any single way to do service
 >  discovery for a CPS; it is envisioned that initial deployments will
 >  provision the location of the CPS at the AS and VS.

Nit: expand the acronyms "AS" and "VS".