Re: [yam] [Technical Errata Reported] RFC6409 (3995)

John C Klensin <john-ietf@jck.com> Fri, 23 May 2014 23:51 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: yam@ietfa.amsl.com
Delivered-To: yam@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D631A017E for <yam@ietfa.amsl.com>; Fri, 23 May 2014 16:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level:
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yGpe83XhnbV for <yam@ietfa.amsl.com>; Fri, 23 May 2014 16:51:57 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB47C1A017D for <yam@ietf.org>; Fri, 23 May 2014 16:51:56 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WnzEp-000Iap-Ld; Fri, 23 May 2014 19:51:00 -0400
Date: Fri, 23 May 2014 19:51:35 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>, Randall Gellens <rg+ietf@qualcomm.com>
Message-ID: <E45DDA85C9C092E7F6D7EF90@[192.168.1.102]>
In-Reply-To: <CALaySJKCTkk7A=c83VJxwxpyZyDRN6oQcmDJc2NP26e0+HmFKw@mail.gmail.com>
References: <20140522105930.779E218000D@rfc-editor.org> <p06240600cfa513ac7ab4@99.111.97.136> <1CD96F1912CBFF4A6A296711@192.168.1.102> <p06240604cfa5730dd57a@99.111.97.136> <CALaySJKCTkk7A=c83VJxwxpyZyDRN6oQcmDJc2NP26e0+HmFKw@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/yam/6kNpFE-nncj_-UK3E5VvTDBF1l8
Cc: yam@ietf.org, presnick@qti.qualcomm.com, sm+ietf@elandsys.com, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [yam] [Technical Errata Reported] RFC6409 (3995)
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam/>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 23:51:58 -0000


--On Friday, 23 May, 2014 18:01 -0400 Barry Leiba
<barryleiba@computer.org> wrote:

> Is it sufficiently important to add the note that I should ask
> the RFC Editor to pull it back, so I can add the note and
> re-verify?

Depends...

If you expect that Randy and/or myself will revise the doc
within the next year or two, this discussion thread suffices and
there is no need to do anything else -- not going to forget any
time soon.  I imagine we could quibble about the text and spin
up a version with the change in less time than we've spent on it
in the last week, but getting it through Last Call and approved
(and preventing that from turning into a debate about the
fundamental philosophy of email and its relationship to the DNS
and the differences in character among the three Pu-ers I got to
compare yesterday) would be your problem, not ours.

Almost the same answer applies if the expectation is that the
spec will never be revised: IMnvHO, we are spending a lot of
time hair-splitting about fussy original text for which a
careful reading of 5321 (without which anyone trying to do much
with 6409 is in big trouble anyway), good sense, and operational
experience and necessity will almost always provide the right
answer.

On the other hand, if you expect there to ultimately be a
revision by someone with no memory of active participation in
YAM, done after Randy and I are sufficiently retired to be
unlikely to a review and/or have forgotten all about this, then,
yes, let's erect a large sign that effectively says "the
original text is defective, the proposed change isn't quite
right, and someone revising the spec better dig through old
email messages and think carefully about exactly what to say and
how".

best,
    john