I just want to point out, that I am certainly not overthinking this with my implementors hat. The RFC and code-point puts pressure on the DNS vendors to actually implement this „because there’s RFC“. The whole reason for standardization is that there’s interoperatibility between the implementations - and just giving the code points without implementing this hardly fulfills that requirement.
Sure, I can ignore the new GOST code point in BIND 9, but that becomes harder when either one of the other open source implementations or one of the big DNS silos will actually do the implementation. So, it’s definitively not „just giving the code point“, it has implications for some of us. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 18 Jun 2020, at 17:36, Jim Reid <j...@rfc1035.com> wrote: > > I think we’re over-thinking this. Just issue new code point(s) for the new > algorithm(s) and be done with it. > > IMO there’s no need for the WG or the IETF to make any statements about the > suitability of the underlying crypto used for optional signing and > validation. That’s largely a matter for those who use these algorithms. > Higher-level concerns about the crypto’s suitability should only come into > play whenever an algorithm is a MUST/SHOULD recommendation in a > standards-track RFC. > > Maybe we need an RFC6895-like process for maintaining this IANA registry, > like we have for RRtype codes? >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
