--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
