[DNSOP] Re: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt

[Yorgos Thessalonikefs <[e-mail]>]

Hi Libor, Mark,

Thanks both for the feedback!

On 18/07/2024 10:47, libor.peltan wrote:
> My point was that
> 
> example.com. IN DS49172 13 130 
> e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320
> example.com. IN DS49172 13   2 
> e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320
> 
> is more equivalent (i.e. the change from the first to the second looks 
> safer and more straightforward) than
> 
> example.com. IN DS49172 13 7 
> 02e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320
> example.com. IN DS49172 13 2 
> e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320
> 
> /Libor
> 
> Dne 18. 07. 24 v 10:27 Mark Andrews napsal(a):
>> It would look like a regular DS. The only difference would be that the first byte of the digest would contain the sub type.   This is just internal structure of the digest.
> 
We did consider both options:
- single dry-run algorithm with the real algorithm as part of the digest;
- multiple dry-run algorithms by burning a bit.

and they were both part of the 01 version.

Based on feedback from the IETF114 era 
(https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec-02#name-feedback-from-ietf-114-3) 
the burning a bit way was selected.

The deciding factor was that burning a bit was the only disadvantage of 
the "burning a bit" option. Halving a not so much populated space with 
little prospect of exploding anytime soon as noted in the feedback.

On the other hand, variable length did find some opposition wrt EPP 
constrains.

And I do agree with Libor that as close the dry-run DS resembles the 
real DS the better.
Swapping the dry-run DS with the real DS is the turn-key action that 
should be made confidently.

Best regards,
-- Yorgos