Re: Revision of RFC 7302

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 03 May 2016 00:12 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCE012D53B for <urn-nid@ietfa.amsl.com>; Mon, 2 May 2016 17:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 0cbNi7DZCfUQ for <urn-nid@ietfa.amsl.com>; Mon, 2 May 2016 17:12:19 -0700 (PDT)
Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF63712D6A7 for <urn-nid@ietf.org>; Mon, 2 May 2016 17:12:19 -0700 (PDT)
Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by comcast with SMTP id xNwkaydZE7xvbxNwpagPnf; Tue, 03 May 2016 00:12:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1462234339; bh=UQlhhpRtRMJLRjKn3LxyjTf7ZESgkk23hp77MAeoZ8s=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=E9dmQXYq56e/igb8NAuD60w5BTyMjaDda2UaNIQoO/Qo3hs47sSf4gzvSElZJe0G9 yASIwgcIiI3V0+5+1VT8DCYHOfu4NYmyq6JxpFWz3xLLpYhGFIDG5tSKMYfNkk2ek6 cK6n2Njx8s2sY//oZEsHbl9Yo7G/q0ypugVI16C6krl8voQkq0Pn2w6ZnRaaGtktVw PvTUBQAhNIbmzIiu0pBGd515chZPLL0uQvG/TKIEFVExnfN3mD2m4890cjdrVPQddm QDtrSA+JN8Cyo036BDl1CxUa8d7pxYMJBELwNXcFSkMq9JNRjmJdvCbV+YK+gt3Kgk nG5K4K/7cjINQ==
Received: from Paul-Kyzivats-MacBook-Pro.local ([107.1.110.101]) by resomta-po-04v.sys.comcast.net with comcast id pcCJ1s00L2BJGiK01cCJRe; Tue, 03 May 2016 00:12:19 +0000
Subject: Re: Revision of RFC 7302
To: urn-nid@ietf.org
References: <CAF_7JxBSXo-EjC3-11Yop5W_Sgo4mWoPvb7SGxH90V9QVHPbUw@mail.gmail.com> <CA+9kkMD=ArH=Y+WxQ-SJ0m3Y3Ka-4pZQhtvifx5H9aAZUqv9XA@mail.gmail.com> <CAF_7JxBO29RGMSwvniEqTiidOFguZ=FQU99GaYTgHvdoSjVqKQ@mail.gmail.com> <CA+9kkMBCSp+PHnBOnu+Tim+DTK8j7vfNC1sXVTB2P_VxXqPhxw@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <90968eb5-6fee-bc65-a3ae-ef8d0128a820@alum.mit.edu>
Date: Mon, 02 May 2016 20:12:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CA+9kkMBCSp+PHnBOnu+Tim+DTK8j7vfNC1sXVTB2P_VxXqPhxw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/fWogNsprEpKRA9Ek8WyaUgldKzE>
X-Mailman-Approved-At: Tue, 03 May 2016 10:19:29 -0700
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2016 00:12:21 -0000

On 5/2/16 4:34 PM, Ted Hardie wrote:

>     If the "obsolete" path is chosen, perhaps there is a way to explicitly
>     highlight the (very limited) changes, beyond the short description in
>     the abstract?
>
> You can include an appendix with a list of the changes.  That's
> non-normative,
> but it would likely be consulted by anyone who wanted to simply check on the
> relationship between the two.

The trouble I have with this approach is that a reviewer must either 
*trust* that the summary is right, or else must check that there aren't 
other changes. If I am doing a serious review I would never have this 
level of trust.)

Doing the latter depends on the size of the document and how extensive 
the changes (even superficial ones) are.

I would be inclined to first try rfcdiff between the two documents. 
Sometimes this can work if the changes are really minor. But more likely 
there will be enough superficial changes that the diff is a mess and you 
can't easily distinguish the superficial changes from the substantial ones.

	Thanks,
	Paul