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

Brian,

I agree that Errata 3309 should be put into the "hold for update" state, because RFC 5375 was not wrong when it was published. 

However, we need to figure out what to do about RFC 6164. I dimly recall a conversation about this when RFC 6164 was published. The consensus was that RFC 6164 trumps RFC 5375 because the former is on the Standards Track while the later is only INFORMATIONAL. So, RFC 6164 doesn't need to update RFC 5375.

Looking back on it, this argument is weak. How would the reader of 5375 know that RFC 6164 exists if it weren't for the update information in the metadata?

I will check with the RFC editor to see if it is OK to add an UPDATE in an errata.

                                               Ron

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Brian E Carpenter
> Sent: Tuesday, August 07, 2012 1:59 PM
> To: Fred Baker (fred)
> Cc: <v6ops@ietf.org>; <livio.zanol.puppim@gmail.com>;
> <fred.baker@cisco.com>; <Olaf.Bonness@t-systems.com>;
> <cpopovic@cisco.com>; <gunter@cisco.com>; RFC Errata System
> Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)
> 
> Wait a minute.
> 
> How can this be described as an error in 5375? 5375 was not wrong when
> published.
> 
> The error was in 6164, which failed to formally update 5375.
> 
> Surely this is a "hold for update" not "verified".
> 
> Regards
>    Brian
> 
> On 07/08/2012 16:23, Fred Baker (fred) wrote:
> > We agree that this erratum is valid.
> >
> > 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
> >
> >
> >
> > ---------------------------------------------------------------------
> -
> > --
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops