RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 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 (5)

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.

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



Search RFCs
Advanced Search
×