[stir] Getting PASSPORT Published

[Adam Roach <[e-mail]>]

[as area director]

tl;dr: I'd like to propose publishing SHAKEN as Informational instead of 
Standards Track, and tweaking the Privacy Considerations section. 
Details below.


The draft-ietf-stir-passport-shaken document still has a DISCUSS 
remaining on it from IESG evaluation:

> I would like to discuss the privacy properties of origids. As I read
> this text, it does not actually require them to be unlinkable or that
> it not be possible to determine whether two ids represent the same
> person behind the origid generator, and I believe it should do so.
> Practically implementing that may require an ID that is longer than a
> UUID.


While it's true that this behavior is defined in the ATIS document, 
publication of an IETF Proposed Standard carries with it the explicit 
indication that the IETF as a whole (including the IESG during their 
evaluation) thinks the approach being described is a Good Idea. In this 
particular case, the fact that the underlying mechanism does not 
inherently provide unlinkability for the underlying identifiers has been 
identified as problematic.

At the same time, I'll note that the primary reason for this document to 
exist is to populate two IANA registries. Both of these registries are 
"Specification Required," which doesn't require the publication of a 
Standards Track document.

An acceptable path to address this situation would be to instead publish 
draft-ietf-stir-passport-shaken as Informational, and to tighten up the 
privacy considerations slightly. I believe this could be achieved with a 
small change to the final sentence of section 10; we would replace:

>    If the operator of an element is concerned about the
>    correlation of 'origid' values, the element could be configured to
>    use a unique 'origid' value per call in such a way that the operator
>    can associate those 'origid' values to the correct element when doing
>    lookups in their backend systems.

With:

>    Absent a compelling reason not to do so, operators should configure 
> their
>    network elements to use a unique and externally unlinkable 'origid' 
> value
>    per call in such a way that the operator can associate those 'origid'
>    values to the correct element when doing lookups in their backend 
> systems.


Does this sound like a reasonable path forward?

/a