[stir] Mahesh Jethanandani's Block on charter-ietf-stir-02-00: (with BLOCK and COMMENT)

[Mahesh Jethanandani via Datatracker <[e-mail]>]

Mahesh Jethanandani has entered the following ballot position for
charter-ietf-stir-02-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-stir/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Deb and Roman have already mentioned milestones, so I will not repeat it here.

But the intended status is unspecified for every deliverable. Given that items 2
and 3 both define protocol-visible identifiers and audit mechanisms that
verifiers will need to interoperate on, I'd expect at least those two to be
Standards Track. I had put it along with milestones, but Eric reminded me that
milestones can be changed, so the intended status needs to go into the charter.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A small update to my COMMENT here.

Privacy impact of entity identification isn't discussed:

10 > Operational experience has revealed that while STIR effectively authenticates
11 > the event of a call and the authorization to use a telephone number, it does
12 > not provide a means to identify the entity behind that authorization.
26 > The Working Group will define a means to associate a PASSporT with an
27 > identifier representing the entity holding the right to use an assigned
28 > telephone number.

STIR has historically treated call privacy as a first-order concern — the
outgoing charter carried a dedicated "privacy analysis" milestone, and the
base protocol supports anonymous calls. Attaching an entity identifier that
verifiers can consume is a meaningful new disclosure surface (who gets to see
it, is there an opt-out, does it apply uniformly to individuals and
enterprises). I previously attributed it to RFC 2418 §2.2, but it turns out
that the RFC only talks about security impact. It does not enumerate privacy
separately. However, in the spirit of RFC 6973, it is exactly the kind of impact
a charter should call out. This seems like squarely the case where it applies. A
sentence or two acknowledging the privacy dimension of item 2 would help.

---

Silence on ATIS/SIP Forum liaison, given the governance carve-out:

49 > - Definition of jurisdictional or legal policy topics, including vetting
50 > policies, regulatory requirements, governance, or authorization frameworks. -
51 > Definition of governance requirements for numbering authorities, certificate
52 > authorities, or transparency services.

This carve-out is sensible, but it doesn't say who owns that governance.
In practice, isn't that the ATIS/SIP Forum's STI-GA/STI-PA framework, which is what
actually operationalizes STIR/SHAKEN in the field? Items 2 and 3 both sit
right up against that governance layer (an entity identifier scheme and a
certificate-transparency mechanism are exactly the kind of thing a
certificate-authority governance body would need to adopt or bless). Do you need a
sentence noting the expected coordination with ATIS/SIP Forum?