Found 1 record.
Status: Rejected (1)
RFC 5557, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", July 2009Source of RFC: pce (rtg)
Errata ID: 3672
Publication Format(s) : TEXT
Reported By: Cyril Margaria
Date Reported: 2013-06-27
Rejected by: Adrian Farrel
Date Rejected: 2013-10-04
Section 5 says:
The <svec-list> is changed as follows: <svec-list> ::= <SVEC> [<OF>] [<GC>] [<XRO>] [<svec-list>]
It should say:
The <svec-list> is changed as follows: <svec-list> ::= <SVEC> [<OF>] [<GC>] [<XRO>] [<metric-list>] [<svec-list>]
RFC5440 defines <svec-list>::=<SVEC>[<svec-list>]
RFC5541 extend <svec-list> as follows:
<svec-list> ::= <SVEC>
RFC5557 should include all the elements defined by the RFCs its extending.
The position of the metric-list may be kept after the [<OF>]
The essence of his report is that message definitions in RFCs should include all
elements of RBNF from the messages as defined in previous RFCs.
Discussion of this point in the PCE working group led to a debate about
whether the RBNF is normative and should be "compilable". Some hold the
view that being conservative in what you send and liberal in what you
receive could only make this text normative for building messages not
parsing them. Others noted that, as with RSVP, the object ordering is
advisory not mandatory except as where noted explicitly in the text.
It is also worth noting that as various documents are developed in parallel,
getting the RBNF right in the RFCs might require last-minute edits in Auth48
which is undesirable for a host of reasons. Others observed that there is no
expectation that authors will read RFC in numeric order and that the RBNF for a
new feature in PCEP applies to how that feature is added.
All this led to http://datatracker.ietf.org/doc/draft-cmfg-pce-pcep-grammar/
which is an experiment to determine whether it is possible to derive an
aggregated RBNF description for all PCEP messages. This might (if successful) go
on to form a type of message registry to act as a stable reference point.
In rejecting this Errata report I note that the reported error is not a typo,
but a deliberate decision of the authors and working group. The fix, therefore,
if it is to be applied needs to be achieved through a consensus document.