Eric,
On 20-May-26 11:13, Eric Rescorla wrote:
On Tue, May 19, 2026 at 3:40 PM Brian E Carpenter <[email protected]
<mailto:[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,
I don't see it as very different from IPR, where the IETF (appropriately)
led the way, and the other streams followed. In this case, it just seems
natural for the Editorial stream to lead.
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.
In the next version, I have trimmed a lot of that material and
moved it to an Appendix as background. But I think that for some
fraction of our contributors, it will be useful.
* Balance between opposing arguments, when relevant.
I have no idea what "when relevant" means. In some cases, this is
appropriate, in others, not.
Rephrased and relegated to Appendix.
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.
No. (But we do have a CoI policy for our "officials":
https://www.ietf.org/about/groups/iesg/iesg-coi-policy/)
Reworded and relegated to Appendix.
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).
Relegated to Appendix.
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.
Unchanged. I believe this *should* apply to RFCs.
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.
Deleted. (You're right about the contradiction, but it's not one we can
resolve.)
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.
Yes. Also, this is a very style-guidish point and I don't think it
belongs here at all. Deleted.
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.
I don't really see any misalignment. You're correct that 2418 is
authoritative for the IETF stream, and I've added a reference to
2418bis in the # Editors section.
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.
Yes. I've added a few weasel words.
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.
Yes. I think the sentence is redundant anyway, because it repeats
what is said elsewhere. It's gone.
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.
I'll concede that "clearly and in detail" is unjustified. But IMHO
the need for disclosure doesn't need any justification.
(My gut feeling is that this may come to be an issue in court
proceedings at some point, so counsel's opinion is definitely
needed.)
Thanks,
Brian
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
