RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Held for Document Update (4)

RFC 3746, "Forwarding and Control Element Separation (ForCES) Framework", April 2004

Source of RFC: forces (rtg)

Errata ID: 5337
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09

Section 5 says:

   [4] Section 5, requirement #9 dictates "Any proposed ForCES

It should say:

   [4] Section 4, requirement #9 dictates "Any proposed ForCES

Notes:

Incorrect reference to Section 5.

[Additional notes added at status change]
In fact The 5 to 4 change need to also be applied to these:
(see [4], Section 5, requirement #6)
(see [4] Section 5, requirement #11)
(See [4], Section 5, Requirement #3)
(see [4] Section 5, requirement #1)
(see [4] Section 5, requirements #12)
(see [4] Section 5, requirement #7)

Errata ID: 5338
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09

Section 3.2 says:

   a change via asynchronous messages (see [4], Section 5, requirement
   #6).
...
   This architecture permits multiple FEs to be present in an NE.  [4]
   dictates that the ForCES Protocol must be able to scale to at least
   hundreds of FEs (see [4] Section 5, requirement #11).  Each of these
   FEs may potentially have a different set of packet processing
...
   When multiple FEs are present, ForCES requires that packets must be
   able to arrive at the NE by one FE and leave the NE via a different
   FE (See [4], Section 5, Requirement #3).  Packets that enter the NE

It should say:

   a change via asynchronous messages (see [4], Section 4, requirement
   #6).
...
   This architecture permits multiple FEs to be present in an NE.  [4]
   dictates that the ForCES Protocol must be able to scale to at least
   hundreds of FEs (see [4] Section 4, requirement #11).  Each of these
   FEs may potentially have a different set of packet processing
...
   When multiple FEs are present, ForCES requires that packets must be
   able to arrive at the NE by one FE and leave the NE via a different
   FE (See [4], Section 4, Requirement #3).  Packets that enter the NE

Notes:

Incorrect reference to Section 5.

see also: https://www.rfc-editor.org/verify_errata_select.php?eid=5338

Errata ID: 5339
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09

Section 4.2.1 says:

   The ForCES Working Group has made a conscious decision that the first
   version of ForCES will be focused on "very close" CE/FE localities in
   IP networks.  Very Close localities consist of control and forwarding
   elements that are either components in the same physical box, or
   separated at most by one local network hop ([8]).  CEs and FEs can be
   connected by a variety of interconnect technologies, including
   Ethernet connections, backplanes, ATM (cell) fabrics, etc.  ForCES
   should be able to support each of these interconnects (see [4]
   Section 5, requirement #1).  When the CEs and FEs are separated
   beyond a single L3 routing hop, the ForCES Protocol will make use of
   an existing RFC 2914 [3] compliant L4 protocol with adequate
   reliability, security, and congestion control (e.g., TCP, SCTP) for
   transport purposes.

It should say:

   The ForCES Working Group has made a conscious decision that the first
   version of ForCES will be focused on "very close" CE/FE localities in
   IP networks.  Very Close localities consist of control and forwarding
   elements that are either components in the same physical box, or
   separated at most by one local network hop ([8]).  CEs and FEs can be
   connected by a variety of interconnect technologies, including
   Ethernet connections, backplanes, ATM (cell) fabrics, etc.  ForCES
   should be able to support each of these interconnects (see [4]
   Section 4, requirement #1).  When the CEs and FEs are separated
   beyond a single L3 routing hop, the ForCES Protocol will make use of
   an existing RFC 2914 [3] compliant L4 protocol with adequate
   reliability, security, and congestion control (e.g., TCP, SCTP) for
   transport purposes.

Notes:

https://www.rfc-editor.org/errata/eid5337

Errata ID: 5340
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09

Section 4.3 says:

   FEs and CEs may join and leave NEs dynamically (see [4] Section 5,
   requirements #12).  When an FE or CE leaves the NE, the association
   with the NE is broken.  If the leaving party rejoins an NE later, to
   re-establish the association, it may need to re-enter the pre-
   association phase.  Loss of association can also happen unexpectedly
   due to a loss of connection between the CE and the FE.  Therefore,
   the framework allows the bi-directional transition between these two
   phases, but the ForCES Protocol is only applicable for the post-
   association phase.  However, the protocol should provide mechanisms
   to support association re-establishment.  This includes the ability
   for CEs and FEs to determine when there is a loss of association
   between them, and to restore association and efficient state
   (re)synchronization mechanisms (see [4] Section 5, requirement #7).
   Note that security association and state must also be re-established
   to guarantee the same level of security (including both
   authentication and authorization) exists before and after the
   association re-establishment.


It should say:

   FEs and CEs may join and leave NEs dynamically (see [4] Section 4,
   requirements #12).  When an FE or CE leaves the NE, the association
   with the NE is broken.  If the leaving party rejoins an NE later, to
   re-establish the association, it may need to re-enter the pre-
   association phase.  Loss of association can also happen unexpectedly
   due to a loss of connection between the CE and the FE.  Therefore,
   the framework allows the bi-directional transition between these two
   phases, but the ForCES Protocol is only applicable for the post-
   association phase.  However, the protocol should provide mechanisms
   to support association re-establishment.  This includes the ability
   for CEs and FEs to determine when there is a loss of association
   between them, and to restore association and efficient state
   (re)synchronization mechanisms (see [4] Section 4, requirement #7).
   Note that security association and state must also be re-established
   to guarantee the same level of security (including both
   authentication and authorization) exists before and after the
   association re-establishment.


Notes:

Incorrect reference to Section 5.

https://www.rfc-editor.org/errata/eid5337

Report New Errata



Advanced Search