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.

As far as I can tell, the authors resubmitted the draft as WG document and
that was it. I would like to hear the assessment of the draft from the authors.

There is also unanswered question from Paul Wouters:

> 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

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]

Reply via email to