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]
Attachment:
signature.asc
Description: PGP signature
