Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)

joel jaeggli <joelja@bogus.com> Tue, 07 August 2012 02:06 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E677221F8666 for <v6ops@ietfa.amsl.com>; Mon, 6 Aug 2012 19:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.263
X-Spam-Level:
X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, 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 uS42+1vOqfoh for <v6ops@ietfa.amsl.com>; Mon, 6 Aug 2012 19:06:45 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB4221F8661 for <v6ops@ietf.org>; Mon, 6 Aug 2012 19:06:45 -0700 (PDT)
Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7724ta6056665 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 7 Aug 2012 02:04:55 GMT (envelope-from joelja@bogus.com)
Message-ID: <502077C6.2080609@bogus.com>
Date: Mon, 06 Aug 2012 19:04:54 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
References: <20120806142829.81256B1E003@rfc-editor.org> <F457181A-090E-4417-A4AD-3ADB7BE35BCE@cisco.com>
In-Reply-To: <F457181A-090E-4417-A4AD-3ADB7BE35BCE@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 07 Aug 2012 02:04:57 +0000 (UTC)
X-Mailman-Approved-At: Tue, 07 Aug 2012 08:53:28 -0700
Cc: v6ops v6ops WG <v6ops@ietf.org>, "livio.zanol.puppim@gmail.com" <livio.zanol.puppim@gmail.com>, Olaf Bonness <Olaf.Bonness@t-systems.com>, "cpopovic@cisco.com" <cpopovic@cisco.com>, "gunter@cisco.com" <gunter@cisco.com>
Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 02:06:46 -0000

On 8/6/12 10:28 AM, Fred Baker (fred) wrote:
> My perception: we should accept the erratum. Agree?
so my interpretation.

  3627 was moved to historic by 6547. 6164 allows the use of /127s...

5375 maybe wrong now but the reference to 3021 is temporally correct.

so yeah I guess.

  On Aug 6, 2012, at 7:28 AM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC5375,
>> "IPv6 Unicast Address Assignment Considerations".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5375&eid=3309
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Lívio Zanol Pereira de Souza Puppim <livio.zanol.puppim@gmail.com>
>>
>> Section: B.2.2
>>
>> Original Text
>> -------------
>> B.2.2. /127 Addresses
>>
>>
>>
>>    The usage of the /127 addresses, the equivalent of IPv4's RFC 3021
>>
>>    [RFC3021], is not valid and should be strongly discouraged as
>>
>>    documented in RFC 3627 [RFC3627].
>>
>> Corrected Text
>> --------------
>> B.2.2. /127 Addresses
>>
>>
>>
>>    The usage of the /127 addresses, the equivalent of IPv4's RFC 3021
>>
>>    [RFC3021], is valid as stated in RFC 6164 [RFC 6164].
>>
>> Notes
>> -----
>> Maybe just remove the section B.2.2?
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5375 (draft-ietf-v6ops-addcon-10)
>> --------------------------------------
>> Title               : IPv6 Unicast Address Assignment Considerations
>> Publication Date    : December 2008
>> Author(s)           : G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn
>> Category            : INFORMATIONAL
>> Source              : IPv6 Operations
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
> ----------------------------------------------------
> The ignorance of how to use new knowledge stockpiles exponentially.
>     - Marshall McLuhan
>