RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (8)

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 493
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

It should say:

2. MUST NOT   This phrase, or the phrase "SHALL NOT", means that the
   definition is an absolute prohibition of the specification.

Errata ID: 495
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.


It should say:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", means that the
   definition is an absolute requirement of the specification.

Notes:


Errata ID: 496
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Kurt Zeilenga
Date Reported: 2001-01-31

Section 6 says:

   In particular, they MUST only be used where it is actually required
   for interoperation or to limit behavior which has potential for
   causing harm (e.g., limiting retransmisssions)  For example, they
   must not be used to try to impose a particular method on
   implementors where the method is not required for interoperability.   

It should say:

   In particular, they MUST only be used where it is actually required
   for interoperation or to limit behavior which has potential for
   causing harm (e.g., limiting retransmissions).  For example, they
   must not be used to try to impose a particular method on
   implementors where the method is not required for interoperability.

Errata ID: 498
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It should say:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED", means that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

Errata ID: 500
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Davidson, Malcolm
Date Reported: 2001-05-31

Section 1 says:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

It should say:

3. SHOULD   This word, or the adjective "RECOMMENDED", means that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Errata ID: 494
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Davidson, Malcolm
Date Reported: 2001-05-31
Verifier Name: RFC Editor
Date Verified: 2007-11-07

Section 6 says:

(e.g., limiting retransmisssions)

It should say:

(e.g., limiting retransmissions)

Errata ID: 499
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Anders Langmyr
Date Reported: 2006-01-09
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-15

Section Abstract says:

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in
       RFC 2119.

It should say:

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
       RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to 
       be interpreted as described in RFC 2119.

Notes:

The phrase "NOT RECOMMENDED" is missing from this sentence.

Errata ID: 5101
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jim Tonti
Date Reported: 2017-08-29
Verifier Name: Warren Kumari
Date Verified: 2017-08-29

Section 5 says:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

It should say:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides).

Notes:

Full stop should appear outside the parentheses in the last sentence.

Status: Reported (1)

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 6954
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: aaron wuescher
Date Reported: 2022-05-05

Section 6. of all scripts says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

{This part: (e.g., limiting retransmisssions); is the focus.}

It should say:

In-line html has an errata by Davidson, Malcolm about the extra S in retransmission. (Good Job to Malcom! (I would also like to make editors aware that is in only corrected in the, in-line html.  The error of the extra -s in the word retransmissions is still present in all of the other documents.)  

The problem I would like to bring to the attention of the minds of the world, is 
still that same word, retransmissions and I'm concerned that it has been looked at and still over looked.   It should be simply "transmissions" or, but NOT RECOMENDED; "re-transmissions".  (I will explain.) 

Notes:

The base word "transmission" (which is already a compound word.) in the plural form, shows more than one, present tense, and also future tense. Therefore the re- prefix is redundant in the word. It actually retards the word making it null. Without the hyphen it is an entirely different compound word that may not even exist yet. The -s making it plural is plenty to make this sentence complete and accurate. There is no need for the re- prefix but if you must it should be hyphenated. Thank you!

Status: Held for Document Update (2)

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 2969
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: John Klensin
Date Reported: 2011-09-12
Held for Document Update by: Russ Housley

Section 1,3,4 says:

(1) "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" mean

(2) 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean

(3) 3. SHOULD   This word, or the adjective "RECOMMENDED", mean

(4) 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean

It should say:

(1) "The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", and "MAY" means

(2) 1. MUST   This word, or the term "SHALL", means

(3) 3. SHOULD   This word means

(4) 4. SHOULD NOT   This phrase means

Editorial note: The use of "mean" after a singular subject is simply wrong.  Subordinate phrases like ", or the term BLATHER," do nothing to change that.


 

Notes:

RFC 2026, to which RFC 2119 should be subordinate, carefully distinguishes between Technical Specifications (TS) and Applicability Statements (AS). Its Section 3.3 prescribes specific language to be used in ASs, with categories "Required", "Recommended", "Elective", "Limited Use", and "Not Recommended", while 2119's language, especially in its Section 6, fairly clearly apply to interoperability requirements within TS documents. Use of terms that 2026 requires for AS documents in a TS context (as synonyms for other, unambiguous, terms) is just an invitation to confusion, especially if the IETF continues to have hair-splitting arguments about the nature of requirements in particular contexts. Consequently, while the change proposed in erratum 419 (altering the definition phrase to reflect the language of Section 4) appears reasonable from an editorial standpoint, the correct fix is to remove the 2026 AS terms as acceptable synonyms from 2119 entirely. If people want to say "SHOULD NOT" and give it specific meaning, they should say "SHOULD NOT" rather than trying to use nearly-synonymous terms and hoping that the reader will figure out what was really met.

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

Reported By: Hugo Gabriel Eyherabide
Date Reported: 2017-12-14
Held for Document Update by: Lars Eggert
Date Held: 2021-03-11

Section 5 says:

MAY   This word, or the adjective "OPTIONAL", mean

It should say:

MAY   This word, or the adjective "OPTIONAL", means

Notes:

This correction is analogous to that pointed out by Erratas 495, 498, 500 and 2969 for sections 1, 3 and 4, but for section. The correction replaces "mean" with "means"

Status: Rejected (2)

RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: gen

Errata ID: 497
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Kiyoshi Ogawa
Date Reported: 2006-07-10
Rejected by: Russ Housley
Date Rejected: 2010-08-19

 

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It should say:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications should be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

Notes:

OR should say:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications is understood and
carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.


The change request is "must" to "should".
It may be self definition.
For the balance of SHOULD and SHOULD NOT , it should use "should", not
"must".
--VERIFIER NOTES--
The full implications MUST be understood in order to ignore a "SHOULD" or "SHOULD NOT" statement in a specification.

Errata ID: 6773
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michał Bieńkowski
Date Reported: 2021-12-03
Rejected by: RFC Editor
Date Rejected: 2022-01-27

Section 5 says:

MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

It should say:

MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional. One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

Notes:

There is a double space before "One vendor may choose to include".
--VERIFIER NOTES--
This report doesn't add clarity or improve readabilty. We don't recommend errata be used to "correct" the number of spaces between sentences.

Report New Errata