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

[Cindy Morgan <[e-mail]>]

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 <[e-mail]> 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: [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]