RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 14 records.

Status: Verified (5)

RFC 5810, "Forwarding and Control Element Separation (ForCES) Protocol Specification", March 2010

Source of RFC: forces (rtg)

Errata ID: 2566
Status: Verified
Type: Editorial

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2010-10-17

Section Appendix A says:

In Appendix A in line 8:

 o  TLV Result Values, Section 7.1.7

It should say:

 o  RESULT-TLV Result Values, Section 7.1.7

Notes:

See Section A.5

Errata ID: 2568
Status: Verified
Type: Editorial

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2010-10-30

Section A.6. says:

A.6. Association Setup Response

a) So far the numbers are represented like:

0x0000   Success
0x0001   FE ID Invalid
etc.
b) we are only using 0x00000000-0x0000FFFF whereas the 32-bit
space covers 0x00000000-0xFFFFFFFF. 

It should say:

a) Since this is a 32 bit space and not 16 bit a proper representation
would have 8 hexadecimal  numbers and would look like:
0x00000000   Success
0x00000001   FE ID Invalid

b)We need to specify that anything from 0x00010000-0xFFFFFFFF is reserved.

Notes:

IANA will update the registry in line with this Erratum

Errata ID: 2574
Status: Verified
Type: Editorial

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2010-10-18

Section Appendix D says:

Note 1:   This emulates adding a new nexthop entry and then
          atomically updating the L3 entries pointing to an old NH to
          point to a new one.

It should say:

Note 1:   This emulates adding a new nexthop entry and then
          atomically updating the L3 entry that pointed to the
          old NH to point to the new one.

Notes:

Example 13 text (not the example) claims you can use a single KEYINFO to
match multiple L3 entries.
You cannot use KEYINFO to match multiple table entries. The model
RFC 5812 section 4.5.3 is clear that you can only match one entry.

Errata ID: 2575
Status: Verified
Type: Editorial

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Verifier Name: Adrian Farrel
Date Verified: 2011-05-08

Throughout the document:

 There is some confusion in the way we describe the HA bits.

It should say:

Suggestions made by Evangelos Haleplidis for global consitency.
i. For consistency of terms:

Change word "stage" of page 17 to "phase".

ii. Change the start of section 4.2.2.3 from:
"In this stage..."
To:
"Entering this stage..."

iii.  Change the text in section 8 from:
"Figure 44 extends the state machine illustrated in Figure 4 to 
allow for new states that facilitate connection recovery."
To:
"Figure 44 changes the state machine illustrated in Figure 4 to specify 
states that facilitate connection recovery."

Also add the following text right after that:
"In this figure, the pre-association phase and the Association Setup 
Stage are merged in one state and Association Lost stage is included 
in the Not Associated state."

iv. Alter wording in Figure 44 in Page 84.
Where it says: 
"CE issues Association Setup"
Change to:
"CE issues Association Setup Response"

Notes:

Changes i through iii are entirely editorial and helf clarity in reading.

Change iv fixes a message name that might be confusing.

Errata ID: 4188
Status: Verified
Type: Editorial

Reported By: Francois-Xavier Le Bail
Date Reported: 2014-11-21
Verifier Name: Adrian Farrel
Date Verified: 2014-12-05

Section A.5. says:

                0x12        E_E_INVALID_FLAGS

It should say:

                0x12        E_INVALID_FLAGS

Notes:

The 'E_INVALID_FLAGS' is defined in 'section 7.1.7 RESULT TLV'.

The same problem exist in IANA Protocol Registries database at
http://www.internetassignednumbersauthority.org/assignments/forces/forces.xhtml#tlv-types because the typo occurs in 'Appendix A. IANA Considerations'

Status: Held for Document Update (8)

RFC 5810, "Forwarding and Control Element Separation (ForCES) Protocol Specification", March 2010

Source of RFC: forces (rtg)

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

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel

Section Appendix A.5 says:


The RESULT-TLV RTesult Value is an 8-bit value

It should say:

The RESULT-TLV Result Value is an 8-bit value.

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

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel

Section A.1 says:

Section A.1. Message Type Namespace, a typo 

  0x0F               Hearbeat

It should say:

should be:
  0x0F               Heartbeat

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

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel

Section 7.1.6 says:

multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can

It should say:

multiple errors in a single leaf PATH-DATA/FULLDATA-TLV, the FE can

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

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel

Section global says:

The text on KEYINFO-TLV examples could be a little confusing.

The grammar is:
KEYINFO-TLV := KeyID FULLDATA-TLV
where the FULLDATA-TLV carries the KEYDATA. 
However, the examples dont show the text as being carried in the
FULLDATA-TLV instead they would show something along the lines of:
KEYINFO-TLV = KeyID=1, KEY_DATA=100

It should say:

The best way to represent this is:
KEYINFO-TLV, V= {1, FULLDATA-TLV V={100}}

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

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Held for Document Update by: Adrian Farrel
Date Held: 2010-10-17

Section 7.2 and App D. says:

Section 7.2
KEY_ID  (in two places)


Appendix D
KEYDATA

It should say:

Section 7.2
KeyID   (both times)


Appendix D
KEY_DATA

Notes:

There is some small inconsistency in spelling the terms
KeyID and KeyData. Sometimes the text refers to KEY_ID and
KEY_DATA and sometimes KeyID and KEYDATA.

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

Reported By: Nikolai Malykh
Date Reported: 2018-05-06
Held for Document Update by: Alvaro Retana
Date Held: 2018-05-07

Section 7.6.1 says:

   Type:

   The operation type for Config message.  Two types of operations for
   the Config message are defined:

       Type = "SET" - This operation is to set LFB components

       Type = "SET-PROP" - This operation is to set LFB component
              properties.

       Type = "DEL" - This operation is to delete some LFB components.

       Type = "COMMIT" - This operation is sent to the FE to commit in a
              2pc transaction.  A COMMIT TLV is an empty TLV, i.e., it
              has no "V"alue.  In other words, there is a length of 4
              (which is for the header only).

       Type = "TRCOMP" - This operation is sent to the FE to mark the
              success from an NE perspective of a 2pc transaction.  A
              TRCOMP TLV is an empty TLV, i.e., it has no "V"alue.  In
              other words, there is a length of 4 (which is for the
              header only).

It should say:

   Type:

   The operation type for Config message.  Five types of operations for
   the Config message are defined:

       Type = "SET" - This operation is to set LFB components

       Type = "SET-PROP" - This operation is to set LFB component
              properties.

       Type = "DEL" - This operation is to delete some LFB components.

       Type = "COMMIT" - This operation is sent to the FE to commit in a
              2pc transaction.  A COMMIT TLV is an empty TLV, i.e., it
              has no "V"alue.  In other words, there is a length of 4
              (which is for the header only).

       Type = "TRCOMP" - This operation is sent to the FE to mark the
              success from an NE perspective of a 2pc transaction.  A
              TRCOMP TLV is an empty TLV, i.e., it has no "V"alue.  In
              other words, there is a length of 4 (which is for the
              header only).

Notes:

The number of types is incorrect (two instead of five).

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

Reported By: Nikolai Malykh
Date Reported: 2018-05-06
Held for Document Update by: Alvaro Retana
Date Held: 2018-05-07

Section 7.6.2 says:

   Type:
          The operation type for Config Response message.  Two types of
          operations for the Config Response message are defined:

       Type = "SET-RESPONSE" - This operation is for the response of the
              SET operation of LFB components.

       Type = "SET-PROP-RESPONSE" - This operation is for the response
              of the SET-PROP operation of LFB component properties.

       Type = "DEL-RESPONSE" - This operation is for the response of the
              DELETE operation of LFB components.

       Type = "COMMIT-RESPONSE" - This operation is sent to the CE to
              confirm a commit success in a 2pc transaction.  A
              COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating
              success or failure.

It should say:

   Type:
          The operation type for Config Response message.  Four types of
          operations for the Config Response message are defined:

       Type = "SET-RESPONSE" - This operation is for the response of the
              SET operation of LFB components.

       Type = "SET-PROP-RESPONSE" - This operation is for the response
              of the SET-PROP operation of LFB component properties.

       Type = "DEL-RESPONSE" - This operation is for the response of the
              DELETE operation of LFB components.

       Type = "COMMIT-RESPONSE" - This operation is sent to the CE to
              confirm a commit success in a 2pc transaction.  A
              COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating
              success or failure.

Notes:

The number of types is incorrect (two instead of four).

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

Reported By: Nikolai Malykh
Date Reported: 2018-05-07
Held for Document Update by: Alvaro Retana
Date Held: 2018-05-07

Section Appendix B says:

         <events baseID="61">
           <event eventID="1">
             <name>PrimaryCEDown</name>
             <synopsis>
                 The pimary CE has changed
             </synopsis>
             <eventTarget>
                 <eventField>LastCEID</eventField>
             </eventTarget>
             <eventChanged/>
             <eventReports>
                <eventReport>
                  <eventField>LastCEID</eventField>
                </eventReport>
             </eventReports>
           </event>
         </events>

       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>

It should say:

         <events baseID="61">
           <event eventID="1">
             <name>PrimaryCEDown</name>
             <synopsis>
                 The primary CE has changed
             </synopsis>
             <eventTarget>
                 <eventField>LastCEID</eventField>
             </eventTarget>
             <eventChanged/>
             <eventReports>
                <eventReport>
                  <eventField>LastCEID</eventField>
                </eventReport>
             </eventReports>
           </event>
         </events>

       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>

Notes:

A typo in the word ¨primary¨.

Status: Rejected (1)

RFC 5810, "Forwarding and Control Element Separation (ForCES) Protocol Specification", March 2010

Source of RFC: forces (rtg)

Errata ID: 2570
Status: Rejected
Type: Editorial

Reported By: Jamal Hadi Salim
Date Reported: 2010-10-16
Rejected by: Adrian Farrel
Date Rejected: 2010-10-18

Section Figure 1 says:


Figure 1 does not have a line joining CE2 and FE2 with Fp..

It should say:

Figure 1 should have a line joining CE2 and FE2 with Fp..

Notes:

This is just a description of how to fix.
I think this form can be improved so i can
enter descriptive text instead of s/orig/new approach
--VERIFIER NOTES--
After discussion with the WG, it was agreed that the figure deliberately reproduces a figure from RFC 3746 and should be left unchanged.

Report New Errata