Re: RFC6164 and 3627

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 29 September 2011 19:25 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70BF1F0C35 for <ipv6@ietfa.amsl.com>; Thu, 29 Sep 2011 12:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.582
X-Spam-Level:
X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p36bQUEqe6SO for <ipv6@ietfa.amsl.com>; Thu, 29 Sep 2011 12:25:16 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B47621F8E39 for <ipv6@ietf.org>; Thu, 29 Sep 2011 12:25:15 -0700 (PDT)
Received: by fxd18 with SMTP id 18so2336373fxd.31 for <ipv6@ietf.org>; Thu, 29 Sep 2011 12:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U713mxqIpUFm/lyEtJXs3WuRMcFk8gcv8V6j51h4wBY=; b=M/CHE5n1WyJ8nk+EE6gvOX0XDkaTxhe+o1wIQNdUc5596nX7eypxF5nn0gXEKfIZ/h byaGGo+Ab+h0vAgNJtISTCtG6SVeD7OVZ0yyCv5nq+QR4xwI2u+XAyOl8Pt3PA45oHtq A69ZCdO+6z/muRCkEycsEJWPwtGUhaefVIbkM=
Received: by 10.223.58.139 with SMTP id g11mr4469814fah.14.1317324487377; Thu, 29 Sep 2011 12:28:07 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id c1sm3347136fab.15.2011.09.29.12.28.03 (version=SSLv3 cipher=OTHER); Thu, 29 Sep 2011 12:28:05 -0700 (PDT)
Message-ID: <4E84C6BC.5070108@gmail.com>
Date: Fri, 30 Sep 2011 08:27:56 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "George, Wes" <wesley.george@twcable.com>
Subject: Re: RFC6164 and 3627
References: <34E4F50CAFA10349A41E0756550084FB0FC21D04@PRVPEXVS04.corp.twcable.com> <C282AE46CA180649B16227A97F76C6D413ADD927@EMAILHK2.jnpr.net> <34E4F50CAFA10349A41E0756550084FB0FD219D2@PRVPEXVS04.corp.twcable.com>
In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0FD219D2@PRVPEXVS04.corp.twcable.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2011 19:25:17 -0000

Wes,

You could simply ask the IESG to reclassify 3627 as Historic. This
could have been done when 6164 was approved, I guess.

However, a standards track document always trumps an informational
document in any formal context, and you can point that out to
customers.

Regards
   Brian Carpenter

On 2011-09-30 05:23, George, Wes wrote:
> Thanks for the quick response. However, IMO that's a pretty thin distinction that I do not believe will be obvious to those not involved in IETF who are looking for guidance on the matter. I have already had customers point to this conflict when we "wave RFCs at each other" to justify either using or not using a /127 on their PtP link. Is it actually forbidden to update an informational RFC with a standard's track one?
> 
> Thanks
> Wes
> 
> 
> From: Miya Kohno [mailto:mkohno@juniper.net]
> Sent: Thursday, September 29, 2011 10:15 AM
> To: George, Wes; 6man
> Subject: RE: RFC6164 and 3627
> 
> Hi Wes,
> 
> The discussion at that time was that 6164, which was in "standard track", did not have to update 3627 since it was "informational".
> 
> Thanks,
> Miya
> 
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of George, Wes
> Sent: Thursday, September 29, 2011 10:50 PM
> To: 6man
> Subject: RFC6164 and 3627
> 
> A (possibly stupid) question occurred to me today -
> 
> Why doesn't RFC6164 formally update RFC3627? As it stands, this either clarifies the existing guidance in 3627 or obsoletes it, but only includes 3627 as an informative reference. I don't remember there being much discussion about this particular aspect of the draft. I know there was lots of discussion about should/shouldn't use /127s, but not about this particular thing.
> 
> If we agree that 6164 should have updated 3627, how do we fix? Can this be handled as an errata filing on 6164, or do we have to write a 6164bis?
> 
> Thanks,
> 
> Wes George
> 
> 
> ________________________________
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------