RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Verified (3)

RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010

Source of RFC: forces (rtg)

Errata ID: 2576
Status: Verified
Type: Editorial

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

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

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: Reported (2)

RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010

Source of RFC: forces (rtg)

Errata ID: 5363
Status: Reported
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2018-05-18

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: Reported
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2018-05-18

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).

Status: Held for Document Update (1)

RFC 5812, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", March 2010

Source of RFC: forces (rtg)

Errata ID: 5656
Status: Held for Document Update
Type: Editorial

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

Source of RFC: forces (rtg)

Errata ID: 2577
Status: Rejected
Type: Editorial

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.

Report New Errata