> On Apr 8, 2026, at 3:40 AM, Petr Špaček <[email protected]> wrote:
> 
> 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 ...'.
> 


I think that approach would work.

At the moment I feel like there is some repetition and inconsistency between 
the two drafts.  For example regarding the DE flag bit.  draft-deleg calls it 
the “DELEG” flag and draft-delext calls it the “Delegation Extensions” flag.  
Both have ASCII art.  I’d suggest putting the details into just one draft and 
have the other say “The DE flag is carried in the OPT RR as described in 
$first-draft”.

I suggest taking a look at ADT flag along the same lines as well.

DW

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to