On 26. 05. 20 18:00, Roy Arends wrote: > >> On 26 May 2020, at 16:06, Petr Špaček <[email protected]> wrote: >> >> On 02. 05. 20 16:09, Roy Arends wrote: >>> Hi, >>> >>> Ed and I just submitted a new version of our private-use TLD draft. >>> >>> https://www.ietf.org/id/draft-arends-private-use-tld-01.txt >>> >>> This draft has substantial more information than the first draft. It >>> explains that a private-use namespace does not exist, why it is needed, and >>> how a namespace aligned with the user-assigned alpha-2 code elements in the >>> ISO-3166-1 standard can be used as private-use namespace. >> >> I think this is clever hack and should be documented, thank you! > > Any time, thanks! > >> Personally I'm bit torn because I've spent my whole professional career >> explaining people how bad idea it is to use non-delegated/non-unique names >> so I would really like to people from overusing this... >> >> Would you be willing to add at least one paragraph with caution? Something >> along lines "private TLD should be used as _option of last resort_", or more >> verbose "these special TLDs should be used only when other options, e.g. >> private subtree under a properly delegated name, were considered and >> refused." > > I’m not sure about ranking different methods of deployment as each has its > own little idiosyncrasies that may be useful to the deployment scenario. > > How about I add a section that details the additional complexities and adds > caution in using this specific method, such as “Using a private use top level > domain is not ‘more secure’ or ‘more private’ than using a public domain; it > requires additional complexity in resolving and signing, etc, etc” > > Does that work for you?
Yes, that would be ideal, I just did not want to delve into details so much. Basically the message I wanted to convey is "usually it is less work and more robust to use a delegated name instead of your own TLD". If you want to add longer explanation I'm happy to review it! -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
