Hi Geoff,
On 5 Feb 2025, at 02:43, Geoff Huston <g...@apnic.net> wrote:
>> On 4 Feb 2025, at 4:49 pm, Kim Davies <kim.dav...@iana.org> wrote:
>>
>> Hi folks,
>>
>> We have published a new version of the draft intended to document the
>> .internal top-level domain.
>> (https://datatracker.ietf.org/doc/draft-davies-internal-tld/)
>>
>> When we presented this work in Dublin, there was a lot of discussion both in
>> the meeting, and subsequently, on whether this should be a work item and
>> also whether the domain merited consideration as a special-use domain name
>> per RFC 6761. I don’t think there was clear consensus on either, but to
>> further the discussion on the latter point, Warren Kumari has provided
>> strawman text to stimulate discussion.
>
> I have discussed this with Warren. Upon reflection I think that its a domain
> name with special use considerations that would largely fit into RFC6761
> critera. The fact that this name "allocation" was the work of ICANN is less
> relevant in this context than the observation than a duly qualified body who
> can make such name allocations has indeed done so merits recording in the
> registry.
By my reading, RFC 6761 and the registry it created are all about how a domain
name should be used, not its provenance. There's no special handling required
by clients, stub resolvers, recursive resolvers, forwarders or authoritative
servers for names in the INTERNAL domain, so on the face of it I don't see a
reason to add the INTERNAL domain to the special use names registry.
There is some special handling required in TLD assignment policies, e.g. in a
future round of new gTLD applications, but that is beyond the scope of RFC 6761
and seems like a matter for ICANN, not the IETF.
The reliable non-existence of a delegation for INTERNAL from the root zone
means that there are particular uses for names the INTERNAL domain that do not
exist with the same sense of reliability as in other TLDs (TLDs that are
delegated today and those that are not). However, that also seems beyond the
scope of RFC 6761.
So I am not sure I follow your logic, above. Perhaps you could expand on your
thinking?
Joe
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
