Re: [stir] Getting PASSPORT Published

[Mary Barnes <[e-mail]>]

I personally don't see it adds any value to make the proposed change given
that you're proposing to change the status of the draft to Informational
(which I'm fine with).  We've had this discussion many, many times with one
of those threads triggering this draft:
https://tools.ietf.org/html/draft-peterson-informational-normativity-01
 We could start it again, if you don't agree with what that draft says -
that will give us a good topic for open mic discussions at the plenary next
month ;)

I also thought IESG had published a statement on this, but I can only find
the one with regards to the references and not the terms:
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
.

In my view, what we have now is sufficient given the change in status.
The document highlights a potential privacy concern and suggests how it
could be addressed by service providers that deem it to be a concern.

Regards,
Mary

On Thu, Feb 21, 2019 at 4:24 PM Adam Roach <[e-mail]> wrote:

> [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
>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>