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. Best regards, Cindy > On Apr 28, 2022, at 12:05 PM, Mukund Sivaraman <muks@xxxxxxxxxx> wrote: > > Hi Donald > > On Thu, Apr 28, 2022 at 02:16:16PM -0400, Donald Eastlake wrote: >> What you describe is completely improper but I'm not sure it's exactly >> accurate. When you said you were "removed" as an author, I assumed that a >> new revision of a draft was posted where you were a first page author for >> version N but not listed as an author for version N+1. That would also be >> improper if there was no effort to consult with you. >> >> But what seems to have happened is that a new draft was created with you >> omitted from the author list and (given the reference to Cindy Morgan in >> the Subject line), the Secretariat was asked to record this new draft as >> replacing the previous draft where you were an author (indeed, the first >> listed author). I think this sort of thing is extremely rare. You could >> certainly ask the Secretariat to reverse the database update so your draft ( >> https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/) is no >> longer shown as being replaced by any other draft. > > A new draft has been created, the contents of which are: > > https://www.ietf.org/archive/id/draft-hsyu-message-fragments-00.txt > > which is largely identical to the original [see diff below], but mainly > authorship has been modified: > > https://www.ietf.org/archive/id/draft-muks-dns-message-fragments-00.txt > > The commit history of the contribution to the original draft is here: > > https://github.com/muks/dnsfragments/commits/master > > The draft appears to have gone from: > > [2015-07-20] https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/ > > (original draft) > > to: > > [2022-04-20] https://datatracker.ietf.org/doc/draft-muks-dnsop-message-fragments/ > > (which included the new author " haisheng yu ", but kept the previous > authors, but with no intimation to us) > > to: > > [2022-04-28] https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/ > > (which deleted the original authors) > > It's not the mechanics, what the new name of the draft is, or what URI > it is at. I am just disappointed we worked on making something and have > disappeared from it, even if it is a copy of the text. It seems > unreasonable, but all things considered (this is not the first time), > I'll shake my head and move on. > > I don't know if my expectation that authorship should be preserved is > misplaced - maybe it is. We already co-assign copyright to the IETF. > > Mukund > > ---- > > The following is a diff between the two drafts to this email, to > illustrate that mainly the authorship information has changed and the > authors who wrote most of it have been removed. > > > > > 5,10c5,8 > < Internet Engineering Task Force M. Sivaraman > < Internet-Draft Internet Systems Consortium > < Intended status: Experimental S. Kerr > < Expires: January 21, 2016 L. Song > < Beijing Internet Institute > < July 20, 2015 > --- >> Internet Engineering Task Force H. Yu >> Internet-Draft Y. Liu >> Intended status: Experimental Guangzhou Genlian >> Expires: 29 October 2022 27 April 2022 > 14c12 > < draft-muks-dns-message-fragments-00 > --- >> draft-hsyu-message-fragments-00 > 32c30 > < Drafts is at http://datatracker.ietf.org/drafts/current/. > --- >> Drafts is at https://datatracker.ietf.org/drafts/current/. > 39c37 > < This Internet-Draft will expire on January 21, 2016. > --- >> This Internet-Draft will expire on 29 October 2022. > 43c41 > < Copyright (c) 2015 IETF Trust and the persons identified as the > --- >> Copyright (c) 2022 IETF Trust and the persons identified as the > 47,52c45,51 > < Provisions Relating to IETF Documents > < (http://trustee.ietf.org/license-info) in effect on the date of > < publication of this document. Please review these documents > < carefully, as they describe your rights and restrictions with respect > < to this document. Code Components extracted from this document must > < include Simplified BSD License text as described in Section 4.e of > --- >> Provisions Relating to IETF Documents (https://trustee.ietf.org/ >> license-info) in effect on the date of publication of this document. >> Please review these documents carefully, as they describe your rights >> and restrictions with respect to this document. Code Components >> extracted from this document must include Revised BSD License text as >> described in Section 4.e of the Trust Legal Provisions and are >> provided without warranty as described in the Revised BSD License. > 56,58d54 > < Sivaraman, et al. Expires January 21, 2016 [Page 1] > < > < Internet-Draft DNS message fragments July 2015 > 59a56,58 >> Yu & Liu Expires 29 October 2022 [Page 1] >> >> Internet-Draft DNS message fragments April 2022 > 61,62d59 > < the Trust Legal Provisions and are provided without warranty as > < described in the Simplified BSD License. > 81c78 > < 4.2.1. Fragment Identifier . . . . . . . . . . . . . . . . . 7 > --- >> 4.2.1. Fragment Identifier . . . . . . . . . . . . . . . . . 8 > 92,93c89 > < Appendix A. Change History (to be removed before publication) . 12 > < Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 > --- >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 > 109a106,108 >> As a UDP datagram is transmitted in a single IP, in theory the size >> of a UDP datagram (including various lower internet layer headers) >> can be as large as 64 KiB. But practically, if the datagram size > 112c111,112 > < Sivaraman, et al. Expires January 21, 2016 [Page 2] > --- >> >> Yu & Liu Expires 29 October 2022 [Page 2] > 114c114 > < Internet-Draft DNS message fragments July 2015 > --- >> Internet-Draft DNS message fragments April 2022 > 117,127c117,127 > < As a UDP datagram is transmitted in a single IP PDU, in theory the > < size of a UDP datagram (including various lower internet layer > < headers) can be as large as 64 KiB. But practically, if the datagram > < size exceeds the path MTU, then the datagram will either be > < fragmented at the IP layer, or worse dropped, by a forwarder. In the > < case of IPv6, DNS packets are fragmented by the sender only. If a > < packet's size exceeds the path MTU, a Packet Too Big (PTB) ICMP > < message will be received by sender without any clue to the sender to > < reply again with a smaller sized message, due to the stateless > < feature of DNS. In addition, IP-level fragmentation caused by large > < DNS response packet will introduce risk of cache poisoning > --- >> exceeds the path MTU, then the datagram will either be fragmented at >> the IP layer, or worse dropped, by a forwarder. In the case of IPv6, >> DNS packets are fragmented by the sender only. If a packet's size >> exceeds the path MTU, it must be fragmented. Except for the first >> fragmented package, other fragmented packages do not include a UDP or >> TCP header, and do not know the port number of the IP package, and >> the subsequent IP slice pack is filtered off. A Packet Too Big (PTB) >> ICMP message will be received by sender without any clue to the >> sender to reply again with a smaller sized message, due to the >> stateless feature of DNS. In addition, IP-level fragmentation caused >> by large DNS response packet will introduce risk of cache poisoning > 168c168 > < Sivaraman, et al. Expires January 21, 2016 [Page 3] > --- >> Yu & Liu Expires 29 October 2022 [Page 3] > 170c170 > < Internet-Draft DNS message fragments July 2015 > --- >> Internet-Draft DNS message fragments April 2022 > 224c224 > < Sivaraman, et al. Expires January 21, 2016 [Page 4] > --- >> Yu & Liu Expires 29 October 2022 [Page 4] > 226c226 > < Internet-Draft DNS message fragments July 2015 > --- >> Internet-Draft DNS message fragments April 2022 > 255,256c255,256 > < The server should use the following sizes for each fragment in the > < sequence in IPv4: > --- >> The server should use the following sizes for each fragment in the >> sequence in IPv4: > 258c258 > < +-------------+---------------------------------+ > --- >> +=============+=================================+ > 260c260 > < +-------------+---------------------------------+ > --- >> +=============+=================================+ > 261a262 >> +-------------+---------------------------------+ > 262a264 >> +-------------+---------------------------------+ > 263a266 >> +-------------+---------------------------------+ > 267,275c270 > < The rationale is that the first packet will always get through, since > < if a 512 octet packet doesn't work, DNS cannot function. We then > < increase to sizes that are likely to get through. 1460 is the 1500 > < octet Ethernet packet size, minus the IP header overhead and enough > < space to support tunneled traffic. 1480 is the 1500 octet Ethernet > < packet size, minus the IP header overhead. [**FIXME**] Why not add > < 1240 here? Shane answers: 1280 is not any kind of limit in IPv4, as > < far as I know. > < > --- >> Table 1 > 276a272,276 >> The rationale is that the first packet will always get through, since >> if a 512 octet packet doesn't work, DNS cannot function. We then >> increase to sizes that are likely to get through. 1460 is the 1500 >> octet Ethernet packet size, minus the IP header overhead and enough >> space to support tunneled traffic. 1480 is the 1500 octet Ethernet > 280c280 > < Sivaraman, et al. Expires January 21, 2016 [Page 5] > --- >> Yu & Liu Expires 29 October 2022 [Page 5] > 282c282 > < Internet-Draft DNS message fragments July 2015 > --- >> Internet-Draft DNS message fragments April 2022 > 285,286c285,287 > < The server should use the following sizes for each packet in the > < sequence in IPv6: > --- >> packet size, minus the IP header overhead. [**FIXME**] Why not add >> 1240 here? Shane answers: 1280 is not any kind of limit in IPv4, as >> far as I know. > 288c289,292 > < +-------------+---------------------------------+ > --- >> The server should use the following sizes for each packet in the >> sequence in IPv6: >> >> +=============+=================================+ > 290c294 > < +-------------+---------------------------------+ > --- >> +=============+=================================+ > 291a296 >> +-------------+---------------------------------+ > 292a298 >> +-------------+---------------------------------+ > 293a300 >> +-------------+---------------------------------+ > 297,298c304,307 > < Like with IPv4, the idea is that the first packet will always get > < through. In this case we use the IPv6-mandated 1280 octets, minus > --- >> Table 2 >> >> Like with IPv4, the idea is that the first packet will always get >> through. In this case we use the IPv6-mandated 1280 octets, minus > 300,302c309,311 > < octet Ethernet packet size, minus the IP header overhead and enough > < space to support tunneled traffic. 1460 is the 1500 octet Ethernet > < packet size, minus the IP header overhead. > --- >> octet Ethernet packet size, minus the IP header overhead and enough >> space to support tunneled traffic. 1460 is the 1500 octet Ethernet >> packet size, minus the IP header overhead. > 306c315 > < o The FRAGMENT option MUST NOT be present in DNS query messages, > --- >> * The FRAGMENT option MUST NOT be present in DNS query messages, > 310c319 > < o In DNS reply messages, the FRAGMENT option MUST NOT be present in > --- >> * In DNS reply messages, the FRAGMENT option MUST NOT be present in > 321c330 > < o More than one FRAGMENT option MUST NOT be present in a DNS reply > --- >> * More than one FRAGMENT option MUST NOT be present in a DNS reply > 323a333,340 >> >> >> >> Yu & Liu Expires 29 October 2022 [Page 6] >> >> Internet-Draft DNS message fragments April 2022 >> >> > 331,340d347 > < > < > < > < > < > < Sivaraman, et al. Expires January 21, 2016 [Page 6] > < > < Internet-Draft DNS message fragments July 2015 > < > < > 382d388 > < 4.2.1. Fragment Identifier > 384,387d389 > < The Fragment Identifier field is represented as an unsigned 8-bit > < integer. The first fragment is identified as 1. Values in the range > < [1,255] can be used to identify the various fragments. Value 0 is > < used for signalling purposes. > 389a392,394 >> Yu & Liu Expires 29 October 2022 [Page 7] >> >> Internet-Draft DNS message fragments April 2022 > 392,394c397 > < Sivaraman, et al. Expires January 21, 2016 [Page 7] > < > < Internet-Draft DNS message fragments July 2015 > --- >> 4.2.1. Fragment Identifier > 395a399,402 >> The Fragment Identifier field is represented as an unsigned 8-bit >> integer. The first fragment is identified as 1. Values in the range >> [1,255] can be used to identify the various fragments. Value 0 is >> used for signalling purposes. > 438,444d444 > < networks where a rate of datagrams can continually be lost due to > < interference and other environmental factors. With larger numbers of > < message fragments, the probability of fragment loss increases. > < > < > < > < > 448c448 > < Sivaraman, et al. Expires January 21, 2016 [Page 8] > --- >> Yu & Liu Expires 29 October 2022 [Page 8] > 450c450 > < Internet-Draft DNS message fragments July 2015 > --- >> Internet-Draft DNS message fragments April 2022 > 452a453,456 >> networks where a rate of datagrams can continually be lost due to >> interference and other environmental factors. With larger numbers of >> message fragments, the probability of fragment loss increases. >> > 476,477d479 > < > < > 486,487d487 > < > < > 495,496d494 > < > < > 500a499 >> 6. EDNS buffer sizes vs. maximum fragmentation sizes > 504,509d502 > < Sivaraman, et al. Expires January 21, 2016 [Page 9] > < > < Internet-Draft DNS message fragments July 2015 > < > < > < 6. EDNS buffer sizes vs. maximum fragmentation sizes > 511,525c504,506 > < Mukund: We need further discussion about the sizes; also an > < upper limit for each *fragment* has to be the client's UDP > < payload size as it is the driver and it alone knows the ultimate > < success/failure of message delivery. So if it sets a maximum > < payload size of 1200, there's no point in trying 1460. Clients > < that support DNS message fragments (and signal support using the > < EDNS option) should adapt their UDP payload size discovery > < algorithm to work with this feature, as the following splits on > < sizes will assist PMTU discovery. > < > < Shane: I think we need to separate the EDNS maximum UDP payload > < size from the maximum fragment size. I think that it is quite > < likely that (for example) we will want to restrict each fragment > < to 1480 bytes, but that the EDNS buffer size might remain at 4 > < kibibytes. > --- >> Yu & Liu Expires 29 October 2022 [Page 9] >> >> Internet-Draft DNS message fragments April 2022 > 527a509,523 >> Mukund Sivaraman: We need further discussion about the sizes; >> also an upper limit for each *fragment* has to be the client's >> UDP payload size as it is the driver and it alone knows the >> ultimate success/failure of message delivery. So if it sets a >> maximum payload size of 1200, there's no point in trying 1460. >> Clients that support DNS message fragments (and signal support >> using the EDNS option) should adapt their UDP payload size >> discovery algorithm to work with this feature, as the following >> splits on sizes will assist PMTU discovery. >> >> Shane Kerr: I think we need to separate the EDNS maximum UDP >> payload size from the maximum fragment size. I think that it is >> quite likely that (for example) we will want to restrict each >> fragment to 1480 bytes, but that the EDNS buffer size might >> remain at 4 kibibytes. > 536,537d531 > < > < > 545,546d538 > < > < > 554,555d545 > < > < > 558,564d547 > < > < > < Sivaraman, et al. Expires January 21, 2016 [Page 10] > < > < Internet-Draft DNS message fragments July 2015 > < > < > 568,569d550 > < > < > 574a556 >> 12. OPT-RR > 577c559,563 > < 12. OPT-RR > --- >> >> Yu & Liu Expires 29 October 2022 [Page 10] >> >> Internet-Draft DNS message fragments April 2022 >> > 582,586c568,570 > < conflicting options (Mukund thinks that we can copy the approach > < in the EDNS specification and use the same rules about > < conflicting OPT-RR that it uses.) > < > < > --- >> conflicting options (Mukund Sivaraman thinks that we can copy >> the approach in the EDNS specification and use the same rules >> about conflicting OPT-RR that it uses.) > 614,620d597 > < > < > < Sivaraman, et al. Expires January 21, 2016 [Page 11] > < > < Internet-Draft DNS message fragments July 2015 > < > < > 623,624c600,602 > < Cookies", draft-ietf-dnsop-cookies-04 (work in progress), > < July 2015. > --- >> Cookies", Work in Progress, Internet-Draft, draft-ietf- >> dnsop-cookies-04, 1 July 2015, <http://www.ietf.org/ >> internet-drafts/draft-ietf-dnsop-cookies-04.txt>. > 628,629c606,619 > < Size Issues", draft-ietf-dnsop-respsize-15 (work in > < progress), February 2014. > --- >> Size Issues", Work in Progress, Internet-Draft, draft- >> ietf-dnsop-respsize-15, 14 February 2014, >> <http://www.ietf.org/internet-drafts/draft-ietf-dnsop- >> respsize-15.txt>. >> >> >> >> >> >> >> Yu & Liu Expires 29 October 2022 [Page 11] >> >> Internet-Draft DNS message fragments April 2022 >> > 632c622,623 > < specification", STD 13, RFC 1035, November 1987. > --- >> specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, >> November 1987, <https://www.rfc-editor.org/info/rfc1035>. > 634,635c625,628 > < [RFC1123] Braden, R., "Requirements for Internet Hosts - Application > < and Support", STD 3, RFC 1123, October 1989. > --- >> [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - >> Application and Support", STD 3, RFC 1123, >> DOI 10.17487/RFC1123, October 1989, >> <https://www.rfc-editor.org/info/rfc1123>. > 639c632,633 > < IPv6", RFC 3542, May 2003. > --- >> IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, >> <https://www.rfc-editor.org/info/rfc3542>. > 642c636,638 > < Resilient against Forged Answers", RFC 5452, January 2009. > --- >> Resilient against Forged Answers", RFC 5452, >> DOI 10.17487/RFC5452, January 2009, >> <https://www.rfc-editor.org/info/rfc5452>. > 645c641,642 > < Control", RFC 5681, September 2009. > --- >> Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, >> <https://www.rfc-editor.org/info/rfc5681>. > 648c645,647 > < for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. > --- >> for DNS (EDNS(0))", STD 75, RFC 6891, >> DOI 10.17487/RFC6891, April 2013, >> <https://www.rfc-editor.org/info/rfc6891>. > 660c659,687 > < Appendix A. Change History (to be removed before publication) > --- >> Authors' Addresses >> >> Haisheng Yu >> Guangzhou Genlian >> Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou >> Guangzhou >> China >> Email: hsyu@xxxxxxxxx >> >> >> >> >> >> Yu & Liu Expires 29 October 2022 [Page 12] >> >> Internet-Draft DNS message fragments April 2022 >> >> >> Yan Liu >> Guangzhou Genlian >> Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou >> Guangzhou >> China >> Email: yliu@xxxxxxxxx >> >> >> >> >> > 662,663d688 > < o draft-muks-dns-message-fragments-00 > < Initial draft. > 672,674d696 > < Sivaraman, et al. Expires January 21, 2016 [Page 12] > < > < Internet-Draft DNS message fragments July 2015 > 677d698 > < Authors' Addresses > 679,683d699 > < Mukund Sivaraman > < Internet Systems Consortium > < 950 Charter Street > < Redwood City, CA 94063 > < US > 685,686d700 > < Email: muks@xxxxxxx > < URI: http://www.isc.org/ > 689,693d702 > < Shane Kerr > < Beijing Internet Institute > < 2/F, Building 5, No.58 Jinghai Road, BDA > < Beijing 100176 > < CN > 695,696d703 > < Email: shane@xxxxxxxxxxx > < URI: http://www.biigroup.com/ > 699,703d705 > < Linjian Song > < Beijing Internet Institute > < 2/F, Building 5, No.58 Jinghai Road, BDA > < Beijing 100176 > < CN > 705,706d706 > < Email: songlinjian@xxxxxxxxx > < URI: http://www.biigroup.com/ > 728c728 > < Sivaraman, et al. Expires January 21, 2016 [Page 13] > --- >> Yu & Liu Expires 29 October 2022 [Page 13]
