Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

[Mukund Sivaraman <[e-mail]>]

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