Re: New Version Notification for draft-leiba-rfc2119-update-00.txt

Ted Lemon <mellon@fugue.com> Wed, 10 August 2016 12:35 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F97D12D79D for <ietf@ietfa.amsl.com>; Wed, 10 Aug 2016 05:35:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 tqpINngox1Hb for <ietf@ietfa.amsl.com>; Wed, 10 Aug 2016 05:35:00 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C946E12B028 for <ietf@ietf.org>; Wed, 10 Aug 2016 05:34:59 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id q128so90699399wma.1 for <ietf@ietf.org>; Wed, 10 Aug 2016 05:34:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2VpEc8kP8M5ln2gPfzIG0WF21/XVRpogywLMJn5SU1Q=; b=0S/c2X4WRLvaqN6Hl3bS9Ult57V2TO/AaanZtKR4ezfRyCxRs59YDlB8oUN7K5pPgU mgImO0CU2t3oqPmtyiuEtWVrA5CfxozVFLnF1sL4lxJ6lwQlsc83zse13XL9yzze7Poz PJHjXUAjwdj2rJd9HwkTc2c+e46CByn2REyO4RIWxzzOh15IzxONjcXDbBg22OtrgK3Z QCORRjh6OKMuLEUSELqCowBAUBtWsjBF/77FmR6iO/yDLDZN15QdIV+qsed9r+21TbT6 wm6G3ySMxO+ToenJrMVL98VDL/2QR1SibYBGLpohoy+TPzs19hVvCI+4j80lHD+srQio Z2Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2VpEc8kP8M5ln2gPfzIG0WF21/XVRpogywLMJn5SU1Q=; b=HwdnholfEYbcA2NLKbQcsZs77zqGMAw4flJEMjLJVvO+SpzEddZX/8VSopS0MnEeSk TXGvsgu8Ob7Rw3unfTBX7ITlV+kkTH9FIX8hoPonlmhGzSbL4E2Qa6dot2hcfZarur9V flPaaZ6i1nZlCE0Gp/mqWtxZuDrOO9FN7yWR0e6A9FDb8MwCATPazLb0/RCRu77bchCB SmBfITPgkVK9KmP+n4jw4PujAT4UCsPmCngY7qJpo9Q4Kj24hGszqsiTmV1ayV9ZcMJ3 O3l9B5EoApQj6ApUvXTQU5x981+JI9xh2ATs70RGK9YzNAUd+QWOW/tMOSJxzyn5xp8r zQwQ==
X-Gm-Message-State: AEkoouu85DiE3jgc0KdsoRyADVdg1nD+UYcHMAzRoBjQVao/4joHeKQfkfC2FI7jQ7qDLrZ/ESQSEw9YjniNKQ==
X-Received: by 10.25.91.149 with SMTP id p143mr604517lfb.39.1470832498173; Wed, 10 Aug 2016 05:34:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.217.93 with HTTP; Wed, 10 Aug 2016 05:34:17 -0700 (PDT)
In-Reply-To: <091c9c6b-41c8-3ab5-50d8-a9c4ec3bf97e@gmail.com>
References: <147077254472.30640.13738163813175851232.idtracker@ietfa.amsl.com> <CALaySJLHx7ytgZqZ9zQXA3vVSU-pNggQQs+QiDnzQ4tBEH5VAQ@mail.gmail.com> <23c809d5-a43d-59de-7e07-3b902848df20@gmail.com> <CAPt1N1=xUr8TD=Pv+Ajm3gTA-=0SmXXu5-+qdxc4gYLfMfnNHA@mail.gmail.com> <091c9c6b-41c8-3ab5-50d8-a9c4ec3bf97e@gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 10 Aug 2016 08:34:17 -0400
Message-ID: <CAPt1N1n4aBQriZg_+Jmv+Xm0FxCJVRKR_yfsf=pp18iYmExdqg@mail.gmail.com>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
To: Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: multipart/alternative; boundary=001a114124b49400a90539b6e0f4
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/kTknhoTR7HzlN9h7DRBVbkj9y1Q>
Cc: Barry Leiba <barryleiba@computer.org>, IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2016 12:35:01 -0000

I think the right thing for new documents to do is reference both 2119 and
this document, not _just_ this document.

On Wed, Aug 10, 2016 at 8:23 AM, Stewart Bryant <stewart.bryant@gmail.com>
wrote:

> That would be a satisfactory approach.
>
> However I suspect that just as IDs still put Network Working Group in the
> top left corner, so I suspect  RFC2119 will be the normal reference used.
>
> Stewart
>
> On 10/08/2016 13:19, Ted Lemon wrote:
>
> I think the right approach to take with this document is not as an
> explicit update to RFC 2119 text, but rather as a Talmudic commentary on
> RFC2119.   This document should do two things: it should help readers of
> old documents who are unclear about what 2119 says, and it should be
> available as a document that can be normatively reference by authors of new
> documents who want more clarity than RFC2119 provides.
>
> The document should be explicit that while it updates 2119, documents that
> refer only to 2119 and not to this document are not updated: if this
> document helps the reader to better understand the context in which the
> RFC2119 keywords are used, great, but nothing more than that is intended.
>
> For documents that do normatively reference this document and not just
> RFC2119, the update is normative.
>
> On Wed, Aug 10, 2016 at 7:47 AM, Stewart Bryant <stewart.bryant@gmail.com>
> wrote:
>
>>
>> Having thought a little more about this, I am wondering about
>> unintended consequences in the 5K documents that we have
>> written since RFC2119 was published.
>>
>> If we effectively change RFC2119 as we propose, is there
>> a danger that readers will incorrectly interpret old text
>> with new semantics. T
>>
>> I have no idea whether anything of significance will occur
>> but considering the thought put into terms like SHOULD
>> there exists a risk that would be mitigated if we picked
>> a new RFC number whereupon the reader would know
>> which definition the writers and reviewers were using.
>>
>> - Stewart
>>
>>
>>
>
>