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

Hi Alice,

Thanks for this reminder! I will consult with the WG and IESG to make sure that nobody objects.

                   Ron

> -----Original Message-----
> From: Alice Russo [mailto:arusso@amsl.com]
> Sent: Tuesday, August 07, 2012 3:55 PM
> To: Ronald Bonica
> Cc: Brian E Carpenter; Fred Baker (fred); <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)
> 
> Ron,
> 
> > I will check with the RFC editor to see if it is OK to add an UPDATE
> in an errata.
> 
> 
> Please see this IESG statement: http://www.ietf.org/iesg/statement/rfc-
> metadata-errata.html.  If there is an errata report regarding the
> metadata of an RFC *and* the verifying party marks it as Verified, the
> RFC Editor will update the RFC's metadata accordingly (which appears in
> the RFC Index, info page, etc.).
> 
> Thank you.
> RFC Editor/ar
> 
> On Aug 7, 2012, at 11:36 AM, Ronald Bonica wrote:
> 
> > 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