I concur, I had come to essentially the same conclusion after discussions with IANA. The registry we were looking for was the one Dave had proposed that has not yet been created.
I can sync with Dave.
It might well be that what we want is a sub registry of the form _smtp._rpt. That way the reporting info for any protocol can be discovered with no need to obtain a per service registration.
On Thu, Mar 22, 2018 at 3:17 PM, Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote:
Hi Phillip,
To followup on the IANA issue from your SecDir review:
On 08/03/2018 19:39, Phillip Hallam-Baker wrote:
>
> Specific issues
>
> The DNS prefix _smtp-tlsrpt is defined. This is not mentioned in the IANA
> considerations. It is a code point being defined in a protocol that is outside
> the scope of UTA and therefore MUST have an IANA assignment and is a DNS code
> point which is shared space and therefore MUST have an assignment.
>
> If no IANA registry exists, one should be created.
After looking at this in more details, I think a new registration in the
registry being created by draft-ietf-dnsop-attrleaf is exactly what you
are asking for. I think registering _smtp-tlsrpt there should be
straightforward. However I don't think this document should be delayed
until after draft-ietf-dnsop-attrleaf is done. So if
draft-ietf-dnsop-attrleaf is taking time, the proposed registration can
be moved to draft-ietf-dnsop-attrleaf itself.
> In general, the approach should be consistent with the following:
>
> [RFC6763] S. Cheshire and M. Krochmal "DNS-Based Service Discovery" RFC 6763
> DOI 10.17487/RFC6763 February 2013
>
> It might well be appropriate to create a separate IANA prefix registry
> 'report'. That is probably easier since this prefix does not fit well with the
> existing ones.
>
> _smtp-tlsrpt._report
I think this is covered by draft-ietf-dnsop-attrleaf.
Best Regards,
Alexey
Website: http://hallambaker.com/
