Re: [Gen-art] Gen-ART review of draft-ietf-avtext-avpf-ccm-layered-03

worley@ariadne.com (Dale R. Worley) Mon, 05 December 2016 20:05 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9083A129CC4 for <gen-art@ietfa.amsl.com>; Mon, 5 Dec 2016 12:05:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 R_IBae10Gim7 for <gen-art@ietfa.amsl.com>; Mon, 5 Dec 2016 12:05:20 -0800 (PST)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 74AEE129CC5 for <gen-art@ietf.org>; Mon, 5 Dec 2016 12:05:20 -0800 (PST)
Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-03v.sys.comcast.net with SMTP id DzVWczP4VMppVDzVncJF8P; Mon, 05 Dec 2016 20:05:19 +0000
Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-14v.sys.comcast.net with SMTP id DzVmcngY3ijl5DzVmcOOz7; Mon, 05 Dec 2016 20:05:19 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uB5K5HAc019039; Mon, 5 Dec 2016 15:05:17 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uB5K5GWQ019036; Mon, 5 Dec 2016 15:05:16 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Stephan Wenger <stewe@stewe.org>
In-Reply-To: <810DE8E7-346D-4FB5-915C-E5A47211E0B8@stewe.org>
Sender: worley@ariadne.com
Date: Mon, 05 Dec 2016 15:05:16 -0500
Message-ID: <87mvgai1kz.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfCfsurfAyDSzUP8spe5WkZTYflYTI4rEuq8xD+HQ3ws3HSrJB65+ws9ItMcjK/jUpWCuo3vNMk8OTIUxkK1WbO0QuRz7mdQNnIumP1TDyamSaGMe0caI y7w1ObZ8uNbhmieM2oPX86er5D4HbXgiAxjruMA+GIj4ZoNF6UIW62mikL/d08FkcM148q7OJo4XLyGJrnrcGj34AKN88quGHZy/zW5wlS4aGiOPKVwjvXdV g2ONqP7SGE/hustbo+T6Nn1bvAq+XfZ3Wsb8xb8RfajvflyGZLyD5rLJM+bQi64ZqDCcX9l1IcU1C0oQKquj8Q==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/UVIKdfyxhQM57ePiuEyxFntHWHs>
Cc: draft-ietf-avtext-avpf-ccm-layered.all@ietf.org, gen-art@ietf.org
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-avtext-avpf-ccm-layered-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2016 20:05:21 -0000

Stephan Wenger <stewe@stewe.org> writes:
> Compared to certain other SDOs, IETF RFCs
> commonly contain a lot of explanatory text, examples and such, which
> is most often purely informative.  If such text were collected in
> distinct sections, I believe it is a good (and unfortunately
> underutilized) idea to label those sections as informative.

As you say, it's very common to have sections of documents from other
SDOs marked "non-normative" or "This section is not normative."  It's
less common to put such an annotation in the section title, but we did
that in RFC 7462 to make sure the reader wouldn't make a mistake:

   12.  Non-normative Algorithm for Handling Combinations of URNs

   The following text is a non-normative example of an algorithm for
   handling combinations of URNs that complies with the rules in
   Sections 10 and 11.  Thus, it demonstrates that the rules are
   consistent and implementable.  (Of course, a device may use any other
   algorithm that complies with Sections 10 and 11.)

Dale