Hello guys.

Just to give you more information:
- RFC 5375 state that you should not use /127 address and makes a reference
to RFC 3627.

- RFC 6177 came out as a standard, and in section 4 states that RFCs 3627
and 5375 are potentially wrong, but did not make any recommendation about
it.

- RFC 6547 was published to overcome this error, and proposes that RFC 3627
should move to historic status, updating the RFC 6177, but again, did not
mention RFC 5375.

- An e-mail has been sent to the WG of the RFC 6547, but no answers were
given. (http://www.ietf.org/mail-archive/web/ipv6/current/msg16203.html)

- I've sent an erratum to RFC 5375 about this, which you guys are
discussing.

So, what to do next?
Publish an erratum in RFC 5375? Publish a RFC 6547-bis? Publish an update
to RFC 5375?

I really don't know. As I've stated in an e-mail to rfc-interest mailing
list, I'm just a reader and saw this /127 text while reading RFC 5375.

The only thing that I'm sure, is that other readers of RFC 5375 would not
want to know that the recommendation about /127, at B.2.2 sector is
misguided after they have elaborated an address assignment project.
Sometimes, you only read the text, and do not click on every RFC linked in
it.

I have full confidence in the WG, and I'm sure you will find the right
solution.

Thank you for your time. Best regards,

Lívio Zanol Puppim

2012/8/7 Ronald Bonica <rbonica@juniper.net>

> 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
>
>


--