On Tue, Aug 23, 2022 at 11:52 AM Paul Hoffman <paul.hoff...@icann.org> wrote:
> Thanks again for all the discussion; it is helping the document. You can > see from the diff at < > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-17> that we > have tightened the language, particularly around what is display format and > what is wire format. More comments are of course welcome. > One group of thoughts that might be helpful, is about the nature of any "protocol" (for lack of a better term) that is added to the registry. It may be helpful to add some things along the lines of: - Any registered "thing" needs to be completely independent of the DNS (at least for any namespace underneath .alt itself). - Any registered "thing" should ensure its identifier (e.g "foo.alt") is not the only method of confirming the namespace and protocol are what are intended. - E.g. independent of the registered name "foo.alt", some shared information can be used to allow multiple users of the "thing" to know that "foo" means what they think it means. - The example from DNS would be the set of pre-configured IP addresses of the ICANN Root Name Servers. All DNS systems assume they are in the same ICANN name space, but are also able to validate that by communicating with the Root Servers. - Any registered "thing" is encouraged to preserve its identifier as part of its domain names, but is also encouraged to not attach or associate any data with the topmost two labels of domain names (e.g. "foo.alt" would not have any sort of data associated with either "foo.alt" or "alt" wtihin the system of "thing" itself.) This ensures any leaks outside of "thing" can safely be identified and ignored by any other similar registered system which is aware of the "alt" registry and scheme. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
