On Mon, Jun 8, 2026 at 7:52 AM Scott Bradner <[email protected]> wrote:
> how possibly could you conclude what my opinion might be as to RFCs 8446 & > 2821? > all I was doing is citing the rules that have been around for a long time > (back at least to RFC 2026 - sec 10.3.1.4) > I wasn't concluding what your opinion was. I was asking how you interpreted that language using those as examples. -Ekr > > Scott > > > On Jun 8, 2026, at 8:48 AM, Eric Rescorla <[email protected]> wrote: > > > > I don't disagree that there are documents that *do* provide detailed > contribution lists, but there is also quite a range of practice, including > documents which just list people without listing their contributions (RFC > 8446) and those which just gesture at a large population of people without > listing any of them, as in RFC 2821: > > Many people worked long and hard on the many iterations of this > > document. There was wide-ranging debate in the IETF DRUMS Working > > Group, both on its mailing list and in face to face discussions, > > about many technical issues and the role of a revised standard for > > Internet mail transport, and many contributors helped form the > > wording in this specification. The hundreds of participants in the > > many discussions since RFC 821 was produced are too numerous to > > mention, but they all helped this document become what it is. > > What I'm asking here is what you believe this text actually *requires* > in terms of individually acknowledging contributions. Is your position that > 8446 and 2821 are in violation of BCP 78 in this respect? > > > > -Ekr > > > > > > > > On Mon, Jun 8, 2026 at 4:42 AM Scott Bradner <[email protected]> wrote: > > an example - RFC 2149 > > > > 7 Acknowledgements > > > > We would like to acknowledge Grenville Armitage (Bellcore) for > > reviewing the document and suggesting improvements towards > > simplifying the multiple MCS functionalities. Discussion with Joel > > Halpern (Newbridge) helped clarify the multiple MCS problem. Anthony > > Gallo (IBM RTP) pointed out security issues that are not adequately > > addressed in the current document. Arvind Murching (Microsoft) > > flagged a potential show stopper in section 4.1.2. > > > > (there are rather many more) > > > > > On Jun 8, 2026, at 7:35 AM, Eric Rescorla <[email protected]> wrote: > > > > > > > > > > > > On Sun, Jun 7, 2026 at 5:35 PM Scott Bradner <[email protected]> wrote: > > > > > > > > > > On Jun 7, 2026, at 7:52 PM, Eric Rescorla <[email protected]> wrote: > > > > > > > 1. This text is purely about contributors duty to the IETF, not > about what appears in RFCs. It's entirely consistent with this text for an > RFC to contain no acknowledgements of any names besides the author, even if > all the work is from others. So, at most this would require indivian > example - RFC 21duals to identify AI assistance at the time of contribution. > > > > > > huh > > > > > > the rule says "The Contribution properly acknowledges all > Contributors" - i.e > > > text in the contribution lists the contributors - unless the text is > remove it would > > > appear in the RFC (and this editor of the rule expects that to be the > case) > > > > > > I think this is overreading the text quite a bit, but perhaps it would > be > > > more useful to try a worked example. For example, RFC 5378 itself > > > has the following acknowledgement: The editors would like to > acknowledge the help the IETF IPR Working > > > Group provided during the development of the document. > > > I take it you believe that this is an acceptable acknowledgement, even > > > though it does not list any person by name? What level of contribution > > > do you believe would require someone to be named individually? > > > > > > -Ekr > > > > > > > > > >
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
