On Aug 8, 2022, at 3:16 AM, Independent Submissions Editor (Eliot Lear) <[email protected]> wrote:
> The community has more choices than Christian indicated. One is that “You” > carve out some space for namespaces like GNS, just as George suggested. > Warren's draft seems to comport itself to contours of that concept, which is > why I came here. Also, the authors of draft-schanzen-gns seem to think that > it is close to something they could use to be willing to engage here. It > also seems to me that such a draft is, roughly speaking, in line with the > general principles of SSAC-113, as Andrew alluded, even if that document had > the different goal of enabling privately or locally scoped namespaces. Of > course, there may be other approaches. draft-ietf-dnsop-alt-tld and SAC113 would give the authors of the draft you are considering an easy method to do the type of naming they talk about in their draft. So would using a TLD that is exceptionally unlikely to be allocated in the global DNS, such as: #gns =gns (or, for a more marketing spin) gns! These are all perfectly valid names; they just happen not to use the LDH pattern that people expect from the global DNS. If the GNS team indeed wants to make it clear that their naming is not part of the global DNS, simply rooting their names in one of these TLDs (available now) or one of the ones from draft-ietf-dnsop-alt-tld or SAC113 (possibly available in the future) would avoid all of the interoperability problems they create in the draft. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
