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

[Russ Housley <[e-mail]>]

Adam:

These look straightforward to fix.  Do you want to proceed with IETF Last Call in parallel?

Russ


> On Sep 3, 2019, at 1:18 AM, Adam Roach <[e-mail]> wrote:
> 
> 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".
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir