Re: [stir] AD Review: draft-ietf-stir-passport-shaken-04

[Chris Wendt <[e-mail]>]

Hi Adam, 

Thanks for the review, i have addressed all of your comments in a forthcoming 05 draft release.

-Chris

> On Oct 19, 2018, at 7:54 PM, Adam Roach <[e-mail]> wrote:
> 
> This is my AD review for draft-ietf-stir-passport-shaken-04.  I have a handful
> of comments below that I'd like to see addressed prior to asking the IESG to
> consider the document. Please treat them as you would any other last-call
> comments. I have no blocking comments, and will be placing the document
> in IETF last call shortly.
> 
> Thanks to everyone who worked on this document.
> 
> /a
> 
> ---------------------------------------------------------------------------
> 
> Abstract:
> 
> >  Industry Solutions) and the SIP Forum IP-NNI Joint Task Force.  These
> 
> Please expand "IP-NNI".
> 
> >  coming from both STIR participating originating communications as
> 
> Please expand "STIR" on first use.
> 
> Also, as "STIR-participating" is a compound adjective, it needs to be
> hyphenated. With the expansion, this would look like:
> 
>    coming from both SIP Telephony Identity Revisited (STIR)-participating
>    originating communications as...
> 
> ---------------------------------------------------------------------------
> 
> §1:
> 
> >  The SHAKEN [ATIS-1000074] specification defines a framework for using
> >  STIR protocols including PASSporT [RFC8225], SIP Authenticated
> ...
> >  current telephone network contains both VoIP and TDM/SS7 originated
> 
> For the purposes of acronym expansion, the Abstract is not treated as part of
> the document. Please expand SHAKEN, STIR, PASSporT, VoIP, TDM, and SS7 on
> first use.  See https://www.rfc-editor.org/materials/abbrev.expansion.txt for
> more details.
> 
> ---------------------------------------------------------------------------
> 
> §2:
> 
> >  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> >  document are to be interpreted as described in [RFC2119].
> 
> Please update to the boilerplate in RFC 8174.
> 
> ---------------------------------------------------------------------------
> 
> §3:
> 
> >  and represents the service provider receiving a call from a non
> >  PASSporT or STI supporting telephone gateway.
> 
> Nit: "...from a non-PASSporT- and non-STI-supporting telephone gateway."
> 
> ---------------------------------------------------------------------------
> 
> §4:
> 
> >  can be one of the following three values, 'A', 'B', or 'C' as defined
> >  in [ATIS-1000074].
> 
> Nit: "...one of the following three values: 'A', 'B',..."
> 
> ---------------------------------------------------------------------------
> 
> §5:
> 
> >  opaque identifier corresponding to the service provider-initiated
> >  calls themselves,
> 
> Nit: "...service-provider-initiated calls..."
> 
> >  documents that more precisely guide it's usage in real deployments.
> 
> Nit: "...its usage..."
> 
> ---------------------------------------------------------------------------
> 
> §6:
> 
> >     "orig":{"tn":"12155551212"},
> 
> The NANPA has reserved the range "555-0100" through "555-0199" in all area
> codes for fictitious use. The number used in this example is a valid number
> allocated for directory assistance use. Consider using "12155550121" (or some
> similarly reserved number for this example. See
> https://www.nationalnanpa.com/number_resource_info/555_numbers.html for more
> information.
> 
> ---------------------------------------------------------------------------
> 
> §7:
> 
> >  [RFC3261] aligned with the use of the identity header defined in
> 
> Nit: "...identity header field..."
> 
> 
>