Subject: [forces] [Editorial Errata Reported] RFC5810 (2574)

From: RFC Errata System <[email-masked]>
Date: Sat, 16 Oct 2010 05:50:59 -0700 (PDT)

The following errata report has been submitted for RFC5810,
"Forwarding and Control Element Separation (ForCES) Protocol Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5810&eid=2574

--------------------------------------
Type: Editorial
Reported by: Jamal Hadi Salim <[email-masked]>

Section: Appendix D

Original Text
-------------
Example 13 text (not the example) claims you can use a single KEYINFO to 
match multiple L3 entries.
" 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.  "
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.

Corrected Text
--------------
Fix the above

Notes
-----

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5810 (draft-ietf-forces-protocol-22)
--------------------------------------
Title               : Forwarding and Control Element Separation (ForCES) Protocol Specification
Publication Date    : March 2010
Author(s)           : A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern
Category            : PROPOSED STANDARD
Source              : Forwarding and Control Element Separation
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: Adrian Farrel <[email-masked]>
Date: Sun, 17 Oct 2010 20:43:03 +0100

Hi,

Would I be correct in assuming that the problem reported here is with the 
use of the word "automatically".

AFAICS, the sequence of operations in the example does not result in KEYINFO 
matching multiple table entries, because the second operation is overwriting 
the previous PATH-DATA-TLV.

Would the following fix be what you are looking for?

OLD
        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.  The assumption is that both tables are
           in the same LFB.
NEW
        Note 1:   This emulates adding a new nexthop entry and then
           updating the L3 entries pointing to an old NH to point to the
           new one.  The assumption is that both tables are in the same
           LFB.
END

Thanks,
Adrian

----- Original Message ----- 
From: "RFC Errata System" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, October 16, 2010 1:50 PM
Subject: [Editorial Errata Reported] RFC5810 (2574)

> Author(s)           : A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. 
> Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 18 Oct 2010 07:07:49 -0400

Hi Adrian,

>          new one.  The assumption is that both tables are in the same

The problem is the statement "L3 entries"... It can only be one
"L3 entry" that matches the key per RFC 5812 rules.
So a proper fix is to change "entries" to "entry". Other than that,
there is no other claim that multiple entries are being updated.
Sorry, I should have been less lazy and entered such text in the
problem description.

cheers,
jamal