Hi Haisheng Yu / Johnson On Fri, Apr 29, 2022 at 11:05:34AM +0800, Haisheng Yu wrote: > Hi， Mukund, > This is Johnson， I'm very sorry to cause you so much trouble. > > I think the draft of draft-muks-dns-message-fragments that you > submitted to the IETF is quite interesting and shows the importance of > dns packet fragmentation in the DNS query process. It's a pity to see > that this draft has expired. I want to see if it can be reactivated in > the working group. Push the work forward and maybe it will become an > RFC. > > Linjian Song and Shane Kerr are both my former colleagues. I > talked to them all about this draft and got some of their suggestions > for it. > > Here's Shane Kerr's thoughts on this draft, which I think is a > good suggestion. > “I think it probably makes more sense to understand the > behavior of DNS over QUIC: > > https://blog.apnic.net/2022/03/29/a-first-look-at-dns-over-quic/ > It should resolve the fragmentation issue, as well as > working through most middleboxes, and providing authentication and > encryption.” > Because I haven't contacted you before, and the draft was > accidentally submitted by me, I asked Benno Overeinder to revoke the > draft I submitted. But because this is a an individual submission, > Benno Overeinder can't revoke the draft. So I try to submit a draft to > cover the previous drafts. > I'm very sorry for causing so much trouble to you because of > my mistakes. I hope we can keep this work going together. > > Haisheng Yu (Johnson) If the author names were removed and it was uploaded to the datatracker accidentally, I take your word for it. Internet drafts are asking for review and comments. In most cases, they are meant to be changed over time until they reach a final satisfactory form. Discussions usually happen in topic working groups so that everyone interested in that topic can comment. All the original authors of this draft have changed affiliation to companies since the draft was written. If there are changes to be made, you are welcome to join in. I suggest that you describe them or write them as diffs and send them either to the dnsop@ mailing list for comments, or to *all* the authors so we can review them and comment on them. We'll discuss them, so please feel encouraged to do it. If the changes are sufficiently large, existing authors would want to add you as an author or even take over as the primary author if you start to steer the document. You wouldn't even have to ask or make the name changes yourself. Your participation should focus mainly on improving the content. I'll provide a story as an example. Several years ago, in the BIND team we received numerous bug reports within a short period in the Response Policy Zones (RPZ) implementation. It was indeed broken in several ways. The implementation was magical at that time in that we didn't fully understand how it worked. I looked for references and found an old ISC technote (formatted very similar to an IETF internet draft) about RPZ which was an early specification of the feature. The BIND code had been updated to do other things though. The BIND ARM (manual) was another reference, but it was very terse and not written as a specification. Another source of RPZ documentation was a Zytrax DNS book with numerous examples. It was clear that the technote was obsolete, and because Evan Hunt and I were handling the RPZ bugs at that time, I contacted Paul Vixie (the existing author) on whether I could update it to match the BIND implementation. Paul responded that he would like to shepherd it himself. The main reason was that RPZ had spawned an industry with several parties dependent on a common standard of "RPZ feeds" - the specification had to be carefully maintained (and of course, documented). In the BIND project, we went about fixing bugs using the existing code and whatever we could gather as references. Brian Conry contributed numerous new system tests to check things worked. Sometime later, Paul and Vernon Schryver updated and published an internet draft on datatracker.ietf.org to update the RPZ specification to match the BIND implementation. It eventually became "draft-vixie-dnsop-dns-rpz". I reviewed draft revisions against the BIND implementation for correctness and provided a list of changes. There was a RPZ BoF meeting which we attended in Seoul and discussed ideas. The draft didn't become an RFC due to other reasons, but I'm happy with the state of the draft in that it accurately specifies RPZ. Mukund
Attachment:
signature.asc
Description: PGP signature
