Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

[Scott Kitterman <[e-mail]>]

On November 11, 2019 3:54:09 PM UTC, John Levine <[e-mail]> wrote:
>In article
><CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=[e-mail]>
>you write:
>>Just to be clear: The policy for changes to that registry is "Expert
>>Review", but since the action that put it there was a document with
>IETF
>>consensus, I'm pretty hesitant about just approving this change based
>on a
>>formal request.  I'd rather at least see some consensus discussion
>about
>>it, or even better, a revision/update to RFC8601.
>
>Hey, wait, Expert Review is supposed to be considerably looser than RFC
>Required.
>
>Since there's no danger of running out of token names, I'd encourage
>you to accept new ptypes if they have a clear spec and a plausible use
>case.  In this instance, I think the description in the I-D is OK, but
>for the use case I would like some evidence that someone, somewhere is
>implementing it and doing something with the result.

I've had feature requests to include both s= Service Type (due to tlsrpt) and t= Flags (particularly t=y (testing)).  Since they are attributes of the DNS record and not the signature, I think the proposed dns ptype would be appropriate.

I plan to implement it in dkimpy and expose the values in dkimpy-milter.  I'd like some indication that it'll move forward first.

I think we can adequately define the ptype in the registry.  I don't think we need to have a spec.  For the rest of Ale's draft, I'm not convinced a registry entry is enough to document the proposed usage. (Speaking as alternate DE - msk is the primary though, so this is not an attempt to override him).

msk: What do you think about the idea of approving the new ptype now (so I can file requests for the above, well defined, DKIM result reporting enhancements)?

Scott K