[stir] Re: Call for adoption: draft-barnes-stir-8588bis-01 (Ends 2025-11-26)

[Pierce Gorman <[e-mail]>]

I reviewed (browsed) earlier this morning.  I noticed it says UUID is required for origid claim.  There was a big argument one day in one of the IP-NNI meetings where this point was debated because not every implementation was using UUID, and the IP-NNI came down squarely on the side of not requiring UUID. FWIW, I was in the camp that said it should be UUID but we were over-ruled.

The only point I'm trying to make is differences in the (interpretation of?) ATIS standards and IETF standards on the same claim are likely to be unhelpful.  And, does this imply Service Providers should now start failing verification of calls that formerly were ok with strings in origid like "This is the origid"?

Beyond that, I didn't see what was different in the bis versus 8588.  Is there a simple "this is what is different in the bis" description I'm overlooking?

Thanks in advance for help.

Pierce

CONFIDENTIAL
-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: Wednesday, November 5, 2025 5:24 PM
To: [e-mail]
Cc: [e-mail]
Subject: [stir] Re: Call for adoption: draft-barnes-stir-8588bis-01 (Ends 2025-11-26)

As discussed in the STIR session earlier today, please read this document as you would for WG Last Call.  We want to do the call for adoption and the WG Last Call concurrently.

For the STIR WG Chairs,
  Russ


On 05.11.2025 17:59, Russ Housley via Datatracker wrote:
> Subject: Call for adoption: draft-barnes-stir-8588bis-01  (Ends
> 2025-11-26)
>
> This message starts a 3-week Call for Adoption for this document.
>
> Abstract:
>    This document extends the Personal Assertion Token (PASSporT), which
>    is a token object that conveys cryptographically signed information
>    about the participants involved in communications.  The extension is
>    defined based on the "Signature-based Handling of Asserted
>    information using toKENs (SHAKEN)" specification by the ATIS/SIP
>    Forum IP-NNI Task Group.  It provides both (1) a specific set of
>    levels of confidence in the correctness of the originating identity
>    of a call originated in a SIP-based telephone network as well as (2)
>    an identifier that allows the Service Provider (SP) to uniquely
>    identify the origin of the call within its network.  This document
>    obsoletes RFC8588.
>
> File can be retrieved from:
> https://datatracker.ietf.org/doc/draft-barnes-stir-8588bis/
>
> Please reply to this message keeping [e-mail] in copy by
> indicating whether you support or not the adoption of this draft as a
> WG document.
> Comments to motivate your preference are highly appreciated.
>
> Authors, and WG participants in general, are reminded of the
> Intellectual Property Rights (IPR) disclosure obligations described in
> BCP 79 [2].
> Appropriate IPR disclosures required for full conformance with the
> provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are
> aware of any.
> Sanctions available for application to violators of IETF IPR Policy
> can be found at [3].
>
> Thank you.
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
>
>
> _______________________________________________
> stir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]