RFC Errata
Found 14 records.
Status: Verified (5)
RFC 5810, "Forwarding and Control Element Separation (ForCES) Protocol Specification", March 2010
Note: This RFC has been updated by RFC 7121, RFC 7391
Source of RFC: forces (rtg)
Errata ID: 2566
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 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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Note: This RFC has been updated by RFC 7121, RFC 7391
Source of RFC: forces (rtg)
Errata ID: 2567
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Note: This RFC has been updated by RFC 7121, RFC 7391
Source of RFC: forces (rtg)
Errata ID: 2570
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
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.