While it is not written down that it is frozen you are required to give enough information to implement it with the expectation that it will be implemented by multiple vendors.
Once implemented you then have to deal with backwards compatibility with existing implementations if changes are made. Mixing I-D/RFC and template mechanisms for assigning and publishing type points is fraught with danger as you then run into issues we have been seeing here. You actually thought about making ZONEMD future proof which was good and should have provided enough flexibility. -- Mark Andrews > On 12 May 2021, at 02:16, Wessels, Duane <dwess...@verisign.com> wrote: > > > >>> On May 10, 2021, at 5:44 PM, Mark Andrews <ma...@isc.org> wrote: >>> >>> >>>> On 11 May 2021, at 09:20, Paul Hoffman <paul.hoff...@icann.org> wrote: >>> >>> On May 10, 2021, at 4:14 PM, Mark Andrews <ma...@isc.org> wrote: >>>> Actually, the process problem is that record format keeps changing AFTER >>>> the code point has been assigned and the record format THEORETICALLY been >>>> FIXED. >>> >>> Mark makes an excellent point, one that people in the DNS world routinely >>> forget. >> >> Just for reference ZONEMD switched two fields between >> draft-wessels-dns-zone-digest-05.txt and >> RFC 8976. "Digest Type | Reserved” -> "Scheme | Hash Algorithm”. This >> resulted in BIND rejecting >> zones with ZONEMD records using SHA-512 digests (digest field has the wrong >> length for Digest Type 1). >> Renaming fields is fine. Reordering/repurposing non reserved isn’t as it >> breaks stuff. Now we are >> making BIND compatible with RFC 8976 but we should never have been put in >> this position. > > Mark, > > Thank you for quickly making this change in BIND. You are correct that > the case of ZONEMD the interpretation of fields did change, although the > wire format did not. > > You've made the point a few times that code point allocation freezes the > record format (not just in wire format but also presentation and meaning). > When I went through the RR type allocation process this was not evident > to me. Is this (theoretical?) "policy" written down somewhere? RFC 6895 > doesn't seem to say anything like that. > > DW > > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
