Re: [Idr] [Editorial Errata Reported] RFC4360 (4944)

[Job Snijders <[e-mail]>]

On Thu, Feb 23, 2017 at 04:50:10PM -0500, John G. Scudder wrote:
> To save others the trouble of figuring out just exactly what this erratum even *is*: in the original text, the numbers in the diagram rulers align above the minus signs. In the "corrected" text they align above the plus signs. I would like to remind anyone who might submit an erratum in the future: please use the "notes" section to make it clear what your proposed change is, unless it's perfectly obvious.
> 
> Looking at https://www.ietf.org/iesg/statement/errata-processing.html, we have 
> 
> > 	• Rejected - The erratum is in error, or proposes a change to
> > 	the RFC that should be done by publishing a new RFC that
> > 	replaces the current RFC. In the latter case, if the change is
> > 	to be considered for future updates of the document, it should
> > 	be proposed using channels other than the errata process, such
> > 	as a WG mailing list. 
> > 	• Hold for Document Update - The erratum is not a necessary
> > 	update to the RFC. However, any future update of the document
> > 	might consider this erratum, and determine whether it is correct
> > 	and merits including in the update. 
> > ...
> > Guidelines for review are: 
> > 
> > 	5. Typographical errors which would not cause any confusions to
> > 	implementation or deployments should be Hold for Document
> > 	Update.
> 
> The erratum either is for a typographical error, in which case it
> should be Hold for Document Update, or it's in error, in which case it
> should be Rejected. The guidelines don't offer a "this is a matter of
> taste" option, which I think is what applies here, unless someone can
> cite an RFC Editor style guideline specifying that the rulers are
> supposed to have the numbers above the pluses?
> 
> Right now my inclination would be go with Reject, but if someone can
> cite evidence that the proposed fix is objectively more correct than
> the current text (or if the mood of the WG supports that option, for
> that matter) we could do Hold for Document Update instead.

The example provided in RFC 2360 is aligned with the currently published
text:

    https://tools.ietf.org/html/rfc2360#section-3.1

Kind regards,

Job