Hi Ondrej > On 10 Apr 2026, at 15:07, Ondřej Surý <[email protected]> wrote: > > Hi Duane, > > coincidentally, we talked about this yesterday during our dnsop-chairs call. > > Our current understanding of the draft is that there hasn't been any > discussion > on the draft since the draft was adopted.
Please don’t interpret silence as a lack of interest. > As far as I can tell, the authors resubmitted the draft as WG document and > that was it. Yes, as per your request. But that wasn’t “it". Since the DELEG draft subsequently requested a different code point from their initial draft, we had to update our draft subsequently. Hence the -02. > I would like to hear the assessment of the draft from the authors. Ready for last call. We’ve asked chairs for guidance on how to move forward with the duplicated effort in both DELEG and DELEXT drafts. Please regard this as a gentle nudge ;-). There is nothing controversial here, by the way. I’ve seen no disagreement with the idea of allocating a range. My proposal is either consolidate into one big draft, or have two drafts: one solely relating to the DELEG record RDATA (and the processing of that data), and one solely relating to the delegation protocol extension (the bits needed to make sure it all works: DE, ADT, NSEC/3 on all delegations). > There is also unanswered question from Paul Wouters: Will happily answer these on the list. > >> I support adoption. Some questions I have: >> >> Bit 14 is the Delegation Extension (DE) flag. It indicates to a >> validator that a referral MUST contain an NSEC or NSEC3 record to prove >> presence or absence of types for the delegated name. >> >> Is it really meant that an NSEC(3) record must be returned along with >> the actual present new RRtype ? I assume this just needs to be rephrased >> better. Likely what is meant is that NSEC(3) records for the range(s) of >> new parental records needs to be included along with any actual records. >> (this might cause a huge amplification attack by malicious parents btw) >> >> Note that this also limits the use of these records to DNSSEC signed >> parents. I thought DELEG wanted to work also without DNSSEC in the >> parent? > > I've also looked in the email history and there's also unresolved proposal > about draft-eastlake-rfc6895bis-iana-01 Will have a look at that as well. Thanks Ondrej, Warmly, Roy > > Cheers, > Ondrej > -- > Ondřej Surý (He/Him) > [email protected] > > A gentle nudge is always appreciated if I take a little longer to reply. > >> On 6. 4. 2026, at 20: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. >> >> DW >> >> _______________________________________________ >> DNSOP mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
