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

["Fred Baker (fred)" <[e-mail]>]

That seems to be a reasonable solution.

On Aug 8, 2012, at 6:43 AM, Ronald Bonica wrote:

Livo,

RFC 6164 speaks directly to the /127 issue. So, it seems that 6164 should have updated 5375. If we issue an errata against 6164 that causes 6164 to update 5375, would that fix the problem?

                                                                                                                                             Ron


From: Livio Zanol Puppim [mailto:[e-mail]]
Sent: Tuesday, August 07, 2012 7:08 PM
To: Ronald Bonica
Cc: Alice Russo; Brian E Carpenter; Fred Baker (fred); <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>; RFC Errata System
Subject: Re: [v6ops] [Technical Errata Reported] RFC5375 (3309)

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 <[e-mail]<mailto:[e-mail]>>
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:[e-mail]<mailto:[e-mail]>]
> Sent: Tuesday, August 07, 2012 3:55 PM
> To: Ronald Bonica
> Cc: Brian E Carpenter; Fred Baker (fred); <[e-mail]<mailto:[e-mail]>>;
> <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>;
> <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>;
> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On
> >> Behalf Of Brian E Carpenter
> >> Sent: Tuesday, August 07, 2012 1:59 PM
> >> To: Fred Baker (fred)
> >> Cc: <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>;
> >> <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>;
> >> <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>>; 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
> >>>> <[e-mail]<mailto:[e-mail]>>
> >>>>
> >>>> 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
> >>> [e-mail]<mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]<mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/v6ops



--

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially.
   - Marshall McLuhan