Subject: [Idr] [Technical Errata Reported] RFC4271 (3673)

From: William McCall <[email-masked]>
Date: Mon, 20 Jan 2014 19:38:57 +0000

Hello all--

I am following up this proposed erratum since it recently noticed it got
rejected and the verification does not match the proposed erratum. I am
looking into clarification of the verification and/or maybe accepting this
erratum.

The proposed erratum (very nitpicky, apologies in advance) concerns the
listing of the types of path attributes in section 5. In it, it states that
path attributes are either well known mandatory, discretionary, optional
transitive or optional non-transitive.

There is a distinct exception which I call out to LOCAL_PREF which is
neither well known mandatory nor well known discretionary (but certainly
well known per its definition in 5.1.5). As such, my proposal is to correct
the list to include simply "well-known" as an attribute type. An
alternative could be to call out the special categorization of LOCAL_PREF
after the list or something similar.

In the verification, the reason for rejection is:

"-- --VERIFIER NOTES--
This erratum was discussed on the IDR list.

The consensus was that whilst an alternative is to revert
from OpenSent to Idle on event 18 at that point, this was not
what was decided when RFC4271 was being produced, and
no one saw a good engineering reason to change it at this
stage.

On a matter of process, this proposal is not an Erratum
as the IETF sees it but an engineering change.

The submitter is, of course, welcome to submit a draft
proposing this change to RFC 4271 and the to discuss the
merits of the change with the IDR Working Group. "

This verification is inappropriate for a few reasons:

1) Errata 3673 has never been discussed on list.
2) OpenSent is not a state that a speaker will be in when sending or
receiving updates
3) Event 18 is for TcpConnectionFails, which is never addressed nor
particularly relevant to path attributes.

It appears that this verification was intended for erratum 3366, which is
the one that is before the one I submitted in the list. It does address the
behavior in OpenSent when event 18 occurs.

So, my questions for the list are:

1) Does this verification look incorrect? If not can this be corrected with
the consensus?
2) Is the proposed erratum intended to be rejected?

Thanks!

-- 
William McCall