[stir] Shepherd Review of draft-ietf-stir-servprovider-oob-24

[Ben Campbell <[e-mail]>]

Hi,

I’ve just reviewed draft-ietf-stir-servprovider-oob-24 as part of the process of doing the shepherd writeup, and have a few comments and questions.

# Substantive:

## General:

Is informational still the right status? It has quite a bit of normative language. There’s nothing inherently wrong about that, but that sort of thing does tend to trigger AD questions. If “Informational” is still correct, I suggest adding a paragraph somewhere early in the document to say why we think that and why we still included 2119/8174 language. IMO, this would be helpful both to head off questions in advance and to help end-readers understand how to think about the document. (I suspect the fact that 8816 is informative is a lot of the reason, but there are work-arounds if we think this document effectively defines a standard.)

## §4, 2nd paragraph: “ The advantage to signing with STIR certificates is that they contain a "TNAuthList" value indicating the telephone network resources that a service provider controls.

Unfortunately, here, the biggest current deployment of STIR mostly still just puts SPCs in TnAuthList. The ATIS approach effectively allows any SPC token holder to attest to any phone number.

# Editorial:

## Abstract, last sentence: If we stick with “Informational”, I suggest saying “This document describes” rather than “This specification defines”.

## §1, 2nd paragraph:
###  “… and who thus will learn about the parties to communication independently…”

The phrase is a little hard to follow. I suggest “...Who thus will independently learn about the parties to communication…"

### “… like mobile networks …”

Given that modern mobile networks tend to use SIP, they might not be the best target to pick on. Maybe something like “such as legacy non-IP telephone networks”

### “ where in-band transmission of STIR may not be feasible:

s/STIR/PASSporTs

## §10, first paragraph: "This draft mitigates those concerns by making the CPS one of the two parties to call setup”

In the gateway case, there may be more than 2 parties to the call setup. I suggest changing “one of the two parties” to “one of the parties”.