Search RFCs
The Series
For Authors
Sponsor
RFC Errata
Found 15 records.
Status:Verified (2)
RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007
Note: This RFC has been updated byRFC 6510
Source of RFC: mpls (rtg)Errata ID:2483
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section 6.1 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(3) Section 6.1 -- bad internal reference, and missing articleWithin Section 6.1, the first text lines on page 17 say:| The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP| descriptor in section 4.1 with the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP SECONDARY_EXPLICIT_ROUTE object. [...]The text should insert the missing article and correct the reference to point to Section 5.1
It should say:
| The S2L sub-LSP flow descriptor has the same format as the S2L| sub-LSP descriptor in section 5.1 with the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP SECONDARY_EXPLICIT_ROUTE object. [...]
Errata ID:2490
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section 17 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(10) Section 17 -- bad internal referenceWithin Section 17, in the second paragraph on page 35, the readeris referred to: "Figure 2 in section 24"which should be: "Figure 2 in Appendix A"
Status:Held for Document Update (10)
RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007
Note: This RFC has been updated byRFC 6510
Source of RFC: mpls (rtg)Errata ID:2481
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(1) Section 4.5 -- syntax / punctuation issueIn the first paragraph of Section 4.5, on page 7, RFC 4875 says: vv| [...]. The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to as the sub-LSP descriptor. [...]Obviously, the tagged comma should be *inside* the square brackets: vv| [...]. The < [<EXPLICIT_ROUTE>,] <S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to as the sub-LSP descriptor. [...]The same issue recurs in the third paragraph of Section 4.5, on thesame page.At similar places in the RFC, e.g. in the first paragraph ofSection 5.2.1, the comma is omitted entirely in the tuple notation.That is very unusual.
It should say:
[see above]
Errata ID:2482
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 5.2.1 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(2) Section 5.2.1 -- typo (text reformatting problem ?)In the 5th line of the last-paragraph of Section 5.2.1, "Sub- Group" should be spelled "Sub-Group" .
Errata ID:2484
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 6.2 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(4) Section 6.2 -- missing articleThe second paragraph of Section 6.2, on mid-page 17, says: [...]. When the integrity bit is set| in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent upstream until all Resv messages have been received from the downstream neighbors.Missing indefinite article.
It should say:
[...]. When the integrity bit is set| in the LSP_REQUIRED_ATTRIBUTE object, a Resv message MUST NOT be sent upstream until all Resv messages have been received from the downstream neighbors.
Errata ID:2485
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 8.2 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(5) Section 8.2 -- text duplication and inconsistencyThe second paragraph of Section 8.2 (on page 23), A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If any of the incoming Resv messages corresponding to a single Path message carry a RESV_CONFIRM object, then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream. If the Sub-Group Originator ID is its own address, then it MUST set the receiver address in the RESV_CONFIRM object to this address, else it MUST propagate the object unchanged.should be deleted entirely !Rationale: The first two sentences in this paragraph are repeated almost literally in the subsequent (third) paragraph of the section. The third (last) sentence above essentially is superseeded, in a more precise manner, by the second and the third bullet at the bottom of page 23. But, perhaps most importantly, the first bullet there handles a subcase not covered by, and hence mis-specified, by that sentence! Apparently, the lower half of page 23 is a revised revision of the quoted second paragraph, which should have been deleted.
Errata ID:2486
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 10.2 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(6) Section 10.2 -- clarification including mismatched angle brackets, word omissions, and punctuationWithin Section 10.2, the third paragraph on page 26 says: [...]| A newly received Path message that matches SESSION object and Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path| state carrying the same or different Sub-Group_ID, referred to Sub-| Group_ID(n) is processed as follows:
It should say:
| A newly received Path message with SESSION object and <Sender Tunnel| Address, LSP ID, Sub-Group Originator ID> tuple matching existing| Path state carrying the same or a different Sub-Group_ID, referred to| as Sub-Group_ID(n), is processed as follows:
Errata ID:2487
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 11.3 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(7) Section 11.3Established language in IETF (and other) publications is "tear down",not simply "tear", when it comes to the deletion of connections etc.Therefore, while not really wrong, I would have appreciated thefollowing changes:- in the 5th line of the 3rd paragraph of Section 11.3 (on page 28): "It does not tear any other branches ..." --> "It does not tear down any other branches ..."- in the 5th paragraph of Section 11.3, in the last text line on p.28: "... that are explicitely torn ..." --> "... that are explicitely torn down ..."[ I note this minor issue just for consideration in the preparation of future / derived work. ]
Errata ID:2488
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 15.1.2 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(8) Section 15.1.2 -- another typoOn page 31, in the 6th line of the first paragraph of Section 15.1.2, "being backed- up" should be "being backed up"[ The hyphenated form, "backed-up" is only appropriate in adverbial context, e.g., "a backed-up LSP". ]
Errata ID:2489
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 16 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(9) Section 16 -- typo/grammarWithin Section 16, the third paragraph on page 34 says: There maybe overhead for an operator to configure ...It should say: There may be overhead for an operator to configure ... ^Rationale: Otherwise, the sentence lacks of a verb.
Errata ID:2491
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 18 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(11) Section 18 -- typo (text reformatting problem ?)Within Section 18, at the bottom of page 35, "re- merge" should be "re-merge"
Errata ID:2493
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 19 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(12) Section 19(12b) -- unusual presentationIt is unusual to present the explanations of fields in a diagramin a sequence that does not correspond to the sequence of thefields therein.Therefore, I would have appreciated it to find ...o in Section 19.2.1 (on page 41) the explanation for "LSP ID" not at the bottom of the list, but at the second position, below the explanation for "IPv4 tunnel sender address";ando in Section 19.2.2 (on page 42) the explanation for "LSP ID" not at the bottom of the list, but at the second position, below the explanation for "IPv6 tunnel sender address";
Status:Rejected (3)
RFC 4875, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", May 2007
Note: This RFC has been updated byRFC 6510
Source of RFC: mpls (rtg)Errata ID:961
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21
(1) Section 4.5 -- syntax / punctuation issueIn the first paragraph of Section 4.5, on page 7, RFC 4875 says: vv| [...]. The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to as the sub-LSP descriptor. [...]Obviously, the tagged comma should be *inside* the square brackets: vv| [...]. The < [<EXPLICIT_ROUTE>,] <S2L_SUB_LSP> > tuple represents the S2L sub-LSP and is referred to as the sub-LSP descriptor. [...]The same issue recurs in the third paragraph of Section 4.5, on thesame page.At similar places in the RFC, e.g. in the first paragraph ofSection 5.2.1, the comma is omitted entirely in the tuple notation.That is very unusual.(2) Section 5.2.1 -- typo (text reformatting problem ?)In the 5th line of the last-paragraph of Section 5.2.1, "Sub- Group" should be spelled "Sub-Group" .(3) Section 6.1 -- bad internal reference, and missing articleWithin Section 6.1, the first text lines on page 17 say:| The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP| descriptor in section 4.1 with the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP SECONDARY_EXPLICIT_ROUTE object. [...]The RFC should say, inserting the missing article and correctingthe reference to point to Section 5.1 :| The S2L sub-LSP flow descriptor has the same format as the S2L| sub-LSP descriptor in section 5.1 with the difference that a P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP SECONDARY_EXPLICIT_ROUTE object. [...](4) Section 6.2 -- missing articleThe second paragraph of Section 6.2, on mid-page 17, says: [...]. When the integrity bit is set| in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent upstream until all Resv messages have been received from the downstream neighbors.It should say: [...]. When the integrity bit is set| in the LSP_REQUIRED_ATTRIBUTE object, a Resv message MUST NOT be sent upstream until all Resv messages have been received from the downstream neighbors.(5) Section 8.2 -- text duplication and inconsistencyThe second paragraph of Section 8.2 (on page 23), A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If any of the incoming Resv messages corresponding to a single Path message carry a RESV_CONFIRM object, then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream. If the Sub-Group Originator ID is its own address, then it MUST set the receiver address in the RESV_CONFIRM object to this address, else it MUST propagate the object unchanged.should be deleted entirely !Rationale: The first two sentences in this paragraph are repeated almost literally in the subsequent (third) paragraph of the section. The third (last) sentence above essentially is superseeded, in a more precise manner, by the second and the third bullet at the bottom of page 23. But, perhaps most importantly, the first bullet there handles a subcase not covered by, and hence mis-specified, by that sentence! Apparently, the lower half of page 23 is a revised revision of the quoted second paragraph, which should have been deleted.(6) Section 10.2 -- clarification including mismatched angle brackets, word omissions, and punctuationWithin Section 10.2, the third paragraph on page 26 says: [...]| A newly received Path message that matches SESSION object and Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path| state carrying the same or different Sub-Group_ID, referred to Sub-| Group_ID(n) is processed as follows:It should say: [...]| A newly received Path message that matches in SESSION object and| <Sender Tunnel Address, LSP ID, Sub-Group Originator ID> with| existing Path state carrying the same or a different Sub-Group_ID,| referred to as Sub-Group_ID(n), is processed as follows:Or even better, a bit reworded for enhanced readability: [...]| A newly received Path message with SESSION object and <Sender Tunnel| Address, LSP ID, Sub-Group Originator ID> tuple matching existing| Path state carrying the same or a different Sub-Group_ID, referred to| as Sub-Group_ID(n), is processed as follows:(7) Section 11.3Established language in IETF (and other) publications is "tear down",not simply "tear", when it comes to the deletion of connections etc.Therefore, while not really wrong, I would have appreciated thefollowing changes:- in the 5th line of the 3rd paragraph of Section 11.3 (on page 28): "It does not tear any other branches ..." --> "It does not tear down any other branches ..."- in the 5th paragraph of Section 11.3, in the last text line on p.28: "... that are explicitely torn ..." --> "... that are explicitely torn down ..."[ I note this minor issue just for consideration in the preparation of future / derived work. ](8) Section 15.1.2 -- another typoOn page 31, in the 6th line of the first paragraph of Section 15.1.2, "being backed- up" should be "being backed up"[ The hyphenated form, "backed-up" is only appropriate in adverbial context, e.g., "a backed-up LSP". ](9) Section 16 -- typo/grammarWithin Section 16, the third paragraph on page 34 says: There maybe overhead for an operator to configure ...It should say: There may be overhead for an operator to configure ... ^Rationale: Otherwise, the sentence lacks of a verb.(10) Section 17 -- bad internal referenceWithin Section 17, in the second paragraph on page 35, the readeris referred to: "Figure 2 in section 24"which should be: "Figure 2 in Appendix A"(11) Section 18 -- typo (text reformatting problem ?)Within Section 18, at the bottom of page 35, "re- merge" should be "re-merge"(12) Section 19(12a) -- lack of precision / completenessThe sub-sections of Section 19 mostly remain a bit unspecific withrespect to Class *numbers* (only Section 19.3 does supply these),whereas C-Type values always are specified fully.For uniformity and completeness, and for the ease of the reader,the following changes/amendments (determined after IANA lookup)should be applied -- adopting the style of the RFC text fromSection 19.3 --, to the lines immediately above the class datastructure diagrams (I use abbreviated, diff-like notation):o in Section 19.1.1 (on mid-page 39): Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13-- SESSION Class = 1, P2MP_LSP_TUNNEL_IPv4 C-Type = 13o in Section 19.1.2 (on page 40): Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14-- SESSION Class = 1, P2MP_LSP_TUNNEL_IPv6 C-Type = 14o in Section 19.2.1 (on top of page 41): Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12-- SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv4 C-Type = 12o in Section 19.2.2 (on top of page 42): Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13-- SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv6 C-Type = 13o in Section 19.4.1 (at the bottom of page 43): Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12-- FILTER_SPEC Class = 10, P2MP LSP_IPv4 C-Type = 12o in Section 19.4.2 (at the top of page 44): Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13-- FILTER_SPEC Class = 10, P2MP LSP_IPv6 C-Type = 13o in Section 19.5 (on page 44): The class of the P2MP SERO is the same as the SERO defined in [RFC4873].-- The class of the P2MP SERO is 200, as assigned for the SERO in [RFC4873].o in Section 19.6 (on page 44): The class of the P2MP SRRO is the same as the SRRO defined in [RFC4873].-- The class of the P2MP SRRO is 201, as assigned for the SRRO in [RFC4873].(12b) -- unusual presentationIt is unusual to present the explanations of fields in a diagramin a sequence that does not correspond to the sequence of thefields therein.Therefore, I would have appreciated it to find ...o in Section 19.2.1 (on page 41) the explanation for "LSP ID" not at the bottom of the list, but at the second position, below the explanation for "IPv4 tunnel sender address";ando in Section 19.2.2 (on page 42) the explanation for "LSP ID" not at the bottom of the list, but at the second position, below the explanation for "IPv6 tunnel sender address";(13) Section 20.2 -- similar to (12a)Contrary to Section 20.1, Section 20.2 is silent about the classnumbers. As in item (12a) above, for consistency and completeness,the following changes should be applied, in accordance with thestyle of the IANA registry file and Section 20.1 : Class Name = SESSION-- 1 Class Name = SESSION Class Name = SENDER_TEMPLATE-- 11 Class Name = SENDER_TEMPLATE Class Name = FILTER_SPEC-- 10 Class Name = FILTER_SPEC Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])-- 200 Class Name = SECONDARY_EXPLICIT_ROUTE Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])-- 201 Class Name = SECONDARY_RECORD_ROUTE[ Note: I have deleted the repeated refs to RFC 4873 for uniformity; this information is already present in Section 19, it might only have been interesting here for the IANA in the I-D phase. ]
It should say:
[see above]
Notes:
I strongly recommend to at least address items (3), (5), (6),
and (10) by an RFC Errata Note; I leave it to your decision which
other items to include additionally; IMHO, items (1), (12a), and
(13) should get high priority among these.
from pending
--VERIFIER NOTES--
Multipart Erratum split into Errata 2481-2494
Errata ID:2492
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21
Section 19 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(12) Section 19(12a) -- lack of precision / completenessThe sub-sections of Section 19 mostly remain a bit unspecific withrespect to Class *numbers* (only Section 19.3 does supply these),whereas C-Type values always are specified fully.For uniformity and completeness, and for the ease of the reader,the following changes/amendments (determined after IANA lookup)should be applied -- adopting the style of the RFC text fromSection 19.3 --, to the lines immediately above the class datastructure diagrams (I use abbreviated, diff-like notation):o in Section 19.1.1 (on mid-page 39): Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13-- SESSION Class = 1, P2MP_LSP_TUNNEL_IPv4 C-Type = 13o in Section 19.1.2 (on page 40): Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14-- SESSION Class = 1, P2MP_LSP_TUNNEL_IPv6 C-Type = 14o in Section 19.2.1 (on top of page 41): Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12-- SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv4 C-Type = 12o in Section 19.2.2 (on top of page 42): Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13-- SENDER_TEMPLATE Class = 11, P2MP_LSP_TUNNEL_IPv6 C-Type = 13o in Section 19.4.1 (at the bottom of page 43): Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12-- FILTER_SPEC Class = 10, P2MP LSP_IPv4 C-Type = 12o in Section 19.4.2 (at the top of page 44): Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13-- FILTER_SPEC Class = 10, P2MP LSP_IPv6 C-Type = 13o in Section 19.5 (on page 44): The class of the P2MP SERO is the same as the SERO defined in [RFC4873].-- The class of the P2MP SERO is 200, as assigned for the SERO in [RFC4873].o in Section 19.6 (on page 44): The class of the P2MP SRRO is the same as the SRRO defined in [RFC4873].-- The class of the P2MP SRRO is 201, as assigned for the SRRO in [RFC4873].
Notes:
--VERIFIER NOTES--
The risk of errors is reduced by only defining numbers once in a document. In any case, sufficient information exists in the document to make implementation simple.
Errata ID:2494
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-15
Rejected by: Adrian Farrel
Date Rejected: 2010-08-21
Section 20.2 says:
Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.(13) Section 20.2 -- similar to (12a)Contrary to Section 20.1, Section 20.2 is silent about the classnumbers. As in item (12a) above, for consistency and completeness,the following changes should be applied, in accordance with thestyle of the IANA registry file and Section 20.1 : Class Name = SESSION-- 1 Class Name = SESSION Class Name = SENDER_TEMPLATE-- 11 Class Name = SENDER_TEMPLATE Class Name = FILTER_SPEC-- 10 Class Name = FILTER_SPEC Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])-- 200 Class Name = SECONDARY_EXPLICIT_ROUTE Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])-- 201 Class Name = SECONDARY_RECORD_ROUTE
Notes:
--VERIFIER NOTES--
No need to make this change as all the important information is already present in the document in the IANA section.