RFC Errata
Found 7 records.
Status: Verified (3)
RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010
Note: This RFC has been updated by RFC 7408
Source of RFC: forces (rtg)
Errata ID: 2576
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2010-10-17
Section Table 1 says:
| | | | information | | FE Protocol | 2 | [2] | Defines parameters | | Object | | | for the ForCES | | | | | protocol operation |
It should say:
| | | | information | | FE Protocol | 2 | RFC 5810 | Defines parameters | | Object | | | for the ForCES | | | | | protocol operation |
Notes:
Reference [2] used to be the reference to the I-D that became RFC 5810
Errata ID: 3371
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Evangelos Haleplidis
Date Reported: 2012-10-07
Verifier Name: Adrian Farrel
Date Verified: 2012-11-04
Throughout the document, when it says:
Page 65 Section 4.7.2 paragraph 1
<product> lists the allowed frame formats...
Page 95 Section 5.1
<xsd:element name="frameProduced">
It should say:
Page 65 Section 4.7.2 paragraph 1
<product> MAY lists the allowed frame formats...
Page 65 Section 4.7.2 paragraph 1 additional text at end of paragraph
The <product> element MUST contain at least either a frame format or a metadata.
Page 95 Section 5.1
<xsd:element name="frameProduced" minOccurs="0">
Notes:
Issue with frameProduced being mandatory for an output port.
Errata ID: 3487
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2013-02-18
Verifier Name: Adrian Farrel
Date Verified: 2013-02-19
Section 5.1 says:
<component access="read-only" componentID="7">
<name>FEState</name>
<synopsis>State of this FE</synopsis>
<typeRef>FEStateValues</typeRef>
</component>
It should say:
<component access="read-write" componentID="7">
<name>FEState</name>
<synopsis>State of this FE</synopsis>
<typeRef>FEStateValues</typeRef>
</component>
Notes:
FEObject FEState (component ID 7) is read-write. It was mistakenly
labelled read-only
Status: Held for Document Update (3)
RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010
Note: This RFC has been updated by RFC 7408
Source of RFC: forces (rtg)
Errata ID: 5363
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-18
Held for Document Update by: Alvaro Retana
Date Held: 2019-09-10
Section 3.2.8 says:
An interesting issue related to class inheritance is backward compatibility between a descendant and an ancestor class. Consider the following hypothetical scenario where a standardized LFB class "L1" exists. Vendor A builds an FE that implements LFB "L1", and vendor B builds a CE that can recognize and operate on LFB "L1". Suppose that a new LFB class, "L2", is defined based on the existing "L1" class by extending its capabilities incrementally. Let us examine the FE backward-compatibility issue by considering what would happen if vendor B upgrades its FE from "L1" to "L2" and vendor C's Halpern & Hadi Salim Standards Track [Page 29] RFC 5812 ForCES FE Model March 2010 CE is not changed. The old L1-based CE can interoperate with the new L2-based FE if the derived LFB class "L2" is indeed backward compatible with the base class "L1".
It should say:
An interesting issue related to class inheritance is backward compatibility between a descendant and an ancestor class. Consider the following hypothetical scenario where a standardized LFB class "L1" exists. Vendor A builds an FE that implements LFB "L1", and vendor B builds a CE that can recognize and operate on LFB "L1". Suppose that a new LFB class, "L2", is defined based on the existing "L1" class by extending its capabilities incrementally. Let us examine the FE backward-compatibility issue by considering what would happen if vendor A upgrades its FE from "L1" to "L2" and vendor B's Halpern & Hadi Salim Standards Track [Page 29] RFC 5812 ForCES FE Model March 2010 CE is not changed. The old L1-based CE can interoperate with the new L2-based FE if the derived LFB class "L2" is indeed backward compatible with the base class "L1".
Notes:
Confusion in the notation of vendors.
Errata ID: 5364
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-18
Held for Document Update by: Alvaro Retana
Date Held: 2019-09-10
Section 3.4.1 says:
(b) Using pure encoded state approach to represent the LFB topology in 5(a), if LFB#1, LFB#2, ..., and LFB#N are of the same type (e.g., meter).
It should say:
(b) Using pure encoded state approach to represent the LFB topology in 7(a), if LFB#1, LFB#2, ..., and LFB#N are of the same type (e.g., meter).
Notes:
Invalid reference to figure 5(a) instead of figure 7(a).
Errata ID: 5656
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2019-03-13
Held for Document Update by: Deborah Brungard
Date Held: 2019-05-30
Section 4.8.6 says:
<synopsis>
the path to the component target
each 4 octets is read as one path element,
using the path construction in the ForCES protocol,
[2].
</synopsis>
It should say:
<synopsis>
the path to the component target
each 4 octets is read as one path element,
using the path construction in the ForCES protocol,
[RFC5810].
</synopsis>
Notes:
Incorrect reference
Status: Rejected (1)
RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010
Note: This RFC has been updated by RFC 7408
Source of RFC: forces (rtg)
Errata ID: 2577
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Rejected by: Adrian Farrel
Date Rejected: 2011-07-24
Section global says:
I dont know where to capture this, but it needs to be captured somewhere and i couldnt think of a better place.. This is in regards to the XML definitions.. The baseID of events, componentIDs and capabilitiyIDs should be unique within the LFB. The schema now distinguishes per category, not globally.
It should say:
It would valuable to be able to validate via the schema that there is uniqueness.
Notes:
--VERIFIER NOTES--
This Erratum is rejected after consultation with the ForCES chair.
The LFB Class is unique globaly. The LFB instance is unique per LFB.
The LFB components are uniquely identified by LFB class::instance id.
Therefore by inference, the LFB events, componentIDs and capabilitiyIDs
are globaly unique.