Subject: Re: [rfc-i] RFC Errata junk

From: John C Klensin <[email-masked]>
Date: Fri, 01 Apr 2022 19:25:03 -0400

--On Friday, April 1, 2022 16:26 -0500, Robert Sparks
<[email-masked]> wrote...

> On 4/1/22 3:14 PM, Stephen Farrell wrote:
>> 
>> Hi Robert,
>> 
>> On 01/04/2022 16:47, Robert Sparks wrote:
>>> I think DT account-creation and login, while raising the
>>> barrier to 
>>> entry,?is?the?right?threshold?to?ask?errata?reporters?to?cro
>>> ss.
>> 
>> I think that's the wrong answer. An Errata handling system
>> ought IMO be as usable for RFC readers as for those writing
>> RFCs.
> 
> I'm not suggesting someone need an account to _read_ errata if
> that's  what you mean.
> 
> But supplying them is, again, a contribution.

While, like Stephen and others who have stepped in on this, I am
very concerned about non-IETF-stream RFCs and people who read
and use RFCs (of any Stream and Status) who are not regular IETF
participants, I tend to agree with Robert.  His reasons and mine
when I suggested this are, I think, similar:

First, being able to identify those who are submitting errata
would probably be a good idea.  The questions that have been
raised about bulk registrations by evil-doers, whether the
datatracker login process is good enough, etc., seem to me to
apply more generally: if they are reasons to not use those
logins for errata, then the datatracker system is almost
certainly in need of strengthening against them on principle and
for many of the other purposes for which it is used.

Second, if the submission of errata does not require some sort
of IPR waiver to allow the RFC Editor, and those who use RFCs,
to make use of whatever is said and to do so without getting
tangled up in questions of third-party rights and ownership, it
seems to me that there is potential for a complicated mess...
and that we should pull the Trust and Counsel in and get that
fixed forthwith, regardless of whether some sort of login
procedure is imposed or not.  On the other hand, while IANAL,
I'm fairly confident the Counsel will tell the Trust that an IPR
agreement from someone would not be worth much if we have no
idea who agreed :-(

Perhaps there is an issue with treating errata as Contributions
when the errata are, e.g., Independent Stream documents
published with restricted rights.  But, in a more perfect world,
a cost of publishing a document with restrictions should be that
the RFC Editor Function does not take responsibility for errata
but instead directs those wishing to report them to contact the
author(s) directly.

I do see other ways to do the same thing, most of which involve
logins and IPR agreements specific to the RFC Series, but that
feels like a great deal of procedural and tooling effort for
little marginal gain.  And extra work for those of us who
periodically submit errata _and_ are IETF participants.

I agree with Brian that we should not use the datatracker login
requirement (or much of anything else) without agreement from
all four streams and/or specific instructions from the Trust
[1], but I would hope that, with the application of a dollop of
good sense, that would not be a complex or time-consuming
process.

And, if the datatracker login procedure requires any significant
commitment to the the IETF other than agreement to IPR policies
and maybe the Code of Conduct and/or collects any information
beyond that required to establish whatever level of identity is
needed to validate logins and agreement to those policies, I
suggest that is something else that needs work.

So, yes, let's move toward treating errata as Contributions.  Or
if people (or any of the streams) have a big problem with that,
let's start thinking seriously about alternatives rather than
ignoring the issues.

_BTW_ other than getting started on any IPR issues, I don't see
any urgency about any of this.  I'd, personally, be happy to see
the CAPCHA implemented and whether, theorizing about attacks
from smart robots aside, it reduces the amount of noise.  Unless
the attack volume suddenly increases significantly, it would
seem perfectly sensible to me to take this thread (and the
previous ones on the IETF list) and drop them in the virtual lap
of the RSWG.

   thanks,
     john

p.s. if statistics are being collected, I'd like to understand
what fraction of the legitimate reports come from people who
already have datatracker logins versus those who do not.    It
might be useful to understand whether we are arguing about a
real problem that might affect more than a very small group of
people -- not that it should not be solved, but that might
affect how excited we should be.

[1] My understanding of the Trust agreement is that the Trust,
as the owner of the RFCs (from all Streams) and administrator of
IPR policies that I believe all Streams have agreed to (plus or
minus small flexibilities) would have complete authority to tell
the RPC to not accept any errata reports or comments on such
reports unless those submitting them had agreed to IPR policies
that would not put the Trust's property at risk.  That is not my
preferred way to move forward on this, but it is certainly a
possibility... and any plan we do adopt should at least have the
advice and consent of the Trustees.

_______________________________________________
rfc-interest mailing list
[email-masked]
https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 2 Apr 2022 00:39:36 +0100

Hiya,

> when I suggested this are, I think, similar:

I do understand and sympathise with that reasoning, but only
a little. ISTM that the problem with bogus errata is not near
pressing and the IPR/contribution problems from errata are
purely theoretical (do correct me if I'm wrong there). I
hope we'd also agree that forcing users to create otherwise-
pointless accounts on web servers is a well enough known
anti-pattern to be avoided.

Cheers,
S.

---

From: John C Klensin <[email-masked]>
Date: Fri, 01 Apr 2022 21:29:24 -0400

--On Saturday, April 2, 2022 00:39 +0100 Stephen Farrell
<[email-masked]> wrote:

>> While, like Stephen and others who have stepped in on this, I
>> am very concerned about non-IETF-stream RFCs and people who
>> read and use RFCs (of any Stream and Status) who are not
>> regular IETF participants, I tend to agree with Robert.  His
>> reasons and mine when I suggested this are, I think, similar:
> 

Stephen,

Our views are not very far apart, but...

* While I have been irritated (and trapped once, albeit with no
long-term damage) by bogus errata and, apparently, others have
too, I haven't seen nearly enough data (or well-justified
outrage) to conclude that the problem is pressing (or even
near-pressing).   Unless the RPC tells us that the problem is
feeling overwhelming to them, it is not pressing and we should,
at most, ask the RSWG to have a look at the issue and, as
needed, discuss it with the Tools Team, and/or Jay vis-a-vis the
program of work under the RFP to rebuild the RPC's tools.

* While I'm not aware of any errata-based Contribution/IPR
problems either, I have little difficulty imagining a scenario,
albeit not a terribly likely one unless someone wants to put
serious energy into being disruptive, in which the errata could
be used to induce an IPR crisis.  Any good attorney, at least
those of my acquaintance, would say that it is far better to
anticipate such issues and get the possibility under control
before they occur rather than playing the odds and risk having
to fix things mid-crisis.  However, I think this is the Trust's
problem, not that (directly) of the RFC Editor, and I know that
there are Trustees who follow this list.  I hope it is not
unreasonable to assume that, having been alerted by the
conversation, they will take it upon themselves to consider and,
as needed, investigate the situation and take or propose
whatever action they decide is needed.  Such action clearly
might include giving the RSWG advise about what to discuss and
how to discuss it.

If we, and others, can agree on the two points/suggestions
above, perhaps we can avoid an interminable discussion on these
two issues (or the "junk" more generally), issues that may or
may not be related to each other.

  best,
    john

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2022 22:29:41 -0400

It appears that John C Klensin  <[email-masked]> said:
>outrage) to conclude that the problem is pressing ...

We haven't even added a CAPTCHA yet.  Let's see how much that slows
down the junk.  At this point I have no idea whether the junk is
from confused people or from confused spambots.  None of the nominal
submitters have ever replied to queries so who knows.

>be used to induce an IPR crisis. ...

Honestly, I have trouble imagining a plausible scenario in which an
erratum adds a significant chunk of someone else's text to an RFC and
the RFC doesn't already have a bunch if the same source's text. Sure,
someone could send in an erratum with pages of random pirated material
but we wouldn't use it.

I am much more worried that someone accidentally or deliberately
quotes another SDO's document in a published RFC without permission, a
scenario which is not hypothetical.

As you may be aware, Carl Malamud's public.resource.org has been in
court for most of a decade defending a copyright suit from ASTM,
ASHRAE, and NFPA for republishing standards that have been
incorporated in law.

Just yesterday they seem to have won.  Fortunately they had excellent
pro bono lawyers or they'd have been dead and buried in 2013.

Link to court papers and press releases:
https://twitter.com/carlmalamud/status/1509671912468746250

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Apr 2022 15:37:07 -0400

> pressing and the IPR/contribution problems from errata are

I agree.

An email verification step should be enough, and we don't need to do that up
front, but simply take the verification as part of the input to the process
of validating the report.

If someone *has* (optionally!) logged via DT, then that it's a different bit
of input to the validation process.

i.e. none of it is binary, but cumulative input to validation of errata.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
rfc-interest mailing list
[email-masked]
https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest