Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

["Peterson, Jon" <[e-mail]>]

>If there were a variety of specifications that used and benefited from
>all that generality, it might be defensible.  But the specifications in
>front of us today merely show added complexity, making concrete analysis
>challenging.

Actually, as I've also already pointed out, our charter constrains us from
working on the non-SIP parts until the "in-band" SIP using protocol is
complete. Which is why, as you say, some years have gone by and the SIP
use case is the only one we are putting forward for an RFC now. That said,
I could point for example to Cullen's rtcweb STIR draft as an example of
the direction the STIR work is going - the lack of discussion of that is
entirely an artifact of the charter here. This modularity is eminently
defensible.

>At that, it's pretty clear that the specifications in front of us are
>still significantly incomplete.  That is, they are insufficient for
>developing a working caller-id authentication service.

We still have some clean-up to do as a result of the last call comments, I
won't argue with that. And yes, we are trying not to drag our feet at this
point but to move aggressively to address something that the industry and
regulators are quite urgently demanding. But the strong claim that you
can't develop a solution based on this work has not been established by
your intervention, and would seem to depend much more on the likelihood of
implementation and deployment than your newcomer's impression of the
wisdom of the architecture. I've seen this code run myself. I hear a lot
of implementers and operators participating in this discussion who do not
share your anxiety on this point. Why do you know better than them?

Jon Peterson
Neustar, Inc.

P.S. 

>Consider that point a bit...  Over 90% of email traffic across the open
>Internet is still spam.  However the mail that comes in with SPF and/or
>DKIM protection constitutes a clean channel of authorized identifiers.
>Mail coming through that channel can be handled differently that mail
>coming through the messy, unauthenticated channel.

Once again, I see no reason to revisit this working group's consensus and
undo our years of work to start over with a technology that you helped
design for email.