Re: Proposed ietf.org email address policy

[Aqua Q Glass <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> --On Sunday, 13 June, 2021 13:14 +0100 Stephen Farrell
> <[e-mail]> 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
>
>
>
>
>