Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
On Fri, Apr 29, 2022 at 10:54:13PM +0200, Benno Overeinder wrote: > Mukund, > > On 29/04/2022 22:27, Mukund Sivaraman wrote: > > > > > > This is indeed how the DNSOP chairs see it and have guided the (new set > > > of) > > > authors in this way. We have also asked Haisheng to contact the > > > secretariat > > > to correct the situation as we cannot withdraw individual drafts or change > > > status. > > > > With the way this is worded, is it accepted practice for the names of > > authors of a document to be removed to make way for another set of > > authors? > > No, certainly not. If you interpret it that way, I have chosen the wrong > words. > > What I meant to say is that we made suggestions or try to guide the > practical procedure for changing the status of document to indicate that it > is not an active document. OK, I think I have misunderstood the last 2 emails in this thread. > The broader discussion of whether it is an accepted practice or not was not > the subject of my answer to the list. As I understand there is a discussion > in the IESG now, and with the email thread on the list and Brian's draft, > https://datatracker.ietf.org/doc/html/draft-carpenter-whats-an-author-02, we > can make progress to better define the process and provide guidance to > authors and IETF participants. That sounds good. I browsed through Carpenter's draft. Section 7 in it is about how to fork (which is welcome), and it sounds reasonable. Mukund signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Doodle poll for DNSOP WG interim on 24 or 25 May
Dear DNSOP WG, We are planning our first DNSOP WG interim meeting for 2022 on May 24 or 25. The DNSOP WG chairs are contacting the authors of two drafts that can be put on the agenda. Details to follow. Please fill in the Doodle poll to settle on a day and time: - https://doodle.com/meeting/participate/id/e0RyVkXb The options for the time slots are CEST/EDT/PDT friendly. We will close the Doodle poll at the end of Thursday, 5 May. Best regards, Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
Mukund, On 29/04/2022 22:27, Mukund Sivaraman wrote: This is indeed how the DNSOP chairs see it and have guided the (new set of) authors in this way. We have also asked Haisheng to contact the secretariat to correct the situation as we cannot withdraw individual drafts or change status. With the way this is worded, is it accepted practice for the names of authors of a document to be removed to make way for another set of authors? No, certainly not. If you interpret it that way, I have chosen the wrong words. What I meant to say is that we made suggestions or try to guide the practical procedure for changing the status of document to indicate that it is not an active document. The broader discussion of whether it is an accepted practice or not was not the subject of my answer to the list. As I understand there is a discussion in the IESG now, and with the email thread on the list and Brian's draft, https://datatracker.ietf.org/doc/html/draft-carpenter-whats-an-author-02, we can make progress to better define the process and provide guidance to authors and IETF participants. -- Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
On Fri, Apr 29, 2022 at 10:05:10PM +0200, Benno Overeinder wrote: > Hi Lars, WG, > > On 29/04/2022 12:54, Lars Eggert wrote: > > On 2022-4-29, at 0:30, Cindy Morgan wrote: > > > The rest of this is a bit of a tangle, and I've referred it to the IESG > > > for further guidance on what steps the Secretariat should take next. > > > > the IESG is reviewing what has happened. > > > > (My personal first impression is that this might be a case where a > > contributor intended to revive an expired document by a different set of > > authors, and was unsure how to best go about this.) > > This is indeed how the DNSOP chairs see it and have guided the (new set of) > authors in this way. We have also asked Haisheng to contact the secretariat > to correct the situation as we cannot withdraw individual drafts or change > status. With the way this is worded, is it accepted practice for the names of authors of a document to be removed to make way for another set of authors? The fact that the document is expired or not is a different matter. The copyright notice on the document says: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. By way of this, by removing the names of authors, isn't the copyright notice attributed to the (original) document authors also being removed? Clearly the text is not copyright of the new authors in this document: https://www.ietf.org/archive/id/draft-hsyu-message-fragments-00.txt Mukund signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
Hi Lars, WG, On 29/04/2022 12:54, Lars Eggert wrote: On 2022-4-29, at 0:30, Cindy Morgan wrote: The rest of this is a bit of a tangle, and I've referred it to the IESG for further guidance on what steps the Secretariat should take next. the IESG is reviewing what has happened. (My personal first impression is that this might be a case where a contributor intended to revive an expired document by a different set of authors, and was unsure how to best go about this.) This is indeed how the DNSOP chairs see it and have guided the (new set of) authors in this way. We have also asked Haisheng to contact the secretariat to correct the situation as we cannot withdraw individual drafts or change status. Regards, -- Benno DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
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) Haisheng Yu(Johnson)h...@biigroup.cn On 4/29/2022 05:46，Mukund Sivaraman wrote： Hi CindyOn Thu, Apr 28, 2022 at 02:30:07PM -0700, Cindy Morgan wrote: Hi Mukand, When the Secretariat got the request to review the replacement relationship suggested by haisheng yu, I checked and saw that "haisheng yu" was listed as an author on both draft-hsyu-message-fragments and draft-muks-dnsop-message-fragments, and so I approved the replaced-by information. The rest of this is a bit of a tangle, and I've referred it to the IESG for further guidance on what steps the Secretariat should take next.Thank you for responding. I don't think you did anything wrong. You tookaction based on what was seen. This name change has taken a peculiartrail:(1) The original draft is "draft-muks-dns-message-fragments" (note the-dns- vs. -dnsop-) where "haisheng yu" is not an author. It is from2015-07-20.https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/(2) "draft-muks-dnsop-message-fragments" (the -dnsop- variant) wasuploaded on 2022-04-20. This lists "haisheng yu" as an additional authoralong with the old authors. Can you check who uploaded it? I didn't,although it contains the name "-muks-".https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/(3) The latest version was uploaded on 2022-04-28, which has removed theoriginal authors from the 2015-07-20 document.https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/ Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
Hi, On 2022-4-29, at 0:30, Cindy Morgan wrote: > The rest of this is a bit of a tangle, and I've referred it to the IESG for > further guidance on what steps the Secretariat should take next. the IESG is reviewing what has happened. (My personal first impression is that this might be a case where a contributor intended to revive an expired document by a different set of authors, and was unsure how to best go about this.) Thanks, Lars signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
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 signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
