I may have missed the consensus on this. I don’t believe the final DNS entry is hugely important as it pertains to TLSRPT on its own, as long as it extends from the target domain. So, today we have "_smtp-tlsrpt.example.com", but it seems like to get more in line with a proper IANA registration, we should alter this slightly. Is there any reason to not go forward with “_smtp._tls.example.com” or “_smtp._tlsrpt.example.com”?
-- Alex Brotman Sr. Engineer, Anti-Abuse Comcast From: Uta [mailto:[email protected]] On Behalf Of Phillip Hallam-Baker Sent: Thursday, March 22, 2018 12:09 PM To: Alexey Melnikov <[email protected]> Cc: [email protected]; [email protected]; IETF Discussion Mailing List <[email protected]>; [email protected] Subject: Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17 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 <[email protected]<mailto:[email protected]>> 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/
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
