On 07. 04. 26 11:29, Roy Arends wrote:
On 6 Apr 2026, at 19:40, Wessels, Duane
<[email protected]> wrote:
Dear DNSOP,
As you may already know, the DELEG working group is embarking on requesting
early allocation of code points for the DELEG protocol.
draft-ietf-dnsop-delext also comes into play here because that draft describes
a new subcategory of RR types called Delegation Types. The DELEG RR type will
be allocated from this new range.
The area directors for DELEG and DNSOP want to make sure that
draft-ietf-dnsop-delext is stable before proceeding with the early allocation
request to IANA. This is an important step in the process for any early
allocation request. Accordingly, Brian and I are here to ask DNSOP and its
chairs to make an assessment on the status and stability of
draft-ietf-dnsop-delext so that we can proceed.
Thanks for this.
I would like to clarify that the methodology and protocol elements are intended
to be an exact match with draft-ietf-deleg. Any discrepancies will be addressed
by the authors of draft-ietf-dnsop-delext to ensure alignment. The sole purpose
of draft-ietf-dnsop-delext is to define and allocate a range of RR types, one
of which will be assigned to the DELEG RR.
One point to note is that we should avoid having two documents defining the
same protocol elements in the long term. Guidance would be appreciated on how
best to converge these into a single document, or alternatively, to clearly
separate responsibilities. For instance, one document defining the protocol
elements and another specifying the DELEG/DELEGPARAM RR types and their RDATA.
Cleanest option would be to specify range in DELEG. Assuming we are
still not allowed to do that, I would just specify protocol in DELEG
protocol and minimize draft-ietf-dnsop-delext to just say something like
'behavior applicable to DELEG RRtype is now extended to range ...'.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
