--On Saturday, May 17, 2025 14:00 -0700 Benjamin Kaduk
<kaduk@xxxxxxx> wrote:
> On Sat, May 17, 2025 at 03:05:17PM -0400, John C Klensin wrote:
>>
>>
>> --On Saturday, May 17, 2025 12:08 -0400 Donald Eastlake
>> <d3e3e3@xxxxxxxxx> wrote:
>>
>> > The DNS protocol itself is binary clean. Bytes in labels can have
>> > any value. Of course this may cause problems in applications /
>> > user interface code or the like. And it is true that leading
>> > underscores and such like may, by convention be reserved. And
>> > "host" names are nominally supposed to start with a letter or
>> > digits and have only letters, digits, and hyphens. etc.
>> >
>> > The labels are length value encoded on the wire and there are
>> > only 6 bits for length so labels are limited to 63 bytes. The
>> > label of length zero is reserved for the label of the root node.
>> > Labels only "end in a period" in their usual string
>> > representation, not on the wire.
>>
>> +1
>> A few suggestions...
>> If one is looking for definitions of domain name syntax to
>> reference in a document, RFC 1035 is a better reference than 1034.
>> It defines a "preferred name syntax" that lies at the core of most
>> applications use of the DNS. It is also worth at least looking at
>> Section 6.1.3.5 of RFC 1123 and Section 11 of RFC 2181 to get a
>> better understanding. While a particular application is free to
>> define its own rules for labels, that should be done (as those
>> documents suggest) clearly and with great care.
>>
>> For example, if there are going to be dependencies on, or
>> recommendations about RFC 7542, whatever syntax rules are adopted
>> should be examined to determine whether UTF-8 labels are allowed or
>> whether IDNA ("xn--...") are needed or more appropriate.
>
> This draft says names are stored as A-Labels.
Sorry.. missed that.
>> Independent of the above, I thought there was an explicit agreement
>> among the IAB, IETF and assorted other parties to not add new
>> application uses or conventions to the ARPA. tree. The "control"
>> of ARPA. by the IAB mentioned in the I-D is, IIR, just the
>> mechanism to enforce that agreement, not an invitation to add
>> additional second-level domains. That issue probably should have
>> been more closely examined by the IAB and the community when
>> "eap-noob.arpa." was adopted but the fact that we have created one
>> such second-level domain does not imply that more of them,
>> especially for the same general set of protocols, are appropriate.
>> Indeed, it may suggest otherwise.
>
> Hmm, I do not really remember something so formal as you indicate
> here. In fact, I don't remember much at all relating to .arpa, but
> I do remember having the impression that there were some scenarios
> in which it could be used.
There were, IIR, a small set of tussles over control/ supervision of
ARPA and INT (and possibly one or two others) when ICANN came into
being. With the main use of ARPA by then being the in-addr.arpa
subdomain, possibilities were IAB, the RIRs, or ICANN. IAB got the
short straw for ARPA and INT stayed with IANA with a general
understanding that added registrations in both were to be sparse and
that neither would be turned into a general-use TLD. That agreement
and associated guidelines are more or less documented in RFC 3172. I
reviewed the registry [1] after reading your note and there are
significantly more second-level domains than I expected to find, so
part of my earlier comment probably falls into the "horse left the
barn" category. At the same time, having multiple second-level
names associated with the same protocol or protocol category is
probably not a good design decision. Too late to take eap-noob out
and turn it into noob.eap.arpa, but I'd encourage the WG, the IESG,
and the IAB to think carefully about whether there is any chance of
additional EAP-related identifier groups being needed and, if there
is even a slight possibility, moving toward an eap.arpa with a
subdomain for this application ("realm"?) and the potential for
additional subdomains as needed.
best,
john
[1] https://www.iana.org/domains/arpa
>
> -Ben
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
