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

[Mukund Sivaraman <[e-mail]>]

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: [e-mail]
> 
> 
> 
> 
> 
> 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: [e-mail]
> 
> 
> 
> 
> 
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: [e-mail]
<    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: [e-mail]
<    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: [e-mail]
<    URI:   http://www.biigroup.com/
728c728
< Sivaraman, et al.       Expires January 21, 2016               [Page 13]
---
> Yu & Liu                 Expires 29 October 2022               [Page 13]