a metadata ammendment towards the [RFC,documents] which supersede prior art, as denoted and approved with new documents, will provide hypertext and dedupe questions.. and additionally a place for IETF to maintain FAQs around relatable RFCs, online vs. adhoc email, and with authenticity.
#aQ
On Sun, Jun 13, 2021 at 10:49 AM John C Klensin <john-ietf@xxxxxxx> wrote:
--On Sunday, 13 June, 2021 13:14 +0100 Stephen Farrell
<stephen.farrell@xxxxxxxxx> wrote:
>
> Hiya,
>
> On 12/06/2021 17:14, John C Klensin wrote:
>> But that suggests that, at least for standards-track
>> documents, having people ask questions directly of the
>> authors and expect authoritative responses is something we
>> should be discouraging, not encouraging.
>
> Disagree. One of the good things about the RFC series
> and IETF specs is that they are written by sets of
> contactable humans.
often contactable.
> I don't think there's a real problem with authors giving
> secret advice that goes against IETF consensus so let's
> not change/break anything for that reason.
First, I don't see enough of a problem to justify a change in
what we have been doing. I am only concerned that making it
easier to find the authors of older RFCs might not be as good an
idea as it might appear to be on first glance. I'm worried
about two cases. And let me apologize in advance for saying
what amounts to "this is part of a larger problem and a quick
fix to part of it might make things worse". But it is and it
could.
(1) Assume someone wrote or co-wrote an RFC many years ago,
but has subsequently dropped out of the IETF. In the
intervening period and without that author being involved or
knowing about it, the IETF consensus on what is specified and/or
how it should be interpreted or applied has changed. That
author, even with all good intentions, may not be the most
reliable source of information.
As a personal example, I think I mentioned that I recently
received a query about what they believed to be an ambiguity in
RFC 1425. Now I have stayed around, know what has happened
since, and responded to the question by pointing the person who
asked to 5321 and suggesting the EMAILCORE list if they believed
there was still an ambiguity. But suppose that, sometime in
late 1993, I had decided I had had enough of email
specifications and the IETF generally, dropped out, and stopped
paying attention to any of this. Would we really, really, want
questions about variations on SMTP addressed to me in 2021?
(2) I don't know about your experience but, at the direction of
WGs for whom I've been acting as author/editor, I have sometimes
written things into documents that became RFCs with which I
profoundly disagree. In many cases, subsequent experience has
proven the WG to have been correct. In others, similar
experience shows that I was right in the first place. Now, with
the understanding that, in such situations "what do you think I
should do in case ABC?" and "what does the standard intend be
done in case ABC?" are different questions and that even the
person asking may not know the difference, how should the
author, especially an author who believe that that should not
write response more than 240 characters long, respond? "What
is the history of that particular decision" is yet another
question, one on which I'd assume the author would be
authoritative.
In both cases, if we were better at making notes when experience
and/or consensus changes and in making it obvious which
specifications, comments, updates, notes, etc., go together, we
would have fewer problems. AFAICT, we know of two ways to
provide that sort of information:
(a) Figure out better ways to index, collect, and/or annotate
the content of documents in ways that make relationships and
current thinking clear. The late (and lamented by some) efforts
of the NEWTRK WG proposed one or two ways to do this and,
although I don't remember its being explicitly proposed, those
documents could contain best current contact information for
documents or sets of them.
(b) More or less abandon the notion of static RFCs with fixed
number assignments as representations of our standards. That
could be done by adopting a model similar to ISO's in which (to
use historical examples I would not recommend trying to change)
the successor to specification 760:1980 would be 760:1981 (not
791) and the first update that does not completely replace the
base specification would be 760:1980-Amendment1 (or
"...-Amendment1(1992)", not 1349. Or we could go all the way to
expressing standards as living documents, updated in place any
time there was consensus about a change or correction and with
no notion of static documents other than tracking history.
Does that explain the concern better?
best,
john
