On Tue, May 19, 2026 at 3:40 PM Brian E Carpenter <
[email protected]> wrote:
> So, I haven't seen any comments.
>
> Either that means everybody is 100% happy with the draft
Definitely not this one.
Overall I continue to believe that these decisions should be
taken on a stream-by-stream basis, and therefore I oppose
adoption.
I also disagree with a number of specific points.
S 2.
This whole section is confusing because you list various principles
and then take some of them back in the last graf. If you're going
to list principles, they should only apply to RFCs.
* Balance between opposing arguments, when relevant.
I have no idea what "when relevant" means. In some cases, this is
appropriate, in others, not.
Other aspects are that personal or business considerations should not
affect accuracy and balance, and any hidden conflicts of interest
should be documented.
This doesn't seem like it applies to RFCs where authors routinely
work on commercial implementations, especially given the fiction
that people participate as individuals. Indeed, AFAIK there is
no requirement that people routinely identify their employers
at all.
Corrections, clarifications and retractions
should be made promptly when needed.
This seems much more like an RFC 6919 "MUST (BUT WE KNOW YOU WON'T).
S 3.
People who did not make any such substantial contribution should not
be listed as authors. Funding support, professional reputation,
managerial or supervisory status, and CV embellishment are
irrelevant. It is also worth noting that in an RFC, authorship by an
employee does not automatically imply endorsement by the employer.
Therefore, authors should not be added just because of who they work
for.
It is not unknown in academia for supervisors to automatically share
authorship of work by their students. Such cases should be resolved
within the RFC stream concerned.
Is this first graf supposed to be some kind of general principle or a
statement about the RFC series? If the former, it seems like it's
contradicted by the second graf. If the latter, it's unclear that
that's the case.
There is no general rule about the ordering of author names, but
alphabetical order is always acceptable.
Why are you calling out alphabetical order specially? It's neither
more or less acceptable than any other order. I recognize it's
common in many fields, but it's also deeply unfair to people
with last names towards the end of the alphabet.
There are quite a few subjective judgements to be made about whether
a contribution is substantial enough to count as authorship. What
fraction of new or corrected text counts? Is a particular concept or
brilliant idea enough? Should the author of a previous trail-blazing
document be invited to join? Should someone who promised to
contribute significantly, but only contributed fragments, be removed?
It is hard to give definite guidelines for such cases.
This graf and indeed this whole section just doesn't line up well
with RFC 2418, which explicitly invests the WG with the power to
define a Document Editor for WG documents, without regard to the size
of their contributions. Section 5 similarly does not line up well.
S 6.
Acknowledgements should be given to people who have made significant
creative contributions smaller than those from the authors and
contributors, or to people who have made useful comments, provided
critical reviews, or otherwise contributed significantly to the
development of the document.
The line here between "acknowledgements" and "contributors" seems
quite fuzzy and hard to police. Over in TLS 1.3, I just listed
everyone who I thought made any kind of significant contribution
(pretty much anything beyond simple editorial stuff) as a Contributor,
and I wouldn't want someone telling me that I couldn't.
If text or ideas have been adopted from
other written sources, including RFCs and drafts, clearly a reference
is an ethical requirement, but an acknowledgement might also be
appropriate.
IETF documents routinely incorporate ideas from a wide variety of
sources, and as far as I can tell it's not a requirement to make any
kind of reference to those ideas, especially when they are well known
in the field. For example, RFC 791 doesn't cite Baran for the idea of
packet switching. RFC 3174 specifies SHA-1, and cites MD4 but doesn't
note that the original idea of hashing is due to Merkle, etc.
S 9.
* If a substantial part of the document was created by AI this must
be disclosed clearly and in detail, typically in the
Acknowledgements section.
I do not agree with this as a general requirement. As I said
originally, the place to start here is with some description of the
problem this requirement is trying to solve.
-Ekr
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
