Hi,

On 24-06-17 17:45, Ondřej Caletka wrote:
Hello,

Dne 24.6.2017 v 15:25 Dick Franks napsal(a):
I beg to disagree.

In each case,

       CDS 0 0 0 0

       CDNSKEY 0 3 0 0

the final "0" is a conventional token representing a zero-length key
field. In neither case is it an attempt to specify a single octet key value.

I believe this has been discussed between 04 and 06 versions of the
draft in this thread:

https://mailarchive.ietf.org/arch/msg/dnsop/PsRIQOtd1bxFSEEm9lfv0WaHKeE >
The result that made it to the RFC is that there should be indeed one
byte with value of 00 in the Digest/Public key field instead of no data
at all.

To be precise: We actually agreed that there should be *one field with the value of 0* instead of no data at all.

This avoids the need of defining new format and updating all the
deployed software. It's not only about parsers of the wire format but
also about zone file parsers, that would need an update as the single
zero is not conformant with currently defined presentation format of
CDS/CDNSKEY RRs.

I raised the specific issue because the to be RFC 8078 was going to change the CDS and CDNSKEY RDATA format from a fixed length RDATA to a variable length: In case of the DELETE operation, the Digest in presentation format was omitted.

While I agree with Paul in that thread that we should use all zeros for the DELETE operation, I believe it was an oversight that the proper encodings (hexadecimal, base64) should be used.

So to me this errata is valid.

Best regards,
  Matthijs


I believe changing RRdata format just for this one purpose would add an
unnecessary complexity.

--
Best regards,
Ondřej Caletka



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to