On Fri, Mar 11, 2022 at 01:49:41AM -0800, Paul Vixie wrote: > Tim Wicinski wrote on 2022-03-11 01:38: > > ... for several years now I have > > felt those two need to be republished with all > > the updated text from the many updates (28 for 1035, 18 for 1034) in new > > documents. This does not include any other > > changes, and it feels like a thankless task. > not just thankless but useless. a correctness preserving rewrite, from > scratch, should be performed every few decades. (we're overdue.) a goal > should be readability which will require NOT reusing most of the original > text or including the updated text. we often didn't know or otherwise > misstated our implications. every material statement made by any prior DNS > specification or update to the specification should be enumerated and > checked off as its then-modern meaning is incorporated. > > i'll offer to join a team to work on this when i eventually retire, if it > hasn't been recently enough done at that time. so, i think, should other > guilty parties.
Some years back, I tried to begin a "squash" document along these lines, but like many other drafts, it was abandoned. When discussing it with colleagues, most had the opinion that this was a wasteful endeavour. Opinions were that it was too much work, that the landscape was changing too much and a new document would become obsolete too. https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-squash-01 I've assisted new DNS developers in the course of my work. From this experience, there should be an effort to make a new modern document as the details of correctly implementing DNS are scattered in too many RFCs and drafts. It is daunting for a newcomer to navigate unless they have read all the RFCs prior and know where to find what. As an example, 2 weeks ago I was asked by a colleage why when parsing a CNAME response a resolver discards the links of the CNAME chain except for the link with the owner name it queried for (unless it can validate the other links). The way this requirement is written in the corresponding RFC, it's difficult to search and find the appropriate RFC. If someone is implementing DNS functionality afresh, they may even miss such requirements because they're all over the place. Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
