Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP

Eric Rosen <erosen@cisco.com> Wed, 28 February 2007 20:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVrZ-0008K0-72; Wed, 28 Feb 2007 15:57:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVrQ-0008GX-QL for ietf@ietf.org; Wed, 28 Feb 2007 15:57:17 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMVqv-0001R8-6S for ietf@ietf.org; Wed, 28 Feb 2007 15:57:16 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Feb 2007 15:56:45 -0500
X-IronPort-AV: i="4.14,232,1170651600"; d="scan'208"; a="53797240:sNHT41099644"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1SKuiMk025983; Wed, 28 Feb 2007 15:56:44 -0500
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1SKuiOA004599; Wed, 28 Feb 2007 15:56:44 -0500 (EST)
To: ietf@ietf.org
In-reply-to: Your message of Fri, 16 Feb 2007 11:02:24 -0500. <E1HI5XU-0007M1-72@stiedprstage1.ietf.org>
Date: Wed, 28 Feb 2007 15:56:44 -0500
Message-ID: <10632.1172696204@cisco.com>
From: Eric Rosen <erosen@cisco.com>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1572; t=1172696204; x=1173560204; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20<erosen@cisco.com> |Subject:=20Re=3A=20Last=20Call=3A=20draft-klensin-norm-ref=20(Handling=2 0Normative=20References=20for=20Standards=20Track=20Documents)=20to=20BCP= 20 |Sender:=20 |To:=20ietf@ietf.org; bh=NSOAG8n+EA5CzYI9iEOW6YFgxs6a2zxolro066QEYEg=; b=SpC+J+On6GcF2dKKm7qS3cNt2jYqX1Te/ngJwc377GpxWPwbFZfL+2/8PVOx5RNkr0JnNoah yB+LAvz16xbqQa03szOU6F3VIYp+b4qaWDVJkOpewX1HVXLAEbwY353S;
Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Subject: Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: erosen@cisco.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

This document has a reasonable goal, but the implementation is objectionable.

The reasonable goal (from the introduction): 

    This document replaces the "hold on normative reference" rule with a
    "note downward normative reference and move on" approach for
    normative references to standards-track documents and BCPs.

The objectionable implementation: 

      A note is included in the reference text that indicates that the
      reference is to a target document of a lower maturity level, that
      some caution should be used since it may be less stable than the
      document from which it is being referenced

In many  cases (probably  the vast majority)  where a document  is advancing
despite a "downward normative reference", the referenced document (and the
technology  described  therein)  is  no  less stable  than  the  referencing
document, and  no "caution" is required.  It's  great to be able  to "make a
downward reference and move on", but  we should not be required to tell lies
and spread FUD.  

An acceptable implementation would be: 

      A note is included in the reference text that indicates that the
      reference is to a target document which is at a prior step in the
      official IETF standardization process.

That statement adequately captures the facts, and does not require the WG to
make dishonest statements or to spread FUD.

Another alternative, probably a better one, is simply to annotate each
reference with its standards status, and make no editorial comment about it
at all.



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf