I'm with John in believing that there isn't enough of a problem to justify any sort of change. In fact I'll go further and say that I think we have achieved, perhaps unintentionally, a pretty effective balance, where authors can be contacted, albeit with some effort, with effort increasing as specifications age. Like it or not, there are cranks out there, and sadly they can appear on both sides of the equation. (This not to say this has happened in the case of RFC authors - AFAIK it hasn't yet - but it most certainly has been a problem with authors of important documents in other disciplines.) Ned > --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
