[stir] Proposal to change servprovider-oob to Standards Track (was Re: Shepherd Review of draft-ietf-stir-servprovider-oob-24)

(+ Murray)

Hello STIR wg:

Please see below that Jon proposed making this draft standards track instead of informational. This will create a normative downref to RFC 8816. As an individual, I think that is the right choice since there is some important security and security-adjacent guidance in the draft.

Does anyone object to that change? If so, please speak up really soon now.

Thanks!

Ben.

> On Oct 23, 2023, at 3:51 PM, Peterson, Jon <Jon.Peterson=40transunion.com@dmarc.ietf.org> wrote:
> 
>  
> Thanks for the read-through Ben. A few responses inline below.
>  
> Jon Peterson
> TransUnion
>  
> # 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.)
>  
> I’m happy advancing it as PS, and having a downref to RFC8816. I think we went back and forth about that at one point. The respin will have this as std. 
>  
> ## §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.
>  
> I thought “telephone network resources” was vague enough that it does not entail TNs as such, or at least, that was the intention. Any CPS that cared to check could consult the relevant industry databases or analytics to make a determination whether a carrier with a given SPC should actually be uploading a PASSporT from that “orig.” Or, SHAKEN-style, it could just take everything and leave it for terminating-side analytics to make the similar determination. That seems more like a matter of local policy than bits on the wire.
>  
> # Editorial:
>  
> ## Abstract, last sentence: If we stick with “Informational”, I suggest saying “This document describes” rather than “This specification defines”.
>  
> Again, since we’re pushing this as PS, I’ll just stick with the current language.
> .
> ## §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…"
>  
> Agreed that isn’t great. How about: “and thus who will necessarily know the parties communicating”.
>  
> ### “… 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”
>  
> Okay.
>  
> ### “ where in-band transmission of STIR may not be feasible:
>  
> s/STIR/PASSporTs
>  
> Okay.
>  
> ## §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”.
>  
> Okay, done. Thanks again!
>  
>  
> _______________________________________________
> stir mailing list
> stir@ietf.org <mailto:stir@ietf.org>
> https://www.ietf.org/mailman/listinfo/stir