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

Stephan Wenger <stewe@stewe.org> Tue, 03 May 2022 16:21 UTC

Return-Path: <stewe@stewe.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036DEC159A2A; Tue, 3 May 2022 09:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steweorg.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8nxPRDu49wI; Tue, 3 May 2022 09:20:58 -0700 (PDT)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e89::71c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF41C159A1C; Tue, 3 May 2022 09:20:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lSQhfLJ70l7xEtAGjqdNboeIv+/XlUBmvrPRSnXK8KTp5K3D1z70eFJrB+XLA+5SL2mRRiNClSgDDE6ucLEX0N4qowHf8sj11TOq1sanXo6N6d5Or0eE9J2XtZ/j8TmYAaQEqy1s3Ej0+HMKKiCOnzPqsN1GdoSicEfYyUPFyoQY2RzIx+uxoi7aKUkag4ELqaLXpcJ1SU3x4OU4s9D+JXVEgBlJDfwhRiLnRlUfkiYg+BGtCsVqunlD3xybSfuv4L83VhQeuDG+V7zu8q9eR/U6htNRAO3R96mVqc1OeUDx2KXz8nwd9POcC6uwgXH0R/GWSzGJalT5Okakk/cqbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Zg+WxHMDdDY1JsQvRNfcvDH/BJ93C60uMPBfB/L16V4=; b=Edox8nnaaXTHQZ5Yoh1jez/oYsiA2snSGr92fpWv02itWXM45pj7XoawjwoEvkyEJDp4SJjA6lJ64q/lPpFVIUXFJLNjx/FegCwZZWdXtie8v64HUT03iKzLBt6KT7q/SwKwp87GB8bq4T+pZlwwNKJeQpF9/IOnV5c3oZ+KjmgJFnHKNXIoRShVxW7egEPmqzRBxj9PeaOZ9Ic7SawaB++YqKYwpVlxYfEDW0WSvmT8HPwAgP+ftNBGnA8vpHh4vFzKOJzYCYo8lhSm5JULSHuQCW2APJPg5liy9wtoIsIwY5sbWBJQsk2a1XS4OfWjlICOI/4z2iBX13hIMrm17Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=stewe.org; dmarc=pass action=none header.from=stewe.org; dkim=pass header.d=stewe.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steweorg.onmicrosoft.com; s=selector2-steweorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zg+WxHMDdDY1JsQvRNfcvDH/BJ93C60uMPBfB/L16V4=; b=ChPHcvv5U1RTSmm0SdFCHKqqmsC+exarhMGHM/x72ZPuG/HODNPlcGGZ00Ytpe+WqcYhdXM0H7PwTom4t1JI9LLZE4gbLZW5Q7PfjptcmYKBKKrwevljThK2xw9+qlTelhK0ePmXrv6r638vBW0r+UHTy1OTIuin+D8zmybBaAI=
Received: from SJ0PR17MB4632.namprd17.prod.outlook.com (2603:10b6:a03:375::19) by MN2PR17MB3805.namprd17.prod.outlook.com (2603:10b6:208:204::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.24; Tue, 3 May 2022 16:20:51 +0000
Received: from SJ0PR17MB4632.namprd17.prod.outlook.com ([fe80::e000:a4a:97a9:ef1b]) by SJ0PR17MB4632.namprd17.prod.outlook.com ([fe80::e000:a4a:97a9:ef1b%7]) with mapi id 15.20.5206.024; Tue, 3 May 2022 16:20:51 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Mukund Sivaraman <muks@mukund.org>, Benno Overeinder <benno@NLnetLabs.nl>
CC: Shane Kerr <shane@time-travellers.org>, DNSOP WG Chairs <dnsop-chairs@ietf.org>, IETF Discussion <ietf@ietf.org>, DNSOP Working Group <dnsop@ietf.org>, "yliu@cfiec.net" <yliu@cfiec.net>, "hsyu@cfiec.net" <hsyu@cfiec.net>, "hsyu@biigroup.cn" <hsyu@biigroup.cn>, Cindy Morgan <cmorgan@amsl.com>, Trustees <trustees@ietf.org>
Thread-Topic: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
Thread-Index: AQHYWyLP3xb3Yyem0UiU4yARCmNTwq0FodQAgAANoACAACiJgIAA4N8AgACZugCAAAYpgIAB8m+AgAOctQA=
Date: Tue, 03 May 2022 16:20:51 +0000
Message-ID: <741A7E29-1AD8-4187-A897-244CC6D4ABDA@stewe.org>
References: <165116358815.5877.9244565954759130167@ietfa.amsl.com> <YmrKSN5OSQh2/SQf@d1> <CAF4+nEE0AJSjUfYXLjxUE94k544k_cK2v7HxNRS1XmSVOnQRPg@mail.gmail.com> <YmrlXv1/L6Ina504@d1> <2AD4D97C-3CAE-476C-B257-6AC7BD8F7F93@amsl.com> <7000069C-15D4-444F-89D1-79B0C89DFBB7@eggert.org> <57d6f6da-a88a-8c84-e5a2-cf956530c64a@NLnetLabs.nl> <YmxKIYi7l2bN2u2F@d1> <978fef52-c6d8-7f97-9ec3-75ca7dad0f46@gmail.com>
In-Reply-To: <978fef52-c6d8-7f97-9ec3-75ca7dad0f46@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.60.22041000
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=stewe.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 764cc0e9-a12f-44e4-1f7a-08da2d20e3ec
x-ms-traffictypediagnostic: MN2PR17MB3805:EE_
x-microsoft-antispam-prvs: <MN2PR17MB38051C362DF23F368A45D922AEC09@MN2PR17MB3805.namprd17.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: AAQB5idLPomeEDUgjCfAO3yDmMqsITI72B7c6/58KWIZvCdlISYT0EEwhn4OEb7rb1DdjyfdwJA8jxza5SUCmrA1Y92GOIlbqNrmHNrFVwVxSsLYvydyAsWgzwKN4K3hjC/8+YVQeqxbiRZRc3/2aPPY/uF1Z1+alSdNajrJf29yOBL6M4rxMDF4ZxoljOOS7MTGP/t9huYWs8Af61GiXo8ceSalKEL3RTY8ERV0aWk8Pc+Hjz4acbOc0Ofv98CaTgrR04jhokCKqv1/iWYKJBBbxrQNZX2mkJ7BxCHJKpKjnzaoNI+23Y0MXKYDy1uB6gFTKGL2QUZFY3gYuNCaKEh5I+gT5Q13x0d7J86TfJPX1CKZwQbhNy5ePVnugiLFYz74/OrOxZDxeQsYky26XIwC6P84a9MlEPAWVJSkMhfu9zCl8ikML3GXe7dBqVw0b33XNEkMC0O6W68pMnk1ZS+OnJth7f9IfDBTCFHn2iPF6Rkmmb0LNXISnW5RgK8ZBvBe/sT7UNGBJW4VKYHiADZBLGaOOsmngMMiMJ9v8Hr9xRyi1Sj+nztWuF1ajGBBipVNlchcbbTJawyGeEu1oJaiI29gAXq7fw+7lxip83Z5t6IR/6n6IdTyWH/fcPoGPAVXW2VLbPBv6YmWuyFrYmUfWIXJBZxsrEHG9lOI6EXnFpU71bW3AKYAPDXMgrQlDB5bKCoseugq7DqNTD2AWJ8tTrOmdTg+gPb/Ma6GSxnSbBQcs5RO/MgppwaSD+/Ks5uZSotS+ukqAawAm5MBwKpnxwz5dv78F1PNSMaiFxrUafYZlaP9aUMlQIKGOXiV
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR17MB4632.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(376002)(39830400003)(396003)(136003)(346002)(5660300002)(7416002)(66446008)(33656002)(4326008)(15650500001)(64756008)(66476007)(66556008)(66946007)(8936002)(76116006)(8676002)(508600001)(54906003)(316002)(6506007)(122000001)(6486002)(38100700002)(966005)(2906002)(38070700005)(110136005)(26005)(83380400001)(2616005)(6512007)(36756003)(71200400001)(186003)(86362001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: WOoCDwSpqKjtC76Yjf/zUpwAxX4hXc0450CCi2jr00pjZd9b2+AfafcAEJYO34TzSwhr8oE5aqNW9X6Jf2iSg6A3RAweESaQ8sptXfgQqe0sRw4wOFD/XHeuE+0sZm6gqoD4Y+QmVBSTVTMmJSmtHt+gbG54qst2N2GoXc2om0j3Oiu1tCIDGcWe68nBRh5bMVgpHoZ1LLp69lfoEcyfdcSkXQvyr3iU2OuhOA2mUIH2km1CLFVxuxliSKSBtnpA/M41tv88/Mmu/XaFUP3d/exE6AfDsFcocLhX5WoBbxxnaPf9tlsmOd2yaxDn+ETacyFa2bYaZfrLr7IRTqhD13zqnvRYFa5At9yDVn+UX0BpoXlNuJCCcYvQcYgyHd5ev5RuqI2WImP9D0iZF++Ks3gIPn8Y4EShgnRSATBSfKH/DIuCBJUfBUdYj6ESFY6xjK5Tr07uSGDmn+Fv2IjGpV9uwdQftGTLu+HSc4KCzUACD9iH43R04VGqbB/5SDTs731RwWqMiyhx6iDITwGWbEmfgDShVQW7ZhqV3GQ+UKHdyll6rNGycoSH/3vzGVIcaQcuHxqJEfJNLEMJekQn0VExEAuo5t9excu5p/eOFITg71aG5FzlpXU3uUGgMBHzlPjZfp+vwvixEPPSAvdT5lWevwKUVgRqR+sRN6ewie2xNQWVMAh/nfHW9x7lZ2+e0PAPHFseTI9/uYLne01/BhhkLtf2bKo60fnXieXWGRije4TPwcYa1PBuqttSLEXrP4aAWuma3FOTLjoUTeOqwaRyv943W0nNqaNbS3V1YuboDkxYSVi6A+HA+MRs8DJzGWVJkh0IhjUo20mq3pDNhLcSP0ICRvkfuVDCf6HfpDpd6HTnWW/xbOgjFXip5JHEWGwnbn9/raAIuBlxNtqB+U5QoKGBhtnjr8Q9QGZ6WxKTKvN6qSofgMQAmkTNEFCVOngcYYsejEZJRBJ+OEFtSxvlwoMT2+1Vsz1u0BjIMJLY2b874twxs45XnO+x7RT1FAoKIY9XpCxUIL1IVDqchjBUkUbNkXpVxtv/9FvCqwEVkyEyvXKiPRLKZLLBdWOuiGlVp69a34xZXrG6VnlLZOusi+BEUDACtBWg91kpZuBXGwhBaMVywWqgnvu+v4eYTVQjfAV51b4MGPCdtug8nHGcieyoYVsgbEnD3uPCCZ4HBggtoPtZWd/+eyABtgp9mSAD3YY/hOwtAmlPp5S/nT1LWTfbvr9GuFttq73DTeJZpmtWyEd4aKx3r3d//0ADUP4pn1YmWsvBc0tAhSRpZHcchQ2Ic/8fyCAlucnvXhMtT30W6zNop93Jd0njhwraW4ilwl2QNSCNgImd8Uleh2GlpscvEdotAqvFN8qdmkoHG6XNJyxdzfxQrdca8FyUMd5qnTNsRzDeuAIL6oHIVb70b6B0OaM/s8Odf1rLjru9rJxbYJJRZ15lsv/jKSrkZCFdyyLzNqnk4ILupy8R6B8zkNqq+FgsGCp7ONjZpdrhFc8VqeJMFJWlFp+l9TIm6E44p8d2tlwpl8Rt0cofO7KFesgfUKs7bKviPnI46pTc15wKRsD9PDTwpabQpcIwbYaouz+HTWwwaGWDuVoMJjKYvyP0Lf58EPbnp5Y5NJ/1zM79W+zZEJoXNHmh2KWG6OdtpUTqcupYza0zM3x6vE9MygTnlYYqcyNZNT+KckOY1vHJ+dKSXP0MO56eQPQxEszwOJ12YWBm4Wgyv9Fvvg==
Content-Type: text/plain; charset="utf-8"
Content-ID: <F6A949ACBF4CF14C9010C94008F28A53@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR17MB4632.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 764cc0e9-a12f-44e4-1f7a-08da2d20e3ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2022 16:20:51.1827 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IiJGA1exz8KyJu2m1Trof/Rd87R5q+pdJQsh+An/gFLNLlimEPust8ixxJCu6oOm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR17MB3805
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gX8M7HOI8n8Z0zawDK86p1jJr_c>
Subject: Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2022 16:21:03 -0000

Hi,

Adding the Trustees.

Speaking as one of the Trustees but not necessarily for the IETF Trust, I don't think the IETF Trust has anything to do here.  The IETF may.

What I write INLINE below is written as an analysis of the situation from an IETF Trustees viewpoint, and a legalistic viewpoint at that.  To summarize the many letters down there, I believe nothing legally wrong happened, and the trust has nothing to do in this case or towards similar cases.

Taking off my Trustee hat and getting into the shoes of someone who has spent time and energy writing something up, just to watch his name to disappear, I don't believe what happened was "right" even if it was legal.  The problem is not copyright law or copyright notices, the problem is proper attribution of work that was performed by someone else.  Remedies are obviously available, circling around proper attribution of substantially all the -00 text to Mukund and the other authors of the initial text.  In the order of cleanliness:

1. The perhaps cleanest way would be to follow most SDO policies and remove any attribution to individuals.  However, that's not going to fly here in the IETF.

2. The IETF, in my opinion unwisely, decided a long time ago to limit the number of listed authors to five, relying on "editors" in the authors' field of the I/D/RFC front page and an contributors/acknowledgement section.  That's neither fish nor meat when it comes to proper attribution, as many folks, often from the academic field, have complained before.  Changing this policy back to where it was before 2000 (where an I-D or RFC could have as many listed authors as appropriate from a contributing viewpoint) may be the cleanest way forward without boiling the ocean, even if in some cases the first page of an RFC would basically be an author's list.  However, that's a policy change that would take time to make.  Also, the original arguments for limiting the number of listed authors on the front page are still around, hence the fate of such a proposal would be unclear.  In any case, we have a real problem NOW, which (I guess) cannot wait for IETF policy work.

3. I believe that the I-D and RFC editors can make exceptions from the five-listed-author policy in justified cases.  Given the controversy at hand, this may well be such a justified case.  One justification is Mukund's justified (I believe) complaint.  The other is that if his allegations are correct, the copyright notice we have today may be unusable for its intended purpose.

4. As a last resort, many I-Ds and RFCs include an acknowledgement section, which is free form.  Proper acknowledgement to the predecessor draft and its authors (including calling them authors and not contributors or something), would IMO make the copyright notice stick to them.  Whether that's also an adequate attribution, and remedy form Mukund's et. al. viewpoint is, of course, for them to decide.

Mukund seems to be aware of most or all of these options, and I hope that a pragmatic way out here will be ultimately found.

Assuming Mukund's claim that he and his original co-authors indeed have authored most of the text in question and hence may own the copyright (I haven't verified that but have no reason to doubt it either, based on the email conversation), the current copyright message would likely be rejected by the US copyright office if we were trying to register the copyright, which in practice is a requirement before enforcing the copyright.   Insofar, I would recommend that the eth current authors and/or the WG take action, preferably using mechanism 3) above, or if the pushback is too bad, mechanism 4.  

I kicked around the idea of a change in the boilerplate that could adequately address this problem (as suggested by Brian) but couldn't come up with one that would work.  If interested, please see inline below for details why I think nothing was legally wrong, the Trust has nothing to do, and why I don't believe a change to the boilerplate copyright notice can be made that addresses the problem of non-listed authors.

Stephan


On 5/2/22, 07:04, "ietf on behalf of Brian E Carpenter" <ietf-bounces@ietf.org on behalf of brian.e.carpenter@gmail.com> wrote:

[...]
    > 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?

    I am not a lawyer, but I believe it's true that *nobody* can remove the
    original authors' copyright (although the details might differ in each
    country's laws). 

That is my understanding as well.  Beyond that, the IETF and IETF' Trust's legal framework is designed such that authors retain full rights to their work, with the exception of the license they grant to the IETF trust.  That's by design, and it's different from many other author/publisher relationships.  

    However, the point here is that when an IETF I-D is
    submitted, it is done so under the IETF's conditions, including the
    IETF's right to produce "derivative works". The details are in BCP98
    (RFC5378) and in the IETF Trust's Legal Provisions, but basically it
    means that the text can be re-used in future IETF drafts and RFCs.

Yes.  To amplify: the IETF's legal framework is designed to allow anyone to pick up abandoned work of others.  Nothing wrong with that.  What may have been a mistake on the policy side was to rely on proper courtesy by the new authors, under the assumption that everyone contributing here is of the same mindset of what "proper courtesy" in such a case entails.

[...]

    I wonder if the conventional sentence "Copyright (c) 2022 IETF Trust and
    the persons identified as the document authors" needs to be tuned to
    also cover previous authors when the authorship team for a draft changes?
    But that question is for the IETF Trust and its lawyer.

The IETF Trust "owns" certain IPR, including the co-ownership of copyright of I-Ds and RFCs.  RFC5378 further delegates the authority to change copyright notices to the IETF Trust.  Insofar, Brian is correct that modifying the copyright boilerplate would be for us to make.  Speaking as one of the Trustees, I would not want to address this problem though, mostly because the IETF has adequate remedies to deal with the case at hand, and similar cases.  Mukund's real problem, as I perceive it, is not the copyright notice, it's the lack of proper acknowledgement and attribution of his work.  That's nothing a boilerplate change can fix; it's an IETF culture thing and for the IETF to address. 

As Brian has correctly pointed out above, the original authors (including Mukund) retain their rights under US copyright law, which is the governing law when it comes to the IETF Trust.  That's irrespective of the copyright notice, even if the notice were not formed correctly.  The copyright notice has certain purposes, including preventing innocent infringement and pointing a possible user of the copyright to the correct addressee(s) to obtain a license, as well as establishing a date when the work was published.  Its formalities are checked by the copyright office only when registering the copyright, which in turn is a common/necessary step before litigating a copyright claim.  Establishing, or enforcing copyright, or creating an equitable relationship between multiple copyright holders, are NOT one of those purposes.  Further reading, for example, here:  https://www.bitlaw.com/copyright/formalities.html or, in more detail, here  https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf 

By law, copyright notices include the copyright holder's names, or references to those names such as our "persons identified as the document authors".  See 2205.2(F) in the linked document above.  In case of books and such, the copyright notice typically does not list authors' names but rather the publishing house, as the copyright was assigned by the authors to the publishing house when they sold the book.  The same is true for submissions to most journals or conferences, where you see IEEE or ACM and such as the copyright holder's name.  In either case, it's easy to know where to go to obtain a license, which is the key purpose of the copyright notice.  For an attribution to the individuals who wrote the book or paper, the copyright notice is NOT the right place.  

For self-published work, the copyright notice normally contains authors' names.  Again, it's presumably easy to know where to go to obtain a license.  The same is true for our boilerplate statement, as the IETF Trust is easily identifiable and the "persons identified as document authors" are listed on the front page and their contact information is part of the I-D or RFC.  Insofar, the copyright notice as we have it should be formed well and acceptable to the office when registering the copyright.

We cannot sweep in all unnamed authors, be they unnamed by accidental omission or by bad intent of a player, by a simple boilerplate change pointing towards "all authors" or "all contributors" or something like that.  It would go contrary to the purpose of the copyright message, which is to provide a potential user of the copyrighted material with a point of contact.  Formally speaking, it would go against 2205.2(F).  As an example, in the current case, it's too much to expect that anyone using wishing to obtain a license to be aware of, and using, an IETF tool like the datatracker to hunt down Mukund's coordinates, and/or doing research on expired drafts on who is owning the original text, and all that in a hundred years from now (which is how long copyright can easily be enforceable--lifetime of author plus 70 years.)



[...]