[{"errata_id": "1", "doc-id": "RFC4954", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " S: 220-smtp.example.com ESMTP Server", "correct_text": " S: 220 smtp.example.com ESMTP Server", "notes": "There are 3 instances of this (one on p. 7 and two on p. 8). \n", "submit_date": "2007-07-19", "submitter_name": "Rob Siemborski", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2", "doc-id": "RFC4907", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "1.4.2", "orig_text": " In order to address\n this problem, \"Packetization Layer Path MTU Discovery\" [RFC4821] does\n depend on the delivery of ICMP messages.", "correct_text": " In order to address\n this problem, \"Packetization Layer Path MTU Discovery\" [RFC4821] does\n not depend on the delivery of ICMP messages.\n", "notes": "", "submit_date": "2007-06-25", "submitter_name": "Stephane Bortzmeyer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3", "doc-id": "RFC4884", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": "The one's complement of the one's complement sum of the data\nstructure, with the checksum field replaced by zero for the\npurpose of computing the checksum.", "correct_text": "The one's complement of the one's complement sum of the ICMP\nExtension Structure, with the checksum field replaced by zero for\nthe purpose of computing the checksum.\n", "notes": "", "submit_date": "2007-05-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4", "doc-id": "RFC4866", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.2", "orig_text": " Enhanced\r\n Router Optimization does not make assumptions on the relationship\r\n ^^^^^^\r\n between mobile and correspondent nodes.", "correct_text": " Enhanced\r\n Route Optimization does not make assumptions on the relationship\r\n ^^^^^ \r\n between mobile and correspondent nodes.", "notes": "Page 43, 1st paragraph", "submit_date": "2007-05-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Christian Vogt", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5", "doc-id": "RFC4853", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": "RFC 3852, section 5.1, the next to the last paragraph says:", "correct_text": "RFC 3852, section 5.1, the last paragraph says:\n", "notes": "", "submit_date": "2007-05-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "6", "doc-id": "RFC4812", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "The running page footer displays the wrong status of the document; \nthe footer displays \"Experimental\". However, RFC 4812 is an \nInformational document. The status is displayed correctly in \nthe document header and in the RFC index.\n\n\n", "submit_date": "2007-03-29", "submitter_name": "Abhay Roy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "7", "doc-id": "RFC4790", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.1", "orig_text": "collation-id = collation-prefix \";\" collation-core-name", "correct_text": "collation-id = collation-scope \";\" collation-core-name", "notes": "Submitted to the RFC Editor by Chris Newman.\r\nAlso reported by Alfred Hoenes 2007-04-10.", "submit_date": "2007-03-29", "submitter_name": "Filip Navara", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "8", "doc-id": "RFC4782", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.3", "orig_text": " The QS Nonce in the\r\n Response is set to the received value of the QS Nonce in the Quick-\r\n Start Option.", "correct_text": " The QS Nonce in the\r\n Response is set to the received value of the QS Nonce in the Quick-\r\n Start Option.\r\n\r\n If the TCP host has sufficient receive buffer space, it could\r\n estimate the required buffer space as the product of the approved\r\n Quick-Start rate and the round-trip time, and advertise a receive\r\n window based on this required buffer space. This receive window\r\n should allow the other TCP host to fully use the approved Quick-Start\r\n Request.\r\n\r\n If the TCP host doesn't know the round-trip time, the TCP host\r\n could use an estimate of the round-trip time in calculating the\r\n required buffer space. Alternately, the TCP host could base the\r\n advertised receive window on the available buffer space, without\r\n calculating the buffer space required for the other TCP host to\r\n fully use the approved Quick-Start Request.\r\n\r\n If the Quick-Start Response is sent in a SYN/ACK packet, then\r\n window scaling of the receive window is not allowed [RFC1323];\r\n if necessary, the TCP host could send a scaled receive window\r\n in a separate ACK packet following the SYN/ACK packet.", "notes": "Clarification regarding the receive window.\r\n\r\nfrom pending", "submit_date": "2007-04-10", "submitter_name": "Michael Scharf", "verifier_id": "", "verifier_name": "Sally Floyd", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "9", "doc-id": "RFC4753", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": " The Diffie-Hellman public value is obtained by concatenating the x\r\n and y values.\r\n\r\n The format of the Diffie-Hellman shared secret value is the same as\r\n that of the Diffie-Hellman public value.", "correct_text": "", "notes": "The last paragraph is incorrect. The Diffie-Hellman shared secret \r\ncontains only the x value. The y value is not included in the shared \r\nsecret.\r\n\r\n\r\n\r\n", "submit_date": "2007-04-23", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "10", "doc-id": "RFC4746", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.3.7", "orig_text": " Consequently, EAP-PAX requires the use of a\r\n Diffie-Hellman group with modulus larger than 3000. ", "correct_text": " Consequently, EAP-PAX requires the use of a\r\n Diffie-Hellman group with modulus larger than 3000 bits. \r\n", "notes": "Provide units.", "submit_date": "2006-11-26", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "11", "doc-id": "RFC4746", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2", "orig_text": " These 52+L octets are then attached to the packet as the payload.", "correct_text": " These 54+L octets are then attached to the packet as the payload.", "notes": "Correction based on preceding text (page 16) and Figure 8\r\n", "submit_date": "2006-11-26", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "12", "doc-id": "RFC4742", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.1", "orig_text": " [RFC4721] Enns, R., Ed., \"NETCONF Configuration Protocol\", RFC 4721,\r\n December 2006.", "correct_text": " [RFC4741] Enns, R., Ed., \"NETCONF Configuration Protocol\", RFC 4741, \r\n December 2006.", "notes": "RFC4742 refers throughout to the NETCONF specification as RFC4721, even though NETCONF is really specified in RFC4741.\r\n\r\nfrom pending", "submit_date": "2007-03-30", "submitter_name": "Heikki Kortti", "verifier_id": "", "verifier_name": null, "update_date": "2021-04-01 04:31:11"}, {"errata_id": "13", "doc-id": "RFC4730", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.1", "orig_text": " DRegexCharacter = DIGIT / \"A\" / \"B\" / \"C\" / \"D\" / \"R\" / \"*\" / \"#\" /\r\n \"a\" / \"b\" / \"c\" / \"d\" / \"r\"", "correct_text": " DRegexCharacter = DIGIT / \"A\" / \"B\" / \"C\" / \"D\" / \"R\" / \"X\" / \"*\" / \"#\"\r\n \"a\" / \"b\" / \"c\" / \"d\" / \"r\" / \"x\"", "notes": "The ABNF for DRegex (page 29) is missing an 'x'.", "submit_date": "2006-11-30", "submitter_name": "Eric Burger", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "14", "doc-id": "RFC4705", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "11", "orig_text": " [IKEv2] Kaufman, C., \"The Internet Key Exchange (IKEv2) Protocol\",\n RFC 2306, December 2005. ", "correct_text": " [IKEv2] Kaufman, C., \"The Internet Key Exchange (IKEv2) Protocol\",\n RFC 4306, December 2005.\n", "notes": "\n", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5154", "doc-id": "RFC8017", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.2.4", "orig_text": "SHA-256 sha224WithRSAEncryption ::= {pkcs-1 14}", "correct_text": "SHA-224 sha224WithRSAEncryption ::= {pkcs-1 14}", "notes": "Good catch. Confirmed.\r\n\r\nBackground: The addition of SHA224 support to PKCS #1 required a few minor technical updates in PKCS #1 v2.2 compared to v2.1, and to the corresponding RFC8017 compared to RFC3447. PKCS #1 v2.2 got the correct update, but RFC8017 didn't -- presumably a copy-and-paste error. My oversight in reviewing the edits. Thanks, Joost, for pointing it out.", "submit_date": "2017-10-12", "submitter_name": "Joost Rijneveld", "verifier_id": "", "verifier_name": "Kathleen Moriarty", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "15", "doc-id": "RFC4701", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "6", "orig_text": " However, it should be noted that an attacker that has some knowledge,\r\n such as of MAC addresses commonly used in DHCP client identification\r\n data, may be able to discover the client's DHCP identify by using a\r\n brute-force attack. ", "correct_text": " However, it should be noted that an attacker that has some knowledge,\r\n such as of MAC addresses commonly used in DHCP client identification\r\n data, may be able to discover the client's DHCP identity by using a\r\n brute-force attack. \r\n", "notes": "", "submit_date": "2006-11-02", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "16", "doc-id": "RFC4698", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4", "orig_text": " o Most specific: Given a set of networks, the network or networks\r\n that are more specific than zero or more specific of the other\r\n networks in the set, and that are not less specific of any of the\r\n networks in the set.\r\n\r\n o Least specific: Given a set of networks, the network or networks\r\n that are not more specific to any of the other networks in the\r\n set.", "correct_text": " o Most specific: Given a set of networks, the network or networks\r\n that are more specific than zero or more of the other networks in\r\n the set, and that are not less specific than any of the networks\r\n in the set.\r\n\r\n o Least specific: Given a set of networks, the network or networks\r\n that are not more specific than any of the other networks in the\r\n set.\r\n", "notes": "from pending", "submit_date": "2006-11-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "17", "doc-id": "RFC4695", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "In this errata, we briefly summarize several errata to RFC 4695,\nreported by Alfred Hoenes. The listed errata either fix normative\nproblem in RFC 4695, or describe editorial errata that may be\nparticularly confusing to the implementor.\n\nThe presentation below is brief. See the main text of\n for a bis version of RFC 4695 that\nintegrates the fixes listed below in a more-complete way, and also\nincludes many other editorial fixes.\n\nJohn Lazzaro, lazzaro@eecs.berkeley.edu\n\n---\n\n[1] In Appendix C.1 and Appendix C.2.3 of RFC 4695, an ABNF rule\nrelated to System Chapter X is incorrectly defined as:\n\n = \"__\" [\"_\" ] \"__\"\n\nThe correct version of this rule is:\n\n = \"__\" *( \"_\" ) \"__\"\n\n[2] In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned\nto the \"url\" parameter are not stated clearly. URIs assigned to \"url\"\nMUST specify either HTTP or HTTP over TLS transport protocols.\n\nIn Appendix C.7.1 and C.7.2 of RFC 4695, the transport\ninteroperability requirements for the \"url\" parameter are not stated\nclearly. For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS\nis OPTIONAL.\n\n[3] Both fmtp lines in both session description examples in Appendix\nC.7.2 of RFC 4695 contain instances of the same syntax error (a\nmissing \";\" at a line wrap after \"cm_used=2M0.1.2\").\n\n[4] In Appendix D of RFC 4695, all uses of \"*ietf-extension\" in rules\nare in error, and should be replaced with \"ietf-extension\". Likewise,\nall uses of \"*extension\" are in error, and should be replaced with\n\"extension\". This bug incorrectly lets the null token be assigned to\nthe j_sec, j_update, render, smf_info, and subrender parameters.\n\n[5] In Appendix D of RFC 4695, the definitions of the \nand incorrectly allow lowercase letters to appear in\nthese strings. The correct definitions of these rules appear below:\n command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M]\n [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]\n\n chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]\n [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]\n\n A = %x41\n B = %x42\n C = %x43\n D = %x44\n E = %x45\n F = %x46\n G = %x47\n H = %x48\n J = %x4A\n K = %x4B\n M = %x4D\n N = %x4E\n P = %x51\n Q = %x52\n T = %x54\n V = %x56\n W = %x57\n X = %x58\n Y = %x59\n Z = %x5A\n\n[6] In Appendix D of RFC 4695, the definitions of the ,\n, and are incorrect. The correct\ndefinitions of these rules appear below:\n nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT))\n / (%x30-33 9(DIGIT))\n / (\"4\" %x30-31 8(DIGIT))\n / (\"42\" %x30-38 7(DIGIT))\n / (\"429\" %x30-33 6(DIGIT))\n / (\"4294\" %x30-38 5(DIGIT))\n / (\"42949\" %x30-35 4(DIGIT))\n / (\"429496\" %x30-36 3(DIGIT))\n / (\"4294967\" %x30-31 2(DIGIT))\n / (\"42949672\" %x30-38 (DIGIT))\n / (\"429496729\" %x30-34)\n\n four-octet = \"0\" / nonzero-four-octet\n midi-chan = DIGIT / (\"1\" %x30-35)\n DIGIT = %x30-39\n NZ-DIGIT = %x31-39\n\n[7] In Appendix D of RFC4695, the rule is\nincorrect. The correct definition of this rule appears below.\n hex-octet = %x30-37 U-HEXDIG\n U-HEXDIG = DIGIT / A / B / C / D / E / F\n\n ; DIGIT as defined in [5] above\n ; A, B, C, D, E, F as defined in [4] above\n\n[8] In Appendix D of RFC4695, the rules and\n are defined unclearly. The rewritten rules\nappear below:\n base64-unit = 4(base64-char)\n base64-pad = (2(base64-char) \"==\") / (3(base64-char) \"=\")\n\n", "correct_text": "", "notes": "", "submit_date": "2007-01-18", "submitter_name": "John Lazzaro", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5790", "doc-id": "RFC6241", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Sections 7.8, 7.9, and 8.4.1", "orig_text": "OLD:\r\n\r\n7.8. \r\n\r\n Description: Request graceful termination of a NETCONF session.\r\n\r\n When a NETCONF server receives a request, it will\r\n gracefully close the session. The server will release any locks\r\n and resources associated with the session and gracefully close\r\n any associated connections. Any NETCONF requests received after\r\n a request will be ignored.\r\n\r\n Positive Response: If the device was able to satisfy the request, an\r\n is sent that includes an element.\r\n\r\n Negative Response: An element is included in the\r\n if the request cannot be completed for any reason.\r\n\r\n Example:\r\n\r\n \r\n \r\n \r\n\r\n \r\n \r\n \r\n\r\nNEW\r\n\r\n7.8. \r\n\r\n Description: Request graceful termination of a NETCONF session.\r\n\r\n When a NETCONF server receives a request, it will\r\n gracefully close the session. The server will release any locks\r\n and resources associated with the session and gracefully close any\r\n associated connections. Any NETCONF requests received after a\r\n request will be ignored.\r\n\r\n For details on what happens if a NETCONF server receives a \r\n request while processing a confirmed commit,\r\n please refer to Section 8.4.\r\n\r\n Positive Response: If the device was able to satisfy the request, an\r\n is sent that includes an element.\r\n\r\n Negative Response: An element is included in the\r\n if the request cannot be completed for any reason.\r\n\r\n Example:\r\n\r\n \r\n \r\n \r\n\r\n \r\n \r\n \r\n\r\nOLD\r\n\r\n7.9. \r\n\r\n Description: Force the termination of a NETCONF session.\r\n\r\n When a NETCONF entity receives a request for an\r\n open session, it will abort any operations currently in process,\r\n release any locks and resources associated with the session, and\r\n close any associated connections.\r\n\r\n If a NETCONF server receives a request while\r\n processing a confirmed commit (Section 8.4), it MUST restore the\r\n configuration to its state before the confirmed commit was issued.\r\n\r\n Otherwise, the operation does not roll back\r\n configuration or other device state modifications made by the\r\n entity holding the lock.\r\n\r\n Parameters:\r\n\r\n session-id: Session identifier of the NETCONF session to be\r\n terminated. If this value is equal to the current session ID,\r\n an \"invalid-value\" error is returned.\r\n\r\n Positive Response: If the device was able to satisfy the request, an\r\n is sent that includes an element.\r\n\r\n Negative Response: An element is included in the\r\n if the request cannot be completed for any reason.\r\n\r\n\r\n Example:\r\n\r\n \r\n \r\n 4\r\n \r\n \r\n\r\n \r\n \r\n \r\n\r\nNEW\r\n\r\n7.9. \r\n\r\n Description: Force the termination of a NETCONF session.\r\n\r\n When a NETCONF entity receives a request for an\r\n open session, it will abort any operations currently in process,\r\n release any locks and resources associated with the session, and\r\n close any associated connections.\r\n\r\n For details on what happens if a NETCONF server receives a \r\n request while processing a confirmed commit,\r\n please refer to Section 8.4.\r\n\r\n Otherwise, the operation does not roll back\r\n configuration or other device state modifications made by the\r\n entity holding the lock.\r\n\r\n Parameters:\r\n\r\n session-id: Session identifier of the NETCONF session to be\r\n terminated. If this value is equal to the current session ID,\r\n an \"invalid-value\" error is returned.\r\n\r\n Positive Response: If the device was able to satisfy the request, an\r\n is sent that includes an element.\r\n\r\n Negative Response: An element is included in the\r\n if the request cannot be completed for any reason.\r\n\r\n\r\n Example:\r\n\r\n \r\n \r\n 4\r\n \r\n \r\n\r\n \r\n \r\n \r\n\r\n\r\nSection 8.4.1\r\n\r\nOLD:\r\n\r\n If the device reboots for any reason before the confirm timeout\r\n expires, the server MUST restore the configuration to its state\r\n before the confirmed commit was issued.\r\n\r\nNEW:\r\n\r\n If the device reboots for any reason before the confirm timeout\r\n expires, the server MUST restore the configuration to its state\r\n before the confirmed commit was issued, unless the confirmed commit \r\n also included a element, in which case the server MAY\r\n continue the confirmed commit procedure.\r\n", "correct_text": "", "notes": "This Errata modifies three different sections, Sections 7.8, 7.9 and 8.4.1. The changes in Section 7.8 and 7.9 defer the description of the behavior of confirmed commit to Section 8.4.1.", "submit_date": "2019-07-23", "submitter_name": "Mahesh Jethanandani", "verifier_id": "", "verifier_name": "Ignas Bagdonas", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "18", "doc-id": "RFC4684", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "This RFC was briefly posted with a misspelling in the title.\nIt was reposted with \"Internet Protcol\" corrected to \"Internet Protocol\".\n\n\n", "submit_date": "2006-11-28", "submitter_name": "RFC Editor", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "19", "doc-id": "RFC4679", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.3.1", "orig_text": " The slot identifier does not exceed 6 characters in length, and the port\n identifier does not exceed 3 characters in length using a '\\' as a\n delimiter.", "correct_text": " The slot identifier does not exceed 6 characters in length, and the port\r\n identifier does not exceed 3 characters in length using a '/' as a\r\n delimiter.\r\n", "notes": "", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Nevil Brownlee", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "20", "doc-id": "RFC4678", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7.1", "orig_text": "...will only be considered if \r\nthe Trust flag is set while the state of the load balancer/scheduler is set.", "correct_text": "... will only be considered if \r\nthe Trust flag has been set with a Set LB State message.\r\n", "notes": "also applies to section 7.2\r\n\r\nfrom pending", "submit_date": "2006-11-15", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Nevil Brownlee", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "21", "doc-id": "RFC4677", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8.1", "orig_text": " There are six kinds of RFCs:\r\n\r\n o Proposed standards\r\n o Draft standards\r\n o Internet standards (sometimes called \"full standards\")\r\n o Informational documents\r\n o Experimental protocols\r\n o Historic documents", "correct_text": " There are seven kinds of RFCs:\r\n\r\n o Proposed standards\r\n o Draft standards\r\n o Internet standards (sometimes called \"full standards\")\r\n o Best Current Practice documents\r\n o Informational documents\r\n o Experimental protocols\r\n o Historic documents", "notes": "This enumeration omits the \"Best Current Practice\" documents.\r\nThe approval process for BCPs is quite different than Informational\r\nRFCs. Because BCPs are so important, including their role in publishing\r\nthe the IETF Standards Process itself, they shoudl be included in this\r\nlist.", "submit_date": "2006-11-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2161", "doc-id": "RFC3398", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "8.2.6.1", "orig_text": "504 Version Not Supported 127 Interworking (+)\r\n", "correct_text": "505 Version Not Supported 127 Interworking (+)\r\n", "notes": "504 appears twice with different text. From the context, it looks like the text in the second entry is correct, and the number is wrong.", "submit_date": "2010-04-13", "submitter_name": "Andrew Miller", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "22", "doc-id": "RFC4676", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.2", "orig_text": " option-code: OPTION_GEOCONF_CIVIC (37)", "correct_text": " option-code: OPTION_GEOCONF_CIVIC (36)", "notes": "\n\n", "submit_date": "2006-11-02", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "23", "doc-id": "RFC4676", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "1", "orig_text": " In addition, if a network provides civic location information via\r\n both DHCPv4 and DHCPv6, the information conveyed by two protocols\r\n MUST be the same.", "correct_text": " In addition, if a network provides civic location information via\r\n both DHCPv4 and DHCPv6, the information conveyed by the two protocols\r\n MUST be the same.\r\n", "notes": "", "submit_date": "2006-11-02", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2570", "doc-id": "RFC5810", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "Figure 1", "orig_text": "\r\nFigure 1 does not have a line joining CE2 and FE2 with Fp..", "correct_text": "Figure 1 should have a line joining CE2 and FE2 with Fp..\r\n", "notes": "This is just a description of how to fix.\r\nI think this form can be improved so i can\r\nenter descriptive text instead of s/orig/new approach\n --VERIFIER NOTES-- \nAfter discussion with the WG, it was agreed that the figure deliberately reproduces a figure from RFC 3746 and should be left unchanged.", "submit_date": "2010-10-16", "submitter_name": "Jamal Hadi Salim", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "24", "doc-id": "RFC4675", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2.3", "orig_text": " The String field is at least one octet in length and contains the\r\n VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a).\r\n [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a\r\n robust implementation SHOULD support the field as undistinguished\r\n octets.", "correct_text": " The String field is at least one octet in length and contains the\r\n VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a).\r\n [RFC3629] UTF-8 encoded ISO 10646 characters are RECOMMENDED, but a\r\n robust implementation SHOULD support the field as undistinguished\r\n octets.\r\n", "notes": "", "submit_date": "2006-09-19", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "25", "doc-id": "RFC4673", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4", "orig_text": "hundredths of a second", "correct_text": "centiseconds", "notes": "Why not use the common ISO-standard unit-multiple name, \"centiseconds\" (abbreviation: \"cs\"), instead of the long-winded \"hundredths of a second\" ?\r\n\r\nThis applies to the UNITS and the DESCRIPTION clause of\r\n - radiusDynAuthServerCounterDiscontinuity (RFC 4673, page 17),\r\n\r\nfrom pending\r\n\r\n--VERIFIER COMMENT--\r\nwell, yes, centiseconds can be used as well but both terms are the same.", "submit_date": "2006-11-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stefaan De Cnodder", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "26", "doc-id": "RFC4672", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "(for RFC 4672 and 4673)\r\n\r\nAs specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and\r\nre-stated in the boilerplate Section 3, \"The Internet-Standard\r\nManagement Framework\", there's just one single\r\nManagement Information Base (MIB) comprised of various \"MIB modules\".\r\nThus, throughout the titles and the text bodies of the RFCs, the\r\nproper term, \"RADIUS ... MIB module\" should be used consistently,\r\ninstead of the rather sluggish \"RADIUS ... MIB\".\r\n", "correct_text": "", "notes": "from pending", "submit_date": "2006-11-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stefaan De Cnodder", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "27", "doc-id": "RFC4670", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "The DESCRIPTION clause of the radiusAccClientRetransmissionsOBJECT-TYPE declaration says:", "orig_text": " DESCRIPTION\r\n \"The number of RADIUS Accounting-Request packets\r\n retransmitted to this RADIUS accounting server.\r\n Retransmissions include retries where the\r\n Identifier and Acct-Delay have been updated, as\r\n well as those in which they remain the same.\"", "correct_text": " DESCRIPTION\r\n \"The number of RADIUS Accounting-Request packets\r\n retransmitted to this RADIUS accounting server.\r\n Retransmissions include retries where the\r\n Identifier and Acct-Delay have been updated, as\r\n well as those in which they remained the same.\"\r\n", "notes": "for temporal consistency\r\n\r\nfrom pending\n --VERIFIER NOTES-- \nthe difference is not clear ", "submit_date": "2006-11-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "28", "doc-id": "RFC4669", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "The DESCRIPTION clause of the radiusAuthServResetTime OBJECT-TYPE declaration says:", "orig_text": " \"If the server has a persistent state (e.g., a process)\r\n and supports a 'reset' operation (e.g., can be told to\r\n re-read configuration files), this value will be the\r\n time elapsed (in hundredths of a second) since the\r\n server was 'reset.'", "correct_text": " \"If the server has a persistent state (e.g., a process)\r\n and supports a 'reset' operation (e.g., can be told to\r\n re-read configuration files), this value will be the\r\n| time elapsed (in centiseconds) since the\r\n| server was 'reset'. ", "notes": "The original description does not conform to the 'rational quoting' style required by the RFC authoring guidelines.\r\n\r\nAlso, why not use the common ISO-standard unit-multiple name, \"centiseconds\" (abbreviation: \"cs\"), instead of the long-winded \"hundredths of a second\" ?\r\n\r\nThis also applies to the DESCRIPTION clauses of\r\n - radiusAuthServUpTime (RFC 4669, top of page 7),\r\n\r\nfrom pending", "submit_date": "2006-11-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "29", "doc-id": "RFC4668", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": "[[Around the page break from page 8 to page 9, and once more,\r\nnear the top of page 14]]\r\n\r\n --\r\n -- AccessRequests + PendingRequests + ClientTimeouts =\r\n -- Successfully received\r\n --", "correct_text": " --\r\n -- AccessRequests - PendingRequests - ClientTimeouts =\r\n -- Successfully received\r\n --", "notes": "I strongly suspect that this is wrong (-- and it does not either\r\nmatch the presentation style of the formulae above in the text).\r\nConceptually, it makes no sense to count 'PendingRequests' and\r\n'ClientTimeouts' as 'Successfully received', and the subsequent\r\nDESCRIPTION clauses strongly support my suspicion that both\r\ninstances of this formula in fact be as above.\r\n\r\nfrom pending", "submit_date": "2006-11-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2397", "doc-id": "RFC4985", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2", "orig_text": "Within Section 2, the 3rd-to-last paragraph on page 3 says:\r\n\r\n Even though this name form is based on the service resource record\r\n (SRV RR) definition in RFC 2782 [N3] and may be used to enhance\r\n subsequent authentication of DNS-based service discovery, this\r\n standard does not define any new conditions or requirements regarding\r\n| use of SRV RR for service discovery or where and when such use is\r\n appropriate.\r\n ^^\r\n", "correct_text": "It should say:\r\n\r\n Even though this name form is based on the service resource record\r\n (SRV RR) definition in RFC 2782 [N3] and may be used to enhance\r\n subsequent authentication of DNS-based service discovery, this\r\n standard does not define any new conditions or requirements regarding\r\n| the use of SRV RRs for service discovery or where and when such use\r\n ^^^^ ^^^\r\n is appropriate.", "notes": "", "submit_date": "2007-09-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2399", "doc-id": "RFC4985", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1", "orig_text": "The last paragraph of Section 1, on page 2 of RFC 4985, says:\r\n\r\n v\r\n| Current dNSName GeneralName Subject Alternative name form only\r\n provides for DNS host names to be expressed in \"preferred name\r\n syntax\", as specified by RFC 1034 [N4]. [...]\r\n\r\n", "correct_text": "It should say:\r\n\r\n vvvvv\r\n| The current dNSName GeneralName Subject Alternative name form only\r\n provides for DNS host names to be expressed in \"preferred name\r\n syntax\", as specified by RFC 1034 [N4]. [...]", "notes": "", "submit_date": "2007-09-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "93", "doc-id": "RFC4430", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "[editorial nits moved to errata ID 1770]\r\n\r\n(7) Section 4.2.7 (page 22/23)\r\n\r\n(7a) Item (1b) above applies, and plaintext vs. ciphertext is unclear.\r\n\r\nThe initial text and Figure 13 unfortunately do not properly make\r\nthe distinction between unencrypted (plaintext) and encrypted\r\n(ciphertext) values and fields.\r\nThe presentation on page 22 needs clarification, according to the\r\nnote given on page 23:\r\n\r\n The coverage of the encrypted data begins at InnerNextPload so that\r\n the first payload's type is kept confidential. Thus, the number of\r\n encrypted octets is PayloadLength - 4.\r\n\r\nOn page 22, the text and Figure 13,\r\n\r\n| The KINK_ENCRYPT payload encapsulates other KINK payloads and is\r\n| encrypted using the session key and the algorithm specified by its\r\n etype. This payload MUST be the final one in the outer payload chain\r\n| of the message. The KINK_ENCRYPT payload MUST be encrypted before\r\n the final KINK checksum is applied.\r\n\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n| +---------------+---------------+---------------+---------------+\r\n| | Next Payload | RESERVED | Payload Length |\r\n +---------------+---------------+---------------+---------------+\r\n | InnerNextPload| RESERVED2 |\r\n +---------------+---------------+---------------+---------------+\r\n | Payload (variable) |\r\n +---------------+---------------+---------------+---------------+\r\n\r\n| Figure 13: KINK_ENCRYPT Payload\r\n\r\nshould say:\r\n\r\n| The KINK_ENCRYPT payload encapsulates other KINK payloads and its\r\n| value is encrypted using the session key and the algorithm specified\r\n by its etype. This payload MUST be the final one in the outer\r\n| payload chain of the message. The plaintext KINK_ENCRYPT payload\r\n| value MUST be encrypted before the final KINK checksum is applied.\r\n\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +---------------+---------------+---------------+---------------+\r\n | Next Payload | RESERVED | Payload Length |\r\n +---------------+---------------+---------------+---------------+\r\n| | |\r\n| ~ encrypted KINK_ENCRYPT Payload value (variable) ~\r\n| | |\r\n +---------------+---------------+---------------+---------------+\r\n\r\n| Figure 13a: KINK_ENCRYPT Payload\r\n\r\n(I have chosen the more descriptive filed name,\r\n'encrypted KINK_ENCRYPT Payload value' over the more fuzzy term,\r\n'encryption payload' used in the text on page 23.)\r\n\r\nAfter the first bullet on page 23,\r\n\r\n o Next Payload, RESERVED, Payload Length -- Defined in the\r\n beginning of this section. This payload is the last one in a\r\n message, and accordingly, the Next Payload field must be\r\n KINK_DONE (0).\r\n\r\nThe following text and figure should be inserted:\r\n\r\n o encrypted KINK_ENCRYPT Payload value -- This is the\r\n encrypted form of the plaintext form of the KINK_ENCRYPT\r\n Payload value in the following format:\r\n\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +---------------+---------------+---------------+---------------+\r\n | InnerNextPload| RESERVED2 |\r\n +---------------+---------------+---------------+---------------+\r\n | KINK Payloads (variable) |\r\n +---------------+---------------+---------------+---------------+\r\n\r\n| Figure 13b: unencrypted KINK_ENCRYPT Payload value\r\n\r\n Fields:\r\n\r\n\r\n(7b) typo, and (7a) continued\r\n\r\nThe final paragraph of Section 4.2.7, on page 23, says:\r\n\r\n vvvvvvvvvvvvvvvvvv\r\n| The format of the encryption payload follows the normal Kerberos\r\n semantics. Its content is the output of an encrypt function defined\r\n in the Encryption Algorithm Profile section of [KCRYPTO]. Parameters\r\n such as encrypt function itself, specific-key, and initial state are\r\n defined with the etype. [...]\r\n itself and there may be some garbage data at the end of the decrypted\r\n plaintext. A KINK implementation MUST be prepared to ignore such\r\n padding after the last sub-payload inside the KINK_ENCRYPT payload.\r\n [...]\r\n\r\nIt should say:\r\n\r\n vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv\r\n| The format of the encrypted KINK_ENCRYPT Payload value follows the\r\n normal Kerberos semantics. Its content is the output of an encrypt\r\n function defined in the Encryption Algorithm Profile section of\r\n| [KCRYPTO]. Parameters such as the encrypt function itself, specific-\r\n key, and initial state are defined with the etype. [...]\r\n", "correct_text": "", "notes": "\r\nItems (1)..(7) have been revised on the author's comments received.\r\nIn particular, item (7) has been revised substantially to achieve\r\na selfconsistent presentation in accordance with the author's intent.\r\nI propose to incorporate the above items (1)..(7) and (9) directly\r\ninto an RFC Errata Note.\r\nItem (8), and perhaps item (7) as well, still needs judgement from\r\nthe RFC authors.\r\n\r\n------------------------------------------------\r\nERRATA RESPONSE:\r\nFrom: Unknown Name (though from this email: Shouichi.Sakane@jp.yokogawa.com)\r\nCould someone verify 1a, 4b and 9b ?\r\n\r\nfrom pending", "submit_date": "2006-07-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "30", "doc-id": "RFC4664", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2.1", "orig_text": " Attachment PSN Attachment\r\n Circuits tunnel Circuits\r\n +\r\n +-----+ pseudo +-----+\r\n | | wire | |\r\n | CE1 |--+ +--| CE2 |\r\n | | | +-----+ +-----+ +-----+ | | |\r\n +-----+ +----|---- | | P | | ----+----+ +-----+\r\n |VPWS\\---|-----|-----|/VPWS|\r\n | PE1 |===|=====|=====| PE2 |\r\n | /|---|-----|-----|\\\\ |\r\n +-----+ +----|---- | | | | ----|----+ +-----+\r\n | | | +-----+ +-----+ +-----+ | | |\r\n | CE3 |--+ +--| CE4 |\r\n | | | |\r\n +-----+ +-----+", "correct_text": " Attachment PSN Attachment\r\n Circuits tunnel Circuits\r\n +\r\n +-----+ pseudo +-----+\r\n | | wire | |\r\n | CE1 |--+ +--| CE2 |\r\n | | | +-----+ +-----+ +-----+ | | |\r\n +-----+ +----|---- | | P | | ----+----+ +-----+\r\n |VPWS\\|---|-----|-----|/VPWS|\r\n | PE1 |===|=====|=====| PE2 |\r\n | /|---|-----|-----|\\ |\r\n +-----+ +----|---- | | | | ----|----+ +-----+\r\n | | | +-----+ +-----+ +-----+ | | |\r\n | CE3 |--+ +--| CE4 |\r\n | | | |\r\n +-----+ +-----+\r\n", "notes": "from pending", "submit_date": "2006-11-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "31", "doc-id": "RFC4661", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "11.2", "orig_text": " [17] Roach, A. B., Campbell, B., and J. Rosenberg, \"A Session\r\n Initiation Protocol (SIP) Event Notification Extension for\r\n Resource Lists\", RFC 4663, September 2006.", "correct_text": " [17] Roach, A. B., Campbell, B., and J. Rosenberg, \"A Session\r\n Initiation Protocol (SIP) Event Notification Extension for\r\n Resource Lists\", RFC 4662, August 2006.\r\n", "notes": "", "submit_date": "2006-11-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "32", "doc-id": "RFC4660", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "11.1", "orig_text": " [4] Roach, A.B., Campbell, B., and J. Rosenberg, \"A Session\r\n Initiation Protocol (SIP) Event Notification Extension for\r\n Resource Lists\", RFC 4663, September 2006.", "correct_text": " [4] Roach, A.B., Campbell, B., and J. Rosenberg, \"A Session\r\n Initiation Protocol (SIP) Event Notification Extension for\r\n Resource Lists\", RFC 4662, August 2006.", "notes": "", "submit_date": "2006-11-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "33", "doc-id": "RFC4650", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) word omission\r\n\r\nIn Section 1, the first text line on page 2 says:\r\n\r\n There is work done in IETF to develop key management schemes. [..]", "correct_text": "\r\nIt should say:\r\n\r\n| There is work done in the IETF to develop key management schemes.\r\n [..]", "notes": "from pending", "submit_date": "2006-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2388", "doc-id": "RFC2132", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1.2", "orig_text": "A DHCP server of \"server\"is an Internet host that returns configuration parameters to DHCP clients.\r\n", "correct_text": "A DHCP server or \"server\" is an Internet host that returns configuration parameters to DHCP clients.", "notes": "", "submit_date": "2010-07-21", "submitter_name": "Muhammad Yousaf", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2396", "doc-id": "RFC4985", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": "The second paragraph of Section 5 (on page 6 of RFC 4985) says:\r\n\r\n When X.509 certificates enhanced with the name form specified in this\r\n standard is used to enhance authentication of service discovery based\r\n on an SRV RR query to a DNS server, all security considerations of\r\n RFC 2782 applies.\r\n\r\n\r\n", "correct_text": " When X.509 certificates enhanced with the name form specified in this\r\n| standard are used to enhance authentication of service discovery\r\n based on an SRV RR query to a DNS server, all security considerations\r\n of RFC 2782 applies.", "notes": "", "submit_date": "2007-09-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2424", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "On mid-page 34, there is the code:\r\n\r\n/*\r\n * add \"length\" to the length\r\n */\r\nstatic uint32_t addTemp;\r\n#define SHA224_256AddLength(context, length) \\\r\n (addTemp = (context)->Length_Low, (context)->Corrupted = \\\r\n (((context)->Length_Low += (length)) < addTemp) && \\\r\n (++(context)->Length_High == 0) ? 1 : 0)\r\n\r\nIt should say (modifying the last line):\r\n\r\n/*\r\n * add \"length\" to the length\r\n */\r\nstatic uint32_t addTemp;\r\n#define SHA224_256AddLength(context, length) \\\r\n (addTemp = (context)->Length_Low, (context)->Corrupted = \\\r\n (((context)->Length_Low += (length)) < addTemp) && \\\r\n (++(context)->Length_High == 0) ? shaInputTooLong : shaSuccess )\r\n\r\nRationale: Same as for item (7) above.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2427", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "Similar to item (9) and (16) above, the Description of SHA256Result\r\ncontains improper wording and unpleasent formatting. Additionally,\r\ncounting 32 elements as ranging from the \"0th\" up to the \"32nd\" is\r\nunpleasant and wrong -- it would indicate 33 elements (octets) !\r\n\r\nOn page 39, the RFC says:\r\n\r\n * Description:\r\n * This function will return the 256-bit message\r\n * digest into the Message_Digest array provided by the caller.\r\n * NOTE: The first octet of hash is stored in the 0th element,\r\n * the last octet of hash in the 32nd element.\r\n\r\nFor correctness and consistency, and for improved readability,\r\nit should say:\r\n\r\n * Description:\r\n * This function will return the 256-bit message digest\r\n * into the Message_Digest array provided by the caller.\r\n * NOTE:\r\n * The first octet of the hash is stored in the element with index 0,\r\n * the last octet of the hash in the element with index 31.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "94", "doc-id": "RFC4428", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) [missing articles]\r\n\r\nIn Section 4.1, the third paragraph on page 7 says:\r\n\r\n In pre-OTN networks, a failure may be masked by intermediate O-E-O\r\n based Optical Line System (OLS), preventing a Photonic Cross-Connect\r\n (PXC) from detecting upstream failures. In such cases, failure\r\n detection may be assisted by an out-of-band communication channel,\r\n and failure condition may be reported to the PXC control plane. This\r\n can be provided by using [RFC4209] extensions that deliver IP\r\n message-based communication between the PXC and the OLS control\r\n plane. [...]\r\n\r\nIt should say:\r\n\r\n| In pre-OTN networks, a failure may be masked by an intermediate O-E-O\r\n based Optical Line System (OLS), preventing a Photonic Cross-Connect\r\n (PXC) from detecting upstream failures. In such cases, failure\r\n detection may be assisted by an out-of-band communication channel,\r\n| and a failure condition may be reported to the PXC control plane.\r\n This can be provided by using [RFC4209] extensions that deliver IP\r\n message-based communication between the PXC and the OLS control\r\n plane. [...]\r\n\r\n\r\n(2) [unexpected break]\r\n\r\nAgain on page 7, later on in the same paragraph as mentioned above,\r\nthe RFC says:\r\n\r\n [...]. If the intermediate OLS supports electrical (digital)\r\n mechanisms, using the LMP communication channel, these failure\r\n| conditions are reported to\r\n|\r\n the PXC and subsequent recovery actions are performed as described in\r\n Section 5. As such, from the control plane viewpoint, this mechanism\r\n turns the OLS-PXC-composed system into a single logical entity, thus\r\n having the same failure management mechanisms as any other O-E-O\r\n capable device.\r\n\r\nIt should say:\r\n\r\n [...]. If the intermediate OLS supports electrical (digital)\r\n mechanisms, using the LMP communication channel, these failure\r\n| conditions are reported to the PXC and subsequent recovery actions\r\n are performed as described in Section 5. As such, from the control\r\n plane viewpoint, this mechanism turns the OLS-PXC-composed system\r\n into a single logical entity, thus having the same failure management\r\n mechanisms as any other O-E-O capable device.\r\n\r\n\r\n(3) [incomplete wording]\r\n\r\nAt the end of Section 4.1, in the last bullet, on page 8, the RFC says:\r\n\r\n o with out-of-band communication between entities: entities are\r\n physically separated, but an out-of-band communication channel is\r\n provided between them (e.g., using [RFCF4204]).\r\n\r\nIt should say (according to the Verifier):\r\n\r\n o with out-of-band communication between entities: entities are\r\n physically separated, but an out-of-band communication channel is\r\n| provided between them (e.g., using LMP [RFC4204]).\r\n\r\n\r\n(4) [unexpected blank line]\r\n\r\nIn Section 5.5.1, the diagram for option '2. Overbooking', near the\r\nbottom of page 22, suffers from an unexpected blank line.\r\n\r\nThe RFC says:\r\n\r\n +----- Dedicated (for instance: 1+1, 1:1, etc.)\r\n |\r\n |\r\n|\r\n +----- Shared (for instance: 1:N, M:N, etc.)\r\n |\r\n Level of |\r\n Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)\r\n\r\nIt should say:\r\n\r\n +----- Dedicated (for instance: 1+1, 1:1, etc.)\r\n |\r\n |\r\n +----- Shared (for instance: 1:N, M:N, etc.)\r\n |\r\n Level of |\r\n Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)\r\n\r\n\r\n(5) [typo: missing underscore]\r\n\r\nIn Section 7.2, the second-to-last paragraph on page 29 says:\r\n\r\n In SONET/SDH environments, one typically considers the VT_SPE/LOVC\r\n and STS SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP\r\n uses the underlying STS_SPE/HOVC LSPs as links). [...]\r\n\r\nIt should say:\r\n\r\n In SONET/SDH environments, one typically considers the VT_SPE/LOVC\r\n| and STS_SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP\r\n uses the underlying STS_SPE/HOVC LSPs as links). [...]\r\n\r\n\r\n(6) [singular-->plural]\r\n\r\nIn Section 8, the second-to-last paragraph on page 33 says:\r\n\r\n [...]. For instance, it is obvious that\r\n providing a 1+1 LSP protection minimizes the LSP downtime (in case of\r\n| failure) while being non-scalable and consuming recovery resource\r\n without enabling any extra-traffic.\r\n ^^\r\nIt should say:\r\n\r\n [...]. For instance, it is obvious that\r\n providing a 1+1 LSP protection minimizes the LSP downtime (in case of\r\n| failure) while being non-scalable and consuming recovery resources\r\n without enabling any extra-traffic.\r\n\r\n\r\n(7) [singular-->plural]\r\n\r\nThe third paragraph of Section 8.2, on page 34, says:\r\n\r\n [...]. Dynamic restoration enables on-demand\r\n path computation based on the information received through failure\r\n notification message, and as such, it is more robust with respect to\r\n the failure scenario scope.\r\n\r\nIt should say (according to the Verifier):\r\n\r\n [...]. Dynamic restoration enables on-demand\r\n path computation based on the information received through failure\r\n| notification message(s), and as such, it is more robust with respect to\r\n the failure scenario scope.\r\n\r\n\r\n(8) [singular-->plural]\r\n\r\nAt the bottom of page 35, Section 8.3 of RFC 4428 says:\r\n\r\n [...]. Recovery schemes, in particular\r\n restoration, with pre-signaled resource reservation (with or without\r\n pre-selection) should be capable of reserving an adequate amount of\r\n resource to ensure recovery from any specific set of failure events,\r\n such as any single SRLG failure, any two SRLG failures, etc.\r\n\r\nIt should say:\r\n\r\n [...]. Recovery schemes, in particular\r\n restoration, with pre-signaled resource reservation (with or without\r\n pre-selection) should be capable of reserving an adequate amount of\r\n| resources to ensure recovery from any specific set of failure events,\r\n such as any single SRLG failure, any two SRLG failures, etc.\r\n\r\n\r\n(9) [punctuation: adjustment for 'logical quoting']\r\n\r\nIn Section 12.2, some Informative References, as found in the RFC,\r\ndo not conform to the RFC style guidelines regarding 'logical quoting'.\r\n\r\nE.g., the RFC says, at the bottom of page 44:\r\n\r\n [BOUILLET] E. Bouillet, et al., \"Stochastic Approaches to Compute\r\n Shared Meshed Restored Lightpaths in Optical Network\r\n| Architectures,\" IEEE Infocom 2002, New York City, June\r\n 2002.\r\n ^^\r\nIt should say:\r\n\r\n [BOUILLET] E. Bouillet, et al., \"Stochastic Approaches to Compute\r\n Shared Meshed Restored Lightpaths in Optical Network\r\n| Architectures\", IEEE Infocom 2002, New York City, June\r\n 2002.\r\n\r\nSimilar changes should be applied to the following entries on page 45:\r\n\r\n [DEMEESTER]\r\n [GLI]\r\n [KODIALAM1]\r\n [KODIALAM2]\r\n [MANCHESTER]\r\n [T1.105]\r\n [WANG]\r\n [G.707]\r\n [G.709]\r\n\r\nand on page 46:\r\n\r\n [G.783]\r\n [G.798]\r\n [G.841]\r\n [G.842]\r\n [G.874]", "correct_text": "", "notes": "from pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dimitri Papadimitriou", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "95", "doc-id": "RFC4427", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7.1", "orig_text": " Note that the restoration resources must be pre-computed, must\r\n be signaled, and may be selected a priori, but may not cross-\r\n connected. Thus, the restoration LSP is not able to carry any\r\n extra-traffic.", "correct_text": " Note that the restoration resources must be pre-computed, must\r\n be signaled, and may be selected a priori, but may not be cross-\r\n connected. Thus, the restoration LSP is not able to carry any\r\n extra-traffic.", "notes": "missing verb\r\n\r\nfrom pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dimitri Papadimitriou", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2571", "doc-id": "RFC5810", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7.1.6", "orig_text": "multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can", "correct_text": "multiple errors in a single leaf PATH-DATA/FULLDATA-TLV, the FE can", "notes": "", "submit_date": "2010-10-16", "submitter_name": "Jamal Hadi Salim", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2404", "doc-id": "RFC4226", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "A.3", "orig_text": " Oracle AuthO()\r\n --------------\r\n A = ALG(K,C)\r\n C = C + 1\r\n Return O to B\r\n\r\n Oracle VerO(A)\r\n --------------\r\n i = C\r\n While (i <= C + s - 1 and Win == FALSE) do\r\n If A == ALG(K,i) then Win = TRUE; C = i + 1\r\n Else i = i + 1\r\n Return Win to B", "correct_text": " Oracle AuthO()\r\n --------------\r\n A = ALG(K,C)\r\n C = C + 1\r\n| Return A to B\r\n\r\n Oracle VerO(A)\r\n --------------\r\n| i = C'\r\n| While (i <= C' + s - 1 and Win == FALSE) do\r\n| If A == ALG(K,i) then Win = TRUE; C' = i + 1\r\n Else i = i + 1\r\n Return Win to B", "notes": "another typo, and continuation of Errata ID 2402.\r\n\r\nStill in Appendix A.3, the text on the upper half of page 19 contains\r\na wrong (undefined) variable name 'O' which should be 'A' instead,\r\nand it should be adapted according to [Errata ID 2402].", "submit_date": "2006-01-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2398", "doc-id": "RFC2453", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.4", "orig_text": "A proof is given in [2] that this algorithm ....", "correct_text": "A proof is given in [5] that this algorithm....", "notes": "On page 8\r\nCorrect the reference.", "submit_date": "2010-07-29", "submitter_name": "Zdenek", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2406", "doc-id": "RFC4226", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "Appendix A.4.3 says:", "orig_text": " Proposition 2 ------------- Suppose m = 10^Digit < 2^31, and let\r\n (q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP-IDEAL\r\n using v verification oracle queries and a <= 2^c - s authenticator\r\n oracle queries. Then [...]\r\n", "correct_text": " Proposition 2\r\n -------------\r\n\r\n Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B\r\n be any adversary attacking HOTP-IDEAL using v verification oracle\r\n queries and a <= 2^c - s authenticator oracle queries. Then [...]", "notes": "", "submit_date": "2006-01-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2408", "doc-id": "RFC4226", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "C", "orig_text": " // These are used to calculate the check-sum digits.\r\n| // 0 1 2 3 4 5 6 7 8 9\r\n private static final int[] doubleDigits =\r\n { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };", "correct_text": " // These are used to calculate the check-sum digits.\r\n| // 0 1 2 3 4 5 6 7 8 9\r\n private static final int[] doubleDigits =\r\n { 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };", "notes": "formatting.\r\n\r\nIn Appendix C, the source text in the upper half of page 28\r\ncontains an improperly formatted comment -- obviously intended\r\nto illustrate the subsequent declaration, the comment must be\r\naligned with that declaration.", "submit_date": "2006-01-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2415", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.1", "orig_text": "The initial Description in the file, on page 18 of the RFC, says:\r\n\r\n vvvvvvvvvvvvvvvvvv\r\n * Description:\r\n * This file implements the Secure Hash Signature Standard\r\n * algorithms as defined in the National Institute of Standards\r\n * and Technology Federal Information Processing Standards\r\n * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2\r\n * published on August 1, 2002, and the FIPS PUB 180-2 Change\r\n * Notice published on February 28, 2004.\r\n", "correct_text": "It should say:\r\n\r\n * Description:\r\n|* This file implements the Secure Hash Algorithms\r\n * as defined in the National Institute of Standards\r\n * and Technology Federal Information Processing Standards\r\n * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2\r\n * published on August 1, 2002, and the FIPS PUB 180-2 Change\r\n * Notice published on February 28, 2004.", "notes": "Avoiding the term \"Signature\" in accordance with the Standards\r\nmentioned. The NIST consistently uses the acronyms \"SHA\" for\r\n\"Secure Hash Algorithm\" and \"SHS\" for \"Secure Hash Standard\"\r\nand precisely distinguished between these two terms.", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2426", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "Similar to item (9) above, the Description comment of SHA224Result\r\ncontains improper wording and unpleasent formatting. Additionally,\r\ncounting 28 elements as ranging from the \"0th\" up to the \"28th\" is\r\nunpleasant and wrong -- it would indicate 29 elements (octets) !\r\n\r\nOn mid-page 36, the RFC says:\r\n\r\n * Description:\r\n * This function will return the 224-bit message\r\n * digest into the Message_Digest array provided by the caller.\r\n * NOTE: The first octet of hash is stored in the 0th element,\r\n * the last octet of hash in the 28th element.\r\n\r\nFor correctness and consistency, and for improved readability,\r\nit should say:\r\n\r\n * Description:\r\n * This function will return the 224-bit message digest\r\n * into the Message_Digest array provided by the caller.\r\n * NOTE:\r\n * The first octet of the hash is stored in the element with index 0,\r\n * the last octet of the hash in the element with index 27.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2455", "doc-id": "RFC4322", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.3", "orig_text": "The first senrtence of Section 9.3, on page 34, says:\r\n\r\n Tunnels sometimes go down because the remote end crashes,\r\n disconnects, or has a network link break. [...]\r\n\r\nThe 'line break' might occor at any place within the network,\r\nnot just at the 'remote end'.\r\nTherefore, the text should better say:\r\n\r\n Tunnels sometimes go down because the remote end crashes,\r\n| disconnects, or a network link break occurs. [...]", "correct_text": "", "notes": "To facilitate the recognition of the text changes proposed,\r\nI have added change bars ('|') in column 1, and up/down pointing\r\nmarker lines ('^^^'/'vvv').", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "34", "doc-id": "RFC4646", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Appendix B says:", "orig_text": " sl-rozaj (Resian dialect of Slovenian", "correct_text": " sl-rozaj (Resian dialect of Slovenian)", "notes": "Missing \")\"", "submit_date": "2006-09-29", "submitter_name": "", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5156", "doc-id": "RFC2819", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1", "orig_text": "device has to deal with more than own management station", "correct_text": "device has to deal with more than one management station", "notes": "Seems to be carried forward from RFC 1757", "submit_date": "2017-10-16", "submitter_name": "Joel Nelson", "verifier_id": "", "verifier_name": "Benoit Claise", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "429", "doc-id": "RFC2486", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " nai = username / ( username \"@\" realm )\n username = dot-string\n realm = realm \".\" label", "correct_text": " realm = [realm \".\"] label\n", "notes": "", "submit_date": "2003-02-12", "submitter_name": "Jonathan Rosenberg", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "430", "doc-id": "RFC2464", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "The URL in this reference is incorrect:\n", "orig_text": " [EUI64] \"Guidelines For 64-bit Global Identifier (EUI-64)\",\n http://standards.ieee.org/db/oui/tutorials/EUI64.html", "correct_text": " [EUI64] \"Guidelines For 64-bit Global Identifier (EUI-64)\",\n http://standards.ieee.org/regauth/oui/tutorials/EUI64.html\n", "notes": "", "submit_date": "2004-04-29", "submitter_name": "Peter Koch", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "35", "doc-id": "RFC4641", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.1.1", "orig_text": " Pre-publish key rollover involves four stages as follows:\r\n\r\n ----------------------------------------------------------------\r\n initial new DNSKEY new RRSIGs DNSKEY removal\r\n ----------------------------------------------------------------\r\n SOA0 SOA1 SOA2 SOA3\r\n RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)\r\n\r\n DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1\r\n DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11\r\n DNSKEY11 DNSKEY11\r\n RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)\r\n RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)\r\n ----------------------------------------------------------------", "correct_text": " Pre-publish key rollover involves four stages as follows:\r\n\r\n ----------------------------------------------------------------\r\n initial new DNSKEY new RRSIGs DNSKEY removal\r\n ----------------------------------------------------------------\r\n SOA0 SOA1 SOA2 SOA3\r\n RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)\r\n\r\n DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1\r\n DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11\r\n| DNSKEY11 DNSKEY11\r\n RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)\r\n RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)\r\n ----------------------------------------------------------------\r\n\r\n Pre-Publish Key Rollover", "notes": "The mis-alignment of the indicated line breaks the intended\r\npresentation of the procedure; cf. subsequent RFC text.\r\n\r\n\r\nfrom pending", "submit_date": "2006-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Olaf Kolkman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "36", "doc-id": "RFC4640", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "12", "orig_text": " [RFC3776] Galvin, J., \"IAB and IESG Selection, Confirmation, and\r\n Recall Process: Operation of the Nominating and Recall\r\n Committees\", BCP 10, RFC 3777, June 2004.", "correct_text": " [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, \"Using IPsec to \r\n Protect Mobile IPv6 Signaling Between Mobile Nodes and Home \r\n Agents\", RFC 3776, June 2004.", "notes": "In Section 12, near the bottom of page 20, a strange accident must\r\nhave hit the Ref. tagged [RFC3776]. This indeed should be a citation of the Mobile IP related RFC 3776, but it is a citiation of the unrelated RFC 3777.\r\n", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "37", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.1", "orig_text": "The Description of SHA1PadMessage, on page 30, says:\r\n\r\n * Description:\r\n * According to the standard, the message must be padded to an\r\n * even 512 bits. The first padding bit must be a '1'. The last\r\n * 64 bits represent the length of the original message. All bits\r\n * in between should be 0. This helper function will pad the\r\n * message according to those rules by filling the Message_Block\r\n * array accordingly. When it returns, it can be assumed that the\r\n * message digest has been computed.\r\n\r\nFor clarity, it should say:\r\n\r\n * Description:\r\n|* According to the standard, the message must be padded to the next\r\n|* proper multiple of 512 bits. The first padding bit must be a '1'.\r\n * The last 64 bits represent the length of the original message.\r\n * All bits in between should be 0. This helper function will pad\r\n * the message according to those rules by filling the Message_Block\r\n * array accordingly. When it returns, it can be assumed that the\r\n * message digest has been computed.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2421", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.1", "orig_text": "The Description of SHA1ProcessMessageBlock, on page 31, says:\r\n\r\n * Parameters:\r\n * None.\r\n\r\nThis is not true, as can be seen subsequently in the source code.\r\nThe RFC should say:\r\n\r\n * Parameters:\r\n * context: [in/out]\r\n * The SHA context to update", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2422", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "The initial Description in this file, on page 33, says:\r\n\r\n * Description:\r\n * This file implements the Secure Hash Signature Standard\r\n * algorithms as defined in the National Institute of Standards\r\n * and Technology Federal Information Processing Standards\r\n * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2\r\n * published on August 1, 2002, and the FIPS PUB 180-2 Change\r\n * Notice published on February 28, 2004.\r\n\r\nIt should say:\r\n\r\n * Description:\r\n * This file implements the Secure Hash Algorithms SHA-224 and\r\n * SHA-256, as defined in the National Institute of Standards\r\n * and Technology Federal Information Processing Standards\r\n * Publication (FIPS PUB) 180-2 published on August 1, 2002, and\r\n * the FIPS PUB 180-2 Change Notice published on February 28, 2004.\r\n\r\nRationale:\r\n\r\nFIPS-PUB 180-1 only specified SHA-1, neither SHA-224 nor SHA-256.\r\nFIPS-PUB 180-2 has introduced SHA-256 (and SHA-384 and SHA-512 as\r\nwell), and SHA-224 has been introduced by the \"Change Notice 1\".\r\nThus, citation of FIPS PUB 180-1 is void and inappropriate in the\r\ncontext of SHA-224 and SHA-256.\r\nAvoiding the term \"Signature\" also conforms to the above Standards\r\n-- cf. item (4) and (5) above.\r\nRestricting the text to the scope of the file -- cf. item (5) above.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2423", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "The comment text, near the bottom of page 33, says:\r\n\r\n * Caveats:\r\n * SHA-224 and SHA-256 are designed to work with messages less\r\n * than 2^64 bits long. This implementation uses SHA224/256Input()\r\n * to hash the bits that are a multiple of the size of an 8-bit\r\n * character, and then uses SHA224/256FinalBits() to hash the\r\n * final few bits of the input.\r\n\r\nIt should better say -- cf. item (6) above:\r\n\r\n * Caveats:\r\n * SHA-224 and SHA-256 are designed to work with messages less\r\n * than 2^64 bits long. This implementation uses SHA224/256Input()\r\n * to hash the bits that are a multiple of the size of an 8-bit\r\n|* character, and then optionally uses SHA224/256FinalBits()\r\n * to hash the final few bits of the input.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2241", "doc-id": "RFC4880", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "12.2.", "orig_text": " The fingerprint of a V3 key is formed by hashing the body (but not\r\n the two-octet length) of the MPIs that form the key material (public\r\n modulus n, followed by exponent e) with MD5.", "correct_text": " The fingerprint of a V3 key is formed by hashing the concatenation\r\n of the bodies of the MPIs (MPI without two-octet length) that form\r\n the key material (public modulus n, followed by exponent e) with MD5.", "notes": "There are two bodies and one hash.\r\n\r\nChanged to editorial.\n --VERIFIER NOTES-- \nIt could have been: \r\n\r\n... by hashing the body (but not the two-octet length) of the two MPIs \r\n ^^^\r\n\r\nBut, it's clear from the parenthetical that there are two MPIs.", "submit_date": "2010-04-28", "submitter_name": "Constantin Hagemeier", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2429", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "The Description of SHA224_256PadMessage, near the bottom of page 40,\r\nsays:\r\n\r\n * Description:\r\n * According to the standard, the message must be padded to an\r\n * even 512 bits. The first padding bit must be a '1'. The\r\n * last 64 bits represent the length of the original message.\r\n * All bits in between should be 0. This helper function will pad\r\n * the message according to those rules by filling the\r\n * Message_Block array accordingly. When it returns, it can be\r\n * assumed that the message digest has been computed.\r\n\r\nFor clarity, it should say (cf. item (10) above):\r\n\r\n * Description:\r\n|* According to the standard, the message must be padded to the next\r\n|* proper multiple of 512 bits. The first padding bit must be a '1'.\r\n * The last 64 bits represent the length of the original message.\r\n * All bits in between should be 0. This helper function will pad\r\n * the message according to those rules by filling the\r\n * Message_Block array accordingly. When it returns, it can be\r\n * assumed that the message digest has been computed.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2435", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "Within the '#ifdef USE_32BIT_ONLY' macro definition branch of the\r\nfile, on mid-page 50 the RFC says:\r\n\r\n/*\r\n * add \"length\" to the length\r\n */\r\nstatic uint32_t addTemp[4] = { 0, 0, 0, 0 };\r\n#define SHA384_512AddLength(context, length) ( \\\r\n addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \\\r\n (context)->Corrupted = (((context)->Length[3] == 0) && \\\r\n ((context)->Length[2] == 0) && ((context)->Length[1] == 0) && \\\r\n ((context)->Length[0] < 8)) ? 1 : 0 )\r\n\r\nIt should say:\r\n\r\n/*\r\n * add \"length\" to the length\r\n */\r\nstatic uint32_t addTemp[4] = { 0, 0, 0, 0 };\r\n#define SHA384_512AddLength(context, length) ( \\\r\n addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \\\r\n (context)->Corrupted = (((context)->Length[0] < addTemp[3]) && \\\r\n ((context)->Length[1] == 0) && ((context)->Length[1] == 0) && \\\r\n ((context)->Length[0] == 0)) ? shaInputTooLong : shaSuccess )\r\n\r\nRationale:\r\n\r\nThe context words Lenght[0] ... Length[3] represent the unsigned\r\n128-bit-wide running (bit-)length of the message text hash so far,\r\nin most-significant word first order.\r\nThe code fragment above is intended to add to this value the\r\nunsigned 32-bit value (uint32_t) length, and to detect overflow\r\n(to 2^128 and above).\r\nThe given code is wrong.\r\n(Apparently it has never been tested with messages long enough to\r\nexhibit this misbehaviour.)\r\nOther parts of the sample code show how this can be done correctly\r\nin the case of long accumulators consisting of two 32-bit words\r\n-- cf. the code snippits in item (7) and (14) above, and item (27)\r\nbelow, as well,\r\nThe replacement code corrects this issue.\r\n\r\nFurthermore, the original code suffers from the same problem as\r\nin item (7) and (14) above; this has been corrected accordingly,\r\nas well.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2437", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "The sample code presents almost all formal function arguments of type\r\narray with predefined (constant) length with this explicit length.\r\nContrary to that, the function prototypes for SHA384_512Reset do not\r\nsupply the expected size of the formal argument 'H0'.\r\nThis inconsistency should be corrected -- as in item (18) above.\r\n\r\nThere are two instances of the issue (see item (xx) below for\r\nanother two similar instances, with the function declarations):\r\n\r\n(28a)\r\nWithin the function prototype definition part of the\r\n '#ifdef USE_32BIT_ONLY'\r\nbranch of the sample code, near the bottom of page 50, the RFC says:\r\n\r\nstatic int SHA384_512Reset(SHA512Context *context, uint32_t H0[]);\r\n\r\nFor consistency and clarity, it should say:\r\n\r\nstatic int SHA384_512Reset(SHA512Context *context,\r\n uint32_t H0[SHA512HashSize/4]);\r\n\r\n(28b)\r\nWithin the function prototype definition part of the\r\n '#else /* !USE_32BIT_ONLY */'\r\nbranch of the sample code, near the bottom of page 51, the RFC says:\r\n\r\nstatic int SHA384_512Reset(SHA512Context *context, uint64_t H0[]);\r\n\r\nFor consistency and clarity, it should say:\r\n\r\nstatic int SHA384_512Reset(SHA512Context *context,\r\n uint64_t H0[SHA512HashSize/8]);", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2441", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "Similar to item (9), (16), (17), (22), (29), and (30) above, the\r\nDescription of SHA384_512ResultN contains improper wording.\r\nAdditionally, counting 48/64 elements as ranging from the \"0th\" up to\r\nthe \"48th/64nd\" is unpleasant and wrong -- that erroneously indicates\r\n49/65 elements (octets) !\r\n\r\nOn page 65/66, the RFC says:\r\n\r\n * Description:\r\n * This helper function will return the 384-bit or 512-bit message\r\n<< page break >>\r\n * digest into the Message_Digest array provided by the caller.\r\n * NOTE: The first octet of hash is stored in the 0th element,\r\n * the last octet of hash in the 48th/64th element.\r\n\r\nFor correctness, it should say:\r\n\r\n * Description:\r\n * This helper function will return the 384-bit or 512-bit message\r\n<< page break >>\r\n * digest into the Message_Digest array provided by the caller.\r\n * NOTE:\r\n * The first octet of the hash is stored in the element with index 0,\r\n * the last octet of the hash in the element with index 47/63.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "38", "doc-id": "RFC4632", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "2", "orig_text": " 3. Eventual exhaustion of the 32-bit IPv4 address space.\r\n\r\n It was clear that then-current rates of Internet growth would\r\n cause the first two problems to become critical sometime between\r\n 1993 and 1995. Work already in progress on topological\r\n assignment of addressing for Connectionless Network Service\r\n (CLNS), which was presented to the community at the Boulder IETF\r\n in December of 1990, led to thoughts on how to re-structure the\r\n 32-bit IPv4 address space to increase its lifespan. Work in the\r\n ROAD group followed and eventually resulted in the publication of\r\n [RFC1338], and later, [RFC1519].\r\n\r\n The design and deployment of CIDR was intended to solve these\r\n problems by providing a mechanism to slow the growth of global\r\n routing tables and to reduce the rate of consumption of IPv4\r\n address space. It did not and does not attempt to solve the\r\n third problem, which is of a more long-term nature; instead, it\r\n endeavors to ease enough of the short- to mid-term difficulties\r\n to allow the Internet to continue to function efficiently while\r\n progress is made on a longer-term solution.\r\n\r\n More historical background on this effort and on the ROAD group\r\n may be found in [RFC1380] and at [LWRD].\r\n\r\n3. Classless Addressing as a Solution", "correct_text": " 3. Eventual exhaustion of the 32-bit IPv4 address space.\r\n\r\n It was clear that then-current rates of Internet growth would\r\n cause the first two problems to become critical sometime between\r\n 1993 and 1995. Work already in progress on topological\r\n assignment of addressing for Connectionless Network Service\r\n (CLNS), which was presented to the community at the Boulder IETF\r\n in December of 1990, led to thoughts on how to re-structure the\r\n 32-bit IPv4 address space to increase its lifespan. Work in the\r\n ROAD group followed and eventually resulted in the publication of\r\n [RFC1338], and later, [RFC1519].\r\n\r\n The design and deployment of CIDR was intended to solve these\r\n problems by providing a mechanism to slow the growth of global\r\n routing tables and to reduce the rate of consumption of IPv4\r\n address space. It did not and does not attempt to solve the\r\n third problem, which is of a more long-term nature; instead, it\r\n endeavors to ease enough of the short- to mid-term difficulties\r\n to allow the Internet to continue to function efficiently while\r\n progress is made on a longer-term solution.\r\n\r\n More historical background on this effort and on the ROAD group\r\n may be found in [RFC1380] and at [LWRD].\r\n\r\n3. Classless Addressing as a Solution", "notes": "In Section 2, on page 4 of RFC 4632, the text after the\r\nenumerated item '3.' up to the end of the section is indented\r\ntoo much (by 4 columns), making it erroneously appear to belong\r\nto that item '3.'\r\n\r\n--VERIFIER COMMENT--\r\nThank you very much for your eagle eyes and your comments. I agree\r\nwith all of them. If you had submitted them during the Internet-draft\r\nprocess, I would make all of these modifications immediately.\r\nHowever, now that the RFC is issued, I believe that we should be quite\r\na bit more conservative before issuing Errata, so as to not congest\r\nthe Errata and obscure vital and substantive changes that might affect\r\nactual interoperability of standards interpretation. With that view\r\nin mind, I'd like to suggest that we not issue any Errata at this\r\ntime. I look forward to your input on subsequent draft documents.\r\n", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tony Li", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "585", "doc-id": "RFC1321", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.4", "orig_text": "/* Round 4. */\r\n /* Let [abcd k s t] denote the operation\r\n a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */", "correct_text": "/* Round 4. */\r\n /* Let [abcd k s i] denote the operation\r\n a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */", "notes": "", "submit_date": "2002-06-14", "submitter_name": "Gregory Smith", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2242", "doc-id": "RFC4880", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "13.1.3.", "orig_text": " mL = intended length in octets of the encoded message, at least tLen\r\n + 11, where tLen is the octet length of the DER encoding T of a\r\n certain value computed during the encoding operation", "correct_text": " emLen = intended length in octets of the encoded message, at least\r\n tLen + 11, where tLen is the octet length of the DER encoding T\r\n of a certain value computed during the encoding operation", "notes": "In the following text it is called emLen.\r\n\r\nChanged to editorial.", "submit_date": "2010-04-28", "submitter_name": "Constantin Hagemeier", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "6808", "doc-id": "RFC4568", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "9.2", "orig_text": "srtp-crypto-suite = \"AES_CM_128_HMAC_SHA1_32\" /\r\n \"F8_128_HMAC_SHA1_32\" /\r\n \"AES_CM_128_HMAC_SHA1_80\" /\r\n srtp-crypto-suite-ext\r\n", "correct_text": "srtp-crypto-suite = \"AES_CM_128_HMAC_SHA1_32\" /\r\n \"F8_128_HMAC_SHA1_80\" /\r\n \"AES_CM_128_HMAC_SHA1_80\" /\r\n srtp-crypto-suite-ext\r\n", "notes": "Section 6.2.3 uses 80 bit for F8 (IANA registration)", "submit_date": "2022-01-05", "submitter_name": "Fritz", "verifier_id": "", "verifier_name": null, "update_date": null}, {"errata_id": "39", "doc-id": "RFC4631", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "7", "orig_text": " In lmpDataLinkTable:\r\n {", "correct_text": " In lmpDataLinkTable:\r\n {", "notes": "spurious indentation\r\n\r\nfrom pending\r\n\r\n--VERIFIER COMMENT--\r\nWhile many of these comments would undoubtedly have led to a more polished \r\nfinal RFC it is fortunate that none of them makes the document in any way \r\nharder to read or less technically meaningful. I am sure that if and when \r\nthe RFC progresses from Proposed Standard to Draft Standard we can look back \r\nat this list to ensure that your comments are addressed.\r\n\r\nIn future, however, I would urge you to make comments on the content and \r\nformat of CCAMP documents as they progress through the working group or \r\nduring IETF last call. Comments made later than that are very unlikely to be \r\nconsidered by the authors for inclusion, but comments made earlier in the \r\nprocess are very likely to be included.\r\n\r\nObviously, if issues of technical clarity or understanding do come up later \r\nthan this, we can address them through Errata while a new revision of the \r\nRFC is prepared. On the other hand, Errata are probably not well used for \r\nrecording small format errors in the text as these are not strictly errors \r\nof content or substance.", "submit_date": "2006-11-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "40", "doc-id": "RFC4623", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.5", "orig_text": " 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n |M|H|0|0|0|0| Length | 0 |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n |x|S|B|E|x|x|x|x| Sequence Number |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |x|S|B|E|x|x|x|x| Sequence Number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "notes": "Extraneous part of the AVP Header in Figure 6.", "submit_date": "2006-10-25", "submitter_name": "Carlos Pignataro", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "41", "doc-id": "RFC4619", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "1", "orig_text": " The main functions required to support frame relay PW by a\r\n Provider Edge (PE) include:", "correct_text": " The main functions required to support frame relay PWs by a\r\n Provider Edge (PE) include:\r\n", "notes": "from pending", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Andrew G. Malis", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "42", "doc-id": "RFC4612", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4", "orig_text": " Additional information:\r\n\r\n Magic number(s): File extension(s): Macintosh File Type Code(s):", "correct_text": " Additional information:\r\n\r\n Magic number(s):\r\n File extension(s):\r\n Macintosh File Type Code(s):", "notes": "line folding issue", "submit_date": "2006-08-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "55", "doc-id": "RFC4570", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "6", "orig_text": " Purpose: See this document\r\n Reference: This document\r\n Values: See this document, and registrations below", "correct_text": " Purpose: See RFC 4632\r\n Reference: RFC 4632\r\n Values: See RFC 4632", "notes": "The filled out SDP attribute registration template in the IANA\r\nConsiderations (Section 6) on page 10 contains improper wording\r\n-- either just being garbage (there are no 'registrations below'\r\nin the RFC), or getting inappropriate when extracted from the RFC\r\nand included in a stand-alone IANA document.\r\n\r\n--VERIFIER COMMENT--\r\nThanks for the comments. It would have been nice if these very minor\r\nerrors could have been corrected prior to RFC publication. However,\r\nI'm not convinced that they are significant enough to warrant a RFC\r\nErrata note. (If, however, the RFC editor disagrees, then I could\r\ncertainly go ahead and do this.)", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Ross Finlayson", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "56", "doc-id": "RFC4567", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "The abstract says:", "orig_text": " General guidelines are also given on how the framework should be used\r\n together with SIP and RTSP. The usage with the Multimedia Internet\r\n KEYing (MIKEY) key management protocol is also defined.", "correct_text": " General guidelines are also given on how the framework should be used\r\n together with SIP and SAP. The usage with the Multimedia Internet\r\n KEYing (MIKEY) key management protocol is also defined.", "notes": " As can be seen from the title and the body of the RFC, and\r\nas has been correctly stated in the first paragraph of the Abstract,\r\nthe RFC primarily deals with SDP and RTSP; it \"also\" considers the use\r\nof the SDP extensions with SIP (Section 4.1.2) and SAP (Section 4.1.3).\r\nHence, SAP should be mentioned in the second paragraph of the Abstract\r\ninstead of RTSP.", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "57", "doc-id": "RFC4566", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(1) typo\r\n\r\nOn page 7 of RFC 4566, Section 4.6 says:\r\n\r\n The SDP specification recommends the use of the ISO 10646 character\r\n| sets in the UTF-8 encoding [5] to allow many different languages to\r\n be represented. However, to assist in compact representations, SDP\r\n also allows other character sets such as ISO 8859-1 to be used when\r\n desired. Internationalisation only applies to free-text fields\r\n (session name and background information), and not to SDP as a whole.\r\n\r\nIt should say:\r\n\r\n The SDP specification recommends the use of the ISO 10646 character\r\n| set in the UTF-8 encoding [5] to allow many different languages to\r\n be represented. However, to assist in compact representations, SDP\r\n also allows other character sets such as ISO 8859-1 to be used when\r\n desired. Internationalisation only applies to free-text fields\r\n (session name and background information), and not to SDP as a whole.\r\n\r\n\r\n(2) inconsistent specification\r\n\r\nContrary to the text in Section 4.6 (see above), Section 5 of RFC 4566\r\nspecifies, at the bottom of page 7:\r\n\r\n An SDP session description is entirely textual using the ISO 10646\r\n character set in UTF-8 encoding. SDP field names and attribute names\r\n use only the US-ASCII subset of UTF-8, but textual fields and\r\n attribute values MAY use the full ISO 10646 character set. [...]\r\n\r\nThese conflicting specifications might become a source of\r\ninteroperability problems, and therefore, the conflict should be\r\nresolved by a clarification !!!\r\n\r\nNote: Subsequent text in sections 5.* specifies behaviour related\r\nto the \"a=charset\" attribute required if other charsets than UTF-8\r\nare used in certain fields; therefore, the latter exclusive UTF-8\r\nrule is most probably too restrictive and hence inappropriate.\r\n\r\n\r\n(3) misleading text / inconsistency + typo (missing article)\r\n\r\nStill in Section 5, the second-to-last paragraph on page 8 of RFC 4566\r\nsays:\r\n\r\n An SDP session description consists of a session-level section\r\n followed by zero or more media-level sections. The session-level\r\n part starts with a \"v=\" line and continues to the first media-level\r\n| section. Each media-level section starts with an \"m=\" line and\r\n| continues to the next media-level section or end of the whole session\r\n description. In general, session-level values are the default for\r\n all media unless overridden by an equivalent media-level value.\r\n\r\nThe second sentence does not accomodate for an important corner case\r\nmentioned in the first sentence, and thus should be amended with\r\nsimilar wording as below. The third sentence is imprecise as well,\r\nbecause the \"or\" does not uniquely select the 'right' condition.\r\n\r\nIt should better say:\r\n\r\n An SDP session description consists of a session-level section\r\n followed by zero or more media-level sections. The session-level\r\n part starts with a \"v=\" line and continues to the first media-level\r\n| section (or the end of the whole description, whichever comes first).\r\n Each media-level section starts with an \"m=\" line and continues to\r\n| the next media-level section or the end of the whole session\r\n| description - whichever comes first. In general, session-level\r\n values are the default for all media unless overridden by an\r\n equivalent media-level value.\r\n\r\n\r\n(4) significant mis-specification\r\n\r\nIn the \"Session description\" block, on top of page 9, the RFC says:\r\n\r\n c=* (connection information -- not required if included in\r\n all media)\r\n b=* (zero or more bandwidth information lines)\r\n\r\nIt should say:\r\n\r\n c=* (connection information -- not required if included in\r\n all media descriptions)\r\n b=* (zero or more bandwidth information lines)\r\n\r\nRationale:\r\nStrictly differentiating between \"media\" and \"media description\"\r\nis always required to avoid confusion! ...\r\nAnd connection information is rarely (if ever) seen in the media!\r\n\r\n\r\n(5) improper wording related with IP addresses\r\n\r\nIP addresses (in IPv4 and IPv6) are always assigned to an interface,\r\nnot to a host or 'machine'. Therefore, a Standards Track RFC\r\nshould never talk about '*the* IP address of a machine'.\r\nFQDNs are also not necessarily unique for a 'machine', e.g. a server\r\nhaving multiple, 'role-based' FQDNs.\r\n\r\nTherefore, in Section 5.2, the last paragraph on page 11,\r\n\r\n| is the address of the machine from which the\r\n session was created. For an address type of IP4, this is either\r\n| the fully qualified domain name of the machine or the dotted-\r\n| decimal representation of the IP version 4 address of the machine.\r\n| For an address type of IP6, this is either the fully qualified\r\n domain name of the machine or the compressed textual\r\n| representation of the IP version 6 address of the machine. For\r\n both IP4 and IP6, the fully qualified domain name is the form that\r\n| SHOULD be given unless this is unavailable, in which case the\r\n globally unique address MAY be substituted. A local IP address\r\n MUST NOT be used in any context where the SDP description might\r\n leave the scope in which the address is meaningful (for example, a\r\n local address MUST NOT be included in an application-level\r\n referral that might leave the scope).\r\n\r\nshould say:\r\n\r\n| is an address of the machine from which the\r\n session was created. For an address type of IP4, this is either\r\n| a fully qualified domain name of the machine or the dotted-\r\n| decimal representation of an IP version 4 address of the machine.\r\n| For an address type of IP6, this is either a fully qualified\r\n domain name of the machine or the compressed textual\r\n| representation of an IP version 6 address of the machine. For\r\n both IP4 and IP6, the fully qualified domain name is the form that\r\n| SHOULD be given unless this is unavailable, in which case a\r\n globally unique address MAY be substituted. A local IP address\r\n MUST NOT be used in any context where the SDP description might\r\n leave the scope in which the address is meaningful (for example, a\r\n local address MUST NOT be included in an application-level\r\n referral that might leave the scope).\r\n\r\n\r\n(6) improper term used\r\n\r\na)\r\nSection 5.6 twice uses the term, \"conference\", where IMHO, according\r\nto the definitions given in Section 2, the term, \"session\" should\r\nbe used. This change makes the text better conform with the\r\nclassification of the \"e=\" and \"p=\" lines on page 9, as well.\r\n\r\nThe first textual paragraph of Section 5.6, on page 13, says:\r\n\r\n The \"e=\" and \"p=\" lines specify contact information for the person\r\n| responsible for the conference. This is not necessarily the same\r\n| person that created the conference announcement.\r\n\r\nIt should say:\r\n\r\n The \"e=\" and \"p=\" lines specify contact information for the person\r\n| responsible for the session. This is not necessarily the same person\r\n| that created the session announcement.\r\n\r\nb)\r\nAnother instance of this issue occurs in Section 5.7, at the bottom\r\nof page 14. There, the RFC says:\r\n\r\n o Sessions using an IPv4 multicast connection address MUST also have\r\n a time to live (TTL) value present in addition to the multicast\r\n address. The TTL and the address together define the scope with\r\n| which multicast packets sent in this conference will be sent. TTL\r\n values MUST be in the range 0-255. [...]\r\n\r\nIt should say:\r\n\r\n o Sessions using an IPv4 multicast connection address MUST also have\r\n a time to live (TTL) value present in addition to the multicast\r\n address. The TTL and the address together define the scope with\r\n| which multicast packets sent in this session will be sent. TTL\r\n values MUST be in the range 0-255. [...]\r\n\r\nc)\r\nFinally, the last sentence of the second paragraph of Section 5.13,\r\non page 21,\r\n\r\n [...]. Attribute\r\n fields can also be added before the first media field; these\r\n \"session-level\" attributes convey additional information that applies\r\n to the conference as a whole rather than to individual media.\r\n\r\nshould say, accordingly:\r\n\r\n [...]. Attribute\r\n fields can also be added before the first media field; these\r\n \"session-level\" attributes convey additional information that applies\r\n| to the session as a whole rather than to individual media.\r\n\r\n\r\n(7) clarification\r\n\r\nThe second paragraph of Section 5.9, on page 17, says:\r\n\r\n The first and second sub-fields give the start and stop times,\r\n respectively, for the session. These values are the decimal\r\n representation of Network Time Protocol (NTP) time values in seconds\r\n since 1900 [13]. To convert these values to UNIX time, subtract\r\n decimal 2208988800.\r\n\r\nTo make the time base unique and absolute, the time zone (UTC) needs to\r\nbe specified.\r\nHence, the RFC should say:\r\n\r\n The first and second sub-fields give the start and stop times,\r\n respectively, for the session. These values are the decimal\r\n representation of Network Time Protocol (NTP) time values in seconds\r\n| since 1900, UTC [13]. To convert these values to UNIX time, subtract\r\n decimal 2208988800.\r\n\r\n\r\n(8) typo (missing article)\r\n\r\nThe second text paragraph of section 5.10, on page 18, says:\r\n\r\n To make description more compact, times may also be given in units of\r\n days, hours, or minutes. [...]\r\n\r\nIt should say:\r\n\r\n| To make the description more compact, times may also be given in\r\n units of days, hours, or minutes. [...]\r\n\r\n\r\n(9) legacy term not replaced\r\n\r\nSince the advent of SIP and the Offer/Answer Model for SDP, it is\r\nno more appropriate, in a general context, to name a\r\n'session description' just a 'session announcement'.\r\n\r\nThe final paragraph of Section 5.11, on page 19, says:\r\n\r\n If a session is likely to last several years, it is expected that the\r\n session announcement will be modified periodically rather than\r\n transmit several years' worth of adjustments in one session\r\n announcement.\r\n\r\nIt should say therefore:\r\n\r\n If a session is likely to last several years, it is expected that the\r\n| session description will be modified periodically rather than\r\n| transmitting several years' worth of adjustments in one session\r\n| description.\r\n\r\n\r\n(10) clarification of 'charset' related terminology, plus typos\r\n\r\nSection 5.13 makes use of legacy terminology related to character\r\nsets and \"charsets\". It should use the stable, IESG policy based\r\nIETF terminology.\r\n\r\na)\r\nHence, the first paragraph on page 22:\r\n\r\n Attribute values are octet strings, and MAY use any octet value\r\n except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute\r\n values are to be interpreted as in ISO-10646 character set with UTF-8\r\n encoding. Unlike other text fields, attribute values are NOT\r\n normally affected by the \"charset\" attribute as this would make\r\n comparisons against known values problematic. However, when an\r\n attribute is defined, it can be defined to be charset dependent, in\r\n which case its value should be interpreted in the session charset\r\n rather than in ISO-10646.\r\n\r\nshould better say:\r\n\r\n Attribute values are octet strings, and MAY use any octet value\r\n except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute\r\n| values are to be interpreted as in the ISO-10646 character set with\r\n UTF-8 encoding. Unlike other text fields, attribute values are NOT\r\n normally affected by the \"charset\" attribute as this would make\r\n comparisons against known values problematic. However, when an\r\n attribute is defined, it can be defined to be charset dependent, in\r\n which case its value should be interpreted in the session charset\r\n rather than in UTF-8.\r\n\r\nNote: RFC 1815 has been deprecated; 'ISO-10646' is *not* considered a\r\n\"charset\", whereas 'UTF-8' is.\r\n\r\nb)\r\nIn Section 6, at the bottom of page 28, the RFC says:\r\n\r\n a=charset:\r\n\r\n This specifies the character set to be used to display the\r\n session name and information data. By default, the ISO-10646\r\n character set in UTF-8 encoding is used. If a more compact\r\n representation is required, other character sets may be used.\r\n For example, the ISO 8859-1 is specified with the following SDP\r\n attribute:\r\n\r\n a=charset:ISO-8859-1\r\n\r\nThe above headline should say:\r\n\r\n a=charset:\r\n\r\nor perhaps even better:\r\n\r\n a=charset:\r\n\r\nand the text body above should be changed to say:\r\n\r\n| This specifies the character set and encoding (\"charset\") to be\r\n| used for the session name and information data. By default,\r\n| the ISO-10646 character set in UTF-8 encoding (charset \"UTF-8\")\r\n is used. If a more compact representation is required, other\r\n| charsets may be used. For example, the ISO 8859-1 charset is\r\n specified with the following SDP attribute:\r\n [...]\r\n\r\nNote: The session description does not determine how parts of it\r\nare *displayed* (theres may be some transcoding used, and fonts\r\nor typefaces, etc., the charset must only be specified for SDP.)\r\n\r\nThe subsequent text on page 29,\r\n\r\n This is a session-level attribute and is not dependent on\r\n charset. The charset specified MUST be one of those registered\r\n with IANA, such as ISO-8859-1. The character set identifier is\r\n a US-ASCII string and MUST be compared against the IANA\r\n identifiers using a case-insensitive comparison. If the\r\n identifier is not recognised or not supported, all strings that\r\n are affected by it SHOULD be regarded as octet strings.\r\n\r\n Note that a character set specified MUST still prohibit the use\r\n of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets\r\n requiring the use of these characters MUST define a quoting\r\n mechanism that prevents these bytes from appearing within text\r\n fields.\r\n\r\nshould be changed to say (fixing typos as well):\r\n\r\n This is a session-level attribute and is not dependent on\r\n charset. The charset specified MUST be one of those registered\r\n| with IANA, such as ISO-8859-1. The charset identifier is a\r\n US-ASCII string and MUST be compared against the IANA\r\n identifiers using a case-insensitive comparison. If the\r\n identifier is not recognised or not supported, all strings that\r\n are affected by it SHOULD be regarded as octet strings.\r\n\r\n| Note that a charset specified MUST still prohibit the use of\r\n| bytes 0x00 (NUL), 0x0A (LF), and 0x0D (CR). Charsets requiring\r\n the use of these characters MUST define a quoting mechanism\r\n that prevents these bytes from appearing within text fields.\r\n\r\n\r\n(11) language related issues, plus typos\r\n\r\nThe RFC text on pp. 29/30 does not properly distinguish between, and\r\nmesses up, the specifics of session content (and its language[s]) and\r\nthe session *description* content (and the language[s] used therein).\r\n\r\nNote: I show more context than absolutely necessary to perform the\r\nrecommended changes, to make these better understandable.\r\n\r\na)\r\nOn mid-page 29, RFC 4566 says:\r\n\r\n a=sdplang:\r\n\r\n This can be a session-level attribute or a media-level\r\n attribute. As a session-level attribute, it specifies the\r\n language for the session description. As a media-level\r\n attribute, it specifies the language for any media-level SDP\r\n information field associated with that media. Multiple sdplang\r\n attributes can be provided either at session or media level if\r\n| multiple languages in the session description or media use\r\n| multiple languages, in which case the order of the attributes\r\n| indicates the order of importance of the various languages in\r\n| the session or media from most important to least important.\r\n\r\n(The last half-sentence is wrong and inappropriate.)\r\n\r\nIt should better say:\r\n\r\n a=sdplang:\r\n\r\n This can be a session-level attribute or a media-level\r\n attribute. As a session-level attribute, it specifies the\r\n language for the session description. As a media-level\r\n attribute, it specifies the language for any media-level SDP\r\n information field associated with that media. Multiple sdplang\r\n attributes can be provided either at session or media level if\r\n| multiple languages in the session or media description use\r\n| multiple languages.\r\n\r\nb)\r\nSkipping one paragraph, the next one says:\r\n\r\n The \"sdplang\" attribute value must be a single RFC 3066\r\n language tag in US-ASCII [9]. It is not dependent on the\r\n charset attribute. An \"sdplang\" attribute SHOULD be specified\r\n| when a session is of sufficient scope to cross geographic\r\n boundaries where the language of recipients cannot be assumed,\r\n| or where the session is in a different language from the\r\n locally assumed norm.\r\n\r\nIt should say:\r\n\r\n The \"sdplang\" attribute value must be a single RFC 3066\r\n language tag in US-ASCII [9]. It is not dependent on the\r\n charset attribute. An \"sdplang\" attribute SHOULD be specified\r\n| when a session description is of sufficient scope to cross\r\n geographic boundaries where the language of recipients cannot\r\n| be assumed, or where the session description is in a different\r\n language from the locally assumed norm.\r\n\r\nc)\r\nNext, in the explanations for:\r\n\r\n a=lang:\r\n\r\nextending from page 29 to page 30,\r\n\r\n This can be a session-level attribute or a media-level\r\n attribute. As a session-level attribute, it specifies the\r\n default language for the session being described. As a media-\r\n level attribute, it specifies the language for that media,\r\n <>\r\n overriding any session-level language specified. Multiple lang\r\n attributes can be provided either at session or media level if\r\n| the session description or media use multiple languages, in\r\n which case the order of the attributes indicates the order of\r\n importance of the various languages in the session or media\r\n from most important to least important.\r\n\r\nshould be corrected to say:\r\n\r\n This can be a session-level attribute or a media-level\r\n attribute. As a session-level attribute, it specifies the\r\n default language for the session being described. As a media-\r\n level attribute, it specifies the language for that media,\r\n <>\r\n overriding any session-level language specified. Multiple lang\r\n attributes can be provided either at session or media level if\r\n| the session or media use multiple languages, in which case the\r\n order of the attributes indicates the order of importance of\r\n| the various languages in the session or media, from most\r\n important to least important.\r\n\r\n\r\n\r\n\r\nNote: In the meantime (since the publication of RFC 4566), RFC 3066\r\nhas been superseded by RFC 4646 plus RFC 4647, now together denoted\r\nas BCP 47.\r\n\r\n\r\n(12) typo\r\n\r\nOn page 31, in the second paragraph of Section 7, RFC 4566 says:\r\n\r\n [...]. Many different transport protocols may be used to\r\n distribute session description, and the nature of the authentication\r\n will differ from transport to transport. [...]\r\n\r\nIt should say:\r\n\r\n [...]. Many different transport protocols may be used to\r\n| distribute session descriptions, and the nature of the authentication\r\n will differ from transport to transport. [...]\r\n\r\n\r\n(13) SDP Grammar issues (ABNF in Section 9, p. 39 ff.),\r\n\r\na)\r\nThe rule for 'repeat-interval' (page 41) could easily have\r\nre-used (incorporated) the 'integer' rule:\r\n\r\n repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]\r\n\r\nis equivalent to:\r\n\r\n repeat-interval = integer [fixed-len-time-unit]\r\n\r\nb)\r\nThe rule for FQDN, at the bottom of page 42, is wrong;\r\nFQDNs really should allow up to 255 characters!\r\n v\r\n| FQDN = 4*(alpha-numeric / \"-\" / \".\")\r\n ; fully qualified domain name as specified\r\n ; in RFC 1035 (and updates)\r\n\r\nBecause details are not gived (can be found at other places),\r\nthis rule should perhaps be only minimally corrected to say:\r\n\r\n| FQDN = *(alpha-numeric / \"-\" / \".\")\r\n ; fully qualified domain name as specified\r\n ; in RFC 1035 (and updates)\r\n\r\n\r\nAt a minimum, serious issues should be addressed,\r\ne.g. (2), (10), (11), and the ABNF mistake (13b).", "correct_text": "", "notes": "from pending\r\n\r\n--VERIFIER COMMENT--\r\nWhile you raise a number of valid minor issues, I see nothing which\r\nneeds urgent attention or correction. I'll keep a record of these\r\nissues, to be included if there is a revision to RFC 4566, but I see\r\nno need to submit an errata note to the RFC Editor.\r\n", "submit_date": "2006-11-09", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Colin Perkins", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "58", "doc-id": "RFC4557", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3", "orig_text": "The corresponding padata-value field [RFC4120] contains the DER [X60]\r\n encoding of the following ASN.1 type:", "correct_text": "The corresponding padata-value field [RFC4120] contains the DER [X690]\r\n encoding of the following ASN.1 type:\r\n", "notes": "", "submit_date": "2006-10-31", "submitter_name": "Tom Petch", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "59", "doc-id": "RFC4550", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "1.1", "orig_text": " In particular, examples assume that Lemonade\r\n Submit and IMAP servers support all Lemonade extensions described in\r\n this document, so they don't show how to deal with absence of an\r\n extension.", "correct_text": " In particular, examples assume that Lemonade\r\n Submit and IMAP servers support all Lemonade extensions described in\r\n this document, so they don't show how to deal with the absence of an\r\n extension.", "notes": "missing article", "submit_date": "2006-08-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "60", "doc-id": "RFC4545", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) typo in Abstract\r\n\r\nThe Abstract, on page 1 of RFC 4545, contains the sentence:\r\n\r\n [...]\r\n In particular, it defines objects for managing user identities and\r\n| the names, addresses, and credentials required manage access control,\r\n for use with various protocols. [...]\r\n\r\nThe text should say (filling in the missing 'to'):\r\n\r\n In particular, it defines objects for managing user identities and\r\n| the names, addresses, and credentials required to manage access\r\n control, for use with various protocols. [...]\r\n\r\n\r\n(2) typo in Section 5\r\n\r\nThe first paragraph of Section 5, on page 4 of RFC 4545, says:\r\n\r\n The User-based Security Model (USM) [RFC3414] also defines the\r\n concept of a user, defining authentication and privacy protocols and\r\n their credentials. The definition of USM includes the SNMP-USER-\r\n| BASED-SM-MIB module allows configuration of SNMPv3 user credentials\r\n to protect SNMPv3 messages. [...]\r\n\r\nThe text should say (filling in the missing 'that'):\r\n\r\n The User-based Security Model (USM) [RFC3414] also defines the\r\n concept of a user, defining authentication and privacy protocols and\r\n their credentials. The definition of USM includes the SNMP-USER-\r\n| BASED-SM-MIB module that allows configuration of SNMPv3 user\r\n credentials to protect SNMPv3 messages. [...]\r\n\r\n\r\n(3) clarification in Section 7\r\n\r\nThe first paragraph of Section 7, on page 5 of RFC 4545, says:\r\n\r\n| This MIB module structure is intended to allow the configuration of a\r\n list of user identities, each with a list of names, addresses,\r\n| credentials, and certificates that, when combined, will distinguish\r\n that identity.\r\n\r\nThe wording should be enhanced, and the reference to certificates\r\nshould be removed -- these apparently have been excluded from the\r\nMIB in the published version.\r\n\r\nTherefore, the text should perhaps better say:\r\n\r\n| This MIB module's structure is intended to allow the configuration of\r\n a list of user identities, each with a list of names, addresses, and\r\n| credentials that, when combined, will distinguish that identity.\r\n\r\n\r\n(4) improper DESCRIPTION text\r\n\r\nThe DESCRIPTION clause for the ipsAuthIdentAddrAttributesTable\r\nOBJECT-TYPE, on page 19, says:\r\n\r\n DESCRIPTION\r\n \"A list of address ranges that are allowed to serve\r\n as the endpoint addresses of a particular identity.\r\n An address range includes a starting and ending address\r\n| and an optional netmask, and an address type indicator,\r\n which can specify whether the address is IPv4, IPv6,\r\n FC-WWPN, or FC-WWNN.\"\r\n\r\nThis text improperly mentions the use of netmasks, which has been\r\nexplicitely excluded from the MIB module, as can be seen from the\r\nsubsequent IpsAuthIdentAddrAttributesEntry syntax, and as explained\r\nin the last paragraph of Section 7.5, on page 8 of the RFC.\r\n\r\nTherefore, this clause should say:\r\n\r\n DESCRIPTION\r\n \"A list of address ranges that are allowed to serve\r\n as the endpoint addresses of a particular identity.\r\n An address range includes a starting and ending address,\r\n| and an address type indicator, which can specify whether\r\n the address is IPv4, IPv6, FC-WWPN, or FC-WWNN.\"\r\n\r\n\r\n(5) redundant MIB objects -- serious danger of inconsistency\r\n\r\nConceptually, rows of the ipsAuthCredChap, ipsAuthCredSrp, and\r\nipsAuthCredKerberos tables are a variant record (union in \"C\")\r\ncontained in the corresponding rows of the ipsAuthCredential table.\r\nThe DESCRIPTION clauses make clear, that the 'life' of the former\r\ntable rows is directly coupled to the 'life' of the latter rows --\r\nfor example, the DESCRIPTION clause of the ipsAuthCredAuthMethod\r\nOBJECT-TYPE says:\r\n\r\n When a row is created in this table, a corresponding\r\n row must be created by the management station\r\n in a corresponding table specified by this value.\r\n\r\n When a row is deleted from this table, the corresponding\r\n row must be automatically deleted by the agent in\r\n the corresponding table specified by this value.\r\n\r\nIMHO, it is inconsistent to have the agent delete the row, but\r\nlet the management station create the row; the SETting of an\r\nipsAuthCredAuthMethod object should create the corresponding row.\r\nAccording to this explanantion and the identical indexing structure\r\nof the four tables, the agent thus is directed to maintain exactly\r\none of those variant rows, matching the current value of a given\r\nipsAuthCredAuthMethod instance.\r\n\r\nIn the published version of the IPS-AUTH-MIB module, the rows\r\nof the basic ipsAuthCredentialAttributesTable contains objects of\r\nRowStatus and StorageType syntax that are used to create/activate/\r\ndelete an ipsAuthCredentialAttributesEntry conceptual row, and to\r\nspecify the persistence behaviour of that row, respectively.\r\n\r\nTherefore, IMHO it makes no sense, and it entails the danger of\r\nfundamental semantic inconsistencies in the MIB module, to also\r\nmaintain objects of RowStatus and StorageType syntax in the\r\nvariant table rows.\r\nE.g.,\r\n- no `active` row can exist in the ipsAuthCredChapAttributesTable\r\n without a corresponding `active` row in the\r\n ipsAuthCredentialAttributesTable;\r\n- no ipsAuthCredChapAttributesEntry can be created by the manager,\r\n that MUST be done automatically by the agent when the\r\n ipsAuthCredAuthMethod instance is set to ipsAuthMethodChap;\r\n- the ipsAuthCredentialAttributesEntry should be set inactive,\r\n if desired, and not the ipsAuthCredChapAttributesEntry;\r\n- the StorageType of both entries MUST be exactly the same.\r\n\r\nTherefore, IMHO the objects\r\n o ipsAuthCredChapRowStatus,\r\n o ipsAuthCredChapStorageType,\r\n o ipsAuthCredSrpRowStatus,\r\n o ipsAuthCredSrpStorageType,\r\n o ipsAuthCredKerbRowStatus, and\r\n o ipsAuthCredKerbStorageType\r\nshould be deprecated as soon as possible, and its MAX-ACCESS\r\nchanged to read-only, with explanation added to the DESCRIPTION\r\nclauses that the values of these objects (if implemented), are\r\nagent maintained mirrors of the corresponding ipsAuthCredRowStatus\r\nand ipsAuthCredStorageType objects, respectively.\r\n\r\nAdditionally, it should be specified that a ipsAuthCredRowStatus\r\ninstance must not be set to `active` unless the proper credentials\r\nhave been set in the appropriate ipsAuthCred* \"detail\" row.\r\n\r\nIf it is decided that automatic row creation by the agent should\r\nnot be specified for backwards compatibility, at least the\r\nipsAuthCred*StorageType objects should be deprecated.\r\n\r\n\r\n(6) clarification in compliance statement\r\n\r\nThe DESCRIPTION clause of the ipsAuthComplianceV1 MODULE-COMPLIANCE\r\nsays:\r\n\r\n DESCRIPTION\r\n \"Initial version of compliance statement based on\r\n initial version of this MIB module.\r\n\r\n The Instance and Identity groups are mandatory;\r\n at least one of the other groups (Name, Address,\r\n| Credential, Certificate) is also mandatory for\r\n any given implementation.\"\r\n\r\nSimilar to item (3) above, the reference to 'Certificate' is\r\ninappropriate and should be deleted; additionally, the plural\r\nform of 'Credential' should be used.\r\n\r\nThus, this clause should say:\r\n\r\n DESCRIPTION\r\n \"Initial version of compliance statement based on\r\n initial version of this MIB module.\r\n\r\n The Instance and Identity groups are mandatory;\r\n at least one of the other groups (Name, Address,\r\n| Credentials) is also mandatory for any given\r\n implementation.\"\r\n\r\n\r\n(7) incomplete citations\r\n\r\nThe following References are incomplete according to RFC-Ed policy;\r\nthey should be amended by \"STD 62, \" just before the RFC number.\r\n\r\nIn Section 11, on page 40, the entry:\r\n\r\n [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, \"An\r\n Architecture for Describing Simple Network Management\r\n Protocol (SNMP) Management Frameworks\", RFC 3411, December\r\n 2002.\r\n\r\nshould say:\r\n\r\n [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, \"An\r\n Architecture for Describing Simple Network Management\r\n Protocol (SNMP) Management Frameworks\", STD 62, RFC 3411,\r\n December 2002.\r\n\r\nIn Section 12, on page 41, the entry:\r\n\r\n [RFC3414] Blumenthal, U. and B. Wijnen, \"User-based Security Model\r\n (USM) for version 3 of the Simple Network Management\r\n Protocol (SNMPv3)\", RFC 3414, December 2002.\r\n\r\nshould say:\r\n\r\n [RFC3414] Blumenthal, U. and B. Wijnen, \"User-based Security Model\r\n (USM) for version 3 of the Simple Network Management\r\n Protocol (SNMPv3)\", STD 62, RFC 3414, December 2002.", "correct_text": "", "notes": "I make use of change bars ('|' in column 1) to emphasize the\r\nlocation of textual issues and/or proposed textual changes.\r\nModified text is re-adjusted according to RFC formatting rules.\r\n\r\nThe items below are listed (and enumerated) in RFC text sequence.\r\nItem (5) apparently is a serious issue.\r\nAll other items are simple errata.\r\n\r\nfrom pending", "submit_date": "2006-06-29", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "431", "doc-id": "RFC2462", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "It currently says:\n", "orig_text": "2. TERMINOLOGY\n\n IP - Internet Protocol Version 6. The terms IPv4 and are used\n only in contexts where necessary to avoid ambiguity.", "correct_text": "2. TERMINOLOGY\n\n IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used\n only in contexts where necessary to avoid ambiguity.", "notes": "", "submit_date": "2004-08-10", "submitter_name": "Tim Shepard", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "43", "doc-id": "RFC4606", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(1) use of \"N\"\r\n\r\nIn Section 2.1 of RFC 4606, on page 6, the explanations for\r\nthe NCC field contain the Note:\r\n\r\n Note 2: When a transparent STS-N/STM-N signal is requested that is\r\n limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the\r\n signal type must be STS-N/STM-N, RCC with flag 1, NCC set to 1.\r\n\r\nSuch text (and similar) contains an unfortunate mess-up of two\r\ndistinct uses of \"N\", with different range of admissible values\r\nfor STS-N and STM-N.\r\nThis becomes particularly confusing in phrases like\r\n\"a single contiguously concatenated STS-Nc_SPE/VC-4-Nc\".\r\nI strongly recommend to avoid this overloaded use of \"N\"\r\nin a single context.\r\nUsing \"M\" for one of these two \"N\"s instead, i.e. talking\r\nabout \"STS-M/STM-N\", or talking about \"STS-<3*N>/STM-N\" or\r\neven \"STS-3N/STM-N\", would remove the ambiguity and add to\r\nthe clarity of the text.\r\n\r\n\r\n(3) continuation of (1)\r\n\r\nWithin section 3, the numbered rules on mid-page 13 would also\r\nbenefit from application of the arguments given in item (1) above:\r\n\r\n 1. S=1->N is the index of a particular STS-3/AUG-1 inside an\r\n STS-N/STM-N multiplex. S is only significant for SONET STS-N\r\n (N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 and\r\n STM-0.\r\n\r\nshould better be specified as:\r\n\r\n 1. S=1->N is the index of a particular STS-3/AUG-1 inside an\r\n| STS-3N/STM-N multiplex.\r\n| S is only significant for SONET STS-3N and SDH STM-N (N>0).\r\n S must be 0 and ignored for STS-1 and STM-0.\r\n\r\nand\r\n\r\n 2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an\r\n STS-3/AUG-1. U is only significant for SONET STS-N (N>1) and SDH\r\n STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0.\r\n\r\nshould better be specified as:\r\n\r\n 2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an\r\n STS-3/AUG-1.\r\n| U is only significant for SONET STS-3N and SDH STM-N (N>0).\r\n U must be 0 and ignored for STS-1 and STM-0.\r\n", "correct_text": "", "notes": "Erratum 43 has been duplicated to allow separate treatment of the different elements reported. This copy is used to address the rejected parts. The rest of the Erratum is now 2804.\n --VERIFIER NOTES-- \nPoints 1) and 3) are rejected. Although the repeated use of \"N\" could lead a reader to be confused, this is common usage amongst writers on TDM, and the readership within CCAMP has so far been unconfused. ", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2807", "doc-id": "RFC3677", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": "Category: Standards Track", "correct_text": "Category: Best Current Practice", "notes": "", "submit_date": "2011-05-13", "submitter_name": "Pete Resnick", "verifier_id": "", "verifier_name": "Olaf Kolkman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2808", "doc-id": "RFC2184", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " Content-Type: application/x-stuff\r\n title*1*=us-ascii'en'This%20is%20even%20more%20\r\n title*2*=%2A%2A%2Afun%2A%2A%2A%20\r\n title*3=\"isn't it!\"", "correct_text": " Content-Type: application/x-stuff\r\n title*0*=us-ascii'en'This%20is%20even%20more%20\r\n title*1*=%2A%2A%2Afun%2A%2A%2A%20\r\n title*2=\"isn't it!\"", "notes": "Verifier Note: Corrected in RFC 2231", "submit_date": "2001-04-14", "submitter_name": "Terje Braten", "verifier_id": "", "verifier_name": "Pete Resnick", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2809", "doc-id": "RFC6167", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": "Phillips, et al. Informational [Page 1]\r\n\f\r\nRFC 6167 jms\" URI Scheme April 2011", "correct_text": "Phillips, et al. Informational [Page 1]\r\n\f\r\nRFC 6167 \"jms\" URI Scheme April 2011", "notes": "This is a typing error, I believe - one inverted comma is missing here.", "submit_date": "2011-05-14", "submitter_name": "Mykyta Yevstifeyev", "verifier_id": "", "verifier_name": "Pete Resnick", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "44", "doc-id": "RFC4601", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": " Normative References say:", "orig_text": " [6] Holbrook, H. and B. Cain, \"Source-Specific Multicast for IP\",\r\n RFC 4507, August 2006.", "correct_text": " [6] Holbrook, H. and B. Cain, \"Source-Specific Multicast for IP\", RFC \r\n 4607, August 2006.", "notes": "Reference [6] in RFC 4601 is wrong, it says SSM for IP is\r\nRFC 4507 when it is RFC 4607.", "submit_date": "2006-11-07", "submitter_name": "Stephen Nadas", "verifier_id": "", "verifier_name": "David Ward", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "45", "doc-id": "RFC4596", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.5.1", "orig_text": "Y2 represents an audio/video phone that should only used\r\nwhen needed.", "correct_text": "Y2 represents an audio/video phone that should only be\r\nused when needed.", "notes": "word omission\r\n\r\nfrom pending", "submit_date": "2006-08-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "46", "doc-id": "RFC4592", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) [improper/misleading wording]\r\n\r\nIn the explanations to the Example in Section 2.2.1, RFC 4592\r\n(near the top of page 9) says:\r\n\r\n| The following responses would not be synthesized from any of the\r\n| wildcards in the zone:\r\n\r\nThis wording is improper/misleading.\r\nPerhaps, the RFC should better say:\r\n\r\n| The following queries would not cause RRs to be synthesized for the\r\n| answer from any of the wildcards in the zone:\r\n\r\n\r\n(2) [typo]\r\n\r\nThe last paragraph of Section 2.2.2, on page 10, says:\r\n\r\n As RFC 1034 also defines \"an authoritative name error indicating that\r\n| the name does not exist\" in section 4.3.1, so this apparently is not\r\n the intent of the original definition, justifying the need for an\r\n updated definition in the next section.\r\n\r\n\"As ..., so ...\" is redundant.\r\nThus, the RFC should say instead:\r\n\r\n As RFC 1034 also defines \"an authoritative name error indicating that\r\n| the name does not exist\" in section 4.3.1, this apparently is not the\r\n intent of the original definition, justifying the need for an updated\r\n definition in the next section.\r\n\r\n\r\n(3) [typo]\r\n\r\nIn Section 3.3.1, the 4th paragraph, on page 12, says:\r\n\r\n A source of synthesis does not guarantee having a RRSet to use for\r\n synthesis. The source of synthesis could be an empty non-terminal.\r\n\r\nIt should say:\r\n\r\n| A source of synthesis does not guarantee having an RRSet to use for\r\n synthesis. The source of synthesis could be an empty non-terminal.\r\n\r\n\r\n(4) [typo]\r\n\r\nIn Section 3.3.3, the last paragraph on page 13 says:\r\n\r\n This is essentially the same text in part 'a' covering the processing\r\n of CNAME RRSets.\r\n\r\nIt should say:\r\n\r\n| This is essentially the same text as in part 'a' covering the\r\n processing of CNAME RRSets.\r\n\r\n\r\n(5) [incomplete change in example?]\r\n\r\nIn Section 4.4, the second-to-last paragraph on page 16 says:\r\n\r\n The DNAME specification is not clear on whether DNAME records in a\r\n cache are used to rewrite queries. In some interpretations, the\r\n rewrite occurs; in others, it does not. Allowing for the occurrence\r\n of rewriting, queries for \"sub.a.b.example. A\" may be rewritten as\r\n| \"sub.foo.bar.tld. A\" by the former caching server and may be\r\n| rewritten as \"sub.a.foo.bar.tld. A\" by the latter. Coherency is\r\n lost, and an operational nightmare ensues.\r\n\r\n\"tld.\" does never appear in the preceding text; apparently it has\r\nbeen replaced there by \"example.net.\"\r\nTherefore, the RFC should say instead:\r\n\r\n The DNAME specification is not clear on whether DNAME records in a\r\n cache are used to rewrite queries. In some interpretations, the\r\n rewrite occurs; in others, it does not. Allowing for the occurrence\r\n of rewriting, queries for \"sub.a.b.example. A\" may be rewritten as\r\n| \"sub.foo.bar.example.net. A\" by the former caching server and may be\r\n| rewritten as \"sub.a.foo.bar.example.net. A\" by the latter. Coherency\r\n is lost, and an operational nightmare ensues.\r\n", "correct_text": "", "notes": "from pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "47", "doc-id": "RFC4590", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "3.5", "orig_text": "Digest-Nextnonce 106\r\nDigest-Response-Auth 107 ", "correct_text": "", "notes": "\n --VERIFIER NOTES-- \nitis unclear what is wrong ", "submit_date": "2006-09-21", "submitter_name": "Alexander Schrab", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "144", "doc-id": "RFC4283", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": " In addition, IANA has created a new namespace for the subtype field\r\n of the Mobile Node Identifier option. The currently allocated values\r\n are as follows:\r\n\r\n NAI (defined in [RFC4282]).", "correct_text": " In addition, IANA has created a new namespace for the subtype field\r\n of the Mobile Node Identifier option. The currently allocated values\r\n are as follows:\r\n\r\n 1 -- NAI (defined in [RFC4282]).", "notes": "", "submit_date": "2005-12-19", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "145", "doc-id": "RFC4280", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " Broadcast and Multicast Service Controller Domain Name List\r\n for DHCPv4", "correct_text": " Broadcast and Multicast Service Controller Domain Name List\r\n Option for DHCPv4", "notes": "\r\n", "submit_date": "2005-12-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "146", "doc-id": "RFC4277", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) Relationship to RFC 1773\r\n\r\nWhile studying RFC 4277, and re-reading its predecessor, RFC 1773,\r\nit became more and more unclear to me why RFC 1773 has not simply\r\nbeen declared being obsoleted by RFC 4277 - or perhaps being done\r\nso by RFC 4277 plus RFC 4276.\r\n\r\nAlmost all material contained in RFC 1773 has been expanded upon\r\nin RFC 4277; only a few historical noted have been dropped -\r\nwhich arguably are of no more interest from the point of view\r\nof current standardization and implementation efforts.\r\n\r\nHence, RFC 4277 apparently is a perfect replacement for RFC 1773,\r\nand it would have added to clarity about the status of the memos\r\nmaking this visible in the RFC index by means of a pair of\r\nrelated OBSOLETED BY and OBSOLETES notes.\r\n\r\n\r\n(2) Inconsistencies with References\r\n\r\nThere are a few issues with References in RFC 4277:\r\n\r\n(2a)\r\n\r\nRFC 1965 had been obsoleted by RFC 3065, as noted in the text,\r\nand consistently, the Ref. [RFC1965] has been placed into the\r\nInformative References (Section 22.2), whereas [RFC3065] has\r\nbeen recorded as a Normative Reference. That's pretty o.k.\r\n\r\nA similar relation exists between RFC 1966 and RFC 2796 (that\r\nhad obsoleted the former), and the text contains a similar,\r\nparallel treatment of this RFC pair as the pair noted above.\r\nNevertheless, the Ref. [RFC1966] has been placed in Section\r\n22.1, Normative References.\r\nThat seems to be inappropriate and inconsistent; [RFC1996]\r\nshould have been filed as an Informative Reference.\r\n\r\n(2b)\r\n\r\nThe first sentence of Section 3, on page 3, contains a citation to\r\n\"[BGP-MIB]\" that can be assumed from the context to mean RFC 4273,\r\nbut there's no such entry in Section 22 !\r\n\r\nConsistently with (2a) above, the Ref. [RFC1657] from Section 22.1\r\nshould better have been placed into Section 22.2, and instead of it,\r\na new entry [BGP-MIB] pointing to RFC 4273 inserted into the\r\nNormative References, Section 22.1.\r\n\r\n\r\nThe following text might be considered for inclusion in an RFC\r\nErrata Note for RFC 4277 to resolve isuues (2a) and (2b):\r\n\r\n-----\r\nRFC 4271, in Section 22.1, \"Normative References\", on page 17,\r\ncontains entries labeled '[RFC1966]' and '[RFC1657]' .\r\nThese entries should have been placed into Section 22.2,\r\n\"Informative References\", instead.\r\n\r\nAdditionally, another entry should be added to Section 22.1 :\r\n\r\n [BGP-MIB] Haas, J., Ed. and S. Hares, Ed., \"Definitions of Managed\r\n Objects for BGP-4\", RFC 4273, January 2006.\r\n-----\r\n\r\n\r\n(3) further errata (typos)\r\n\r\n(3a)\r\n\r\nThe example network topology diagram in Section 8, on mid-page 8,\r\n\r\n /---- transit B ----\\\r\n end-customer transit A----\r\n /---- transit C ----\\\r\n\r\nshould say:\r\n\r\n /---- transit B ----\\\r\n end-customer transit A----\r\n \\---- transit C ----/\r\n\r\nRationale: cf. RFC 1773 !\r\n\r\n(3b)\r\n\r\nConforming to standard IPsec terminology, the first sentence\r\nin Section 17.2 of RFC 4277 (on page 14),\r\n\r\n vvv\r\n BGP can run over IPsec, either in a tunnel or in transport mode,\r\n where the TCP portion of the IP packet is encrypted. [...]\r\n\r\nshould better say:\r\n vvvvvv\r\n| BGP can run over IPsec, either in tunnel mode or in transport mode,\r\n where the TCP portion of the IP packet is encrypted. [...]\r\n\r\nor even, omitting that first 'mode' entirely,\r\n\r\n| BGP can run over IPsec, either in tunnel or in transport mode, where\r\n the TCP portion of the IP packet is encrypted. [...]\r\n\r\n(3c)\r\n\r\nThe last sentence in Section 21 of RFC 4277, on page 16,\r\n\r\n Finally, we'd like to think the IDR WG for general and specific input\r\n that contributed to this document.\r\n\r\nshould say:\r\n v\r\n| Finally, we'd like to thank the IDR WG for general and specific input\r\n that contributed to this document.", "correct_text": "", "notes": "from pending", "submit_date": "2006-03-21", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "432", "doc-id": "RFC2459", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Appendix D.3: ", "orig_text": " 0587 03 81 81 47: . BIT STRING", "correct_text": " 0587 03 81 81 129: . BIT STRING\n", "notes": "", "submit_date": "2001-02-13", "submitter_name": "Yaron Sella", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "495", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "1. MUST This word, or the terms \"REQUIRED\" or \"SHALL\", mean that the\r\n definition is an absolute requirement of the specification.\r\n\r\n", "correct_text": "1. MUST This word, or the terms \"REQUIRED\" or \"SHALL\", means that the\r\n definition is an absolute requirement of the specification.\r\n", "notes": " \r\n", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "48", "doc-id": "RFC4588", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "8.1", "orig_text": " The following MIME subtype name and parameters are introduced in this\r\n document: \"rtx\", \"rtx-time\", and \"apt\".\r\n\r\n The binding used for the retransmission stream to the payload type\r\n number is indicated by an rtpmap attribute. The MIME subtype name\r\n used in the binding is \"rtx\".\r\n\r\n The \"apt\" (associated payload type) parameter MUST be used to map the\r\n retransmission payload type to the associated original stream payload\r\n type. If multiple original payload types are used, then multiple\r\n \"apt\" parameters MUST be included to map each original payload type\r\n to a different retransmission payload type.\r\n", "correct_text": " The following MIME subtype name and parameters are introduced in this\r\n document: \"rtx\", \"rtx-time\", and \"apt\".\r\n\r\n The binding used for the retransmission stream to the payload type\r\n number is indicated by an rtpmap attribute. The MIME subtype name\r\n used in the binding is \"rtx\". The MIME type of the retransmission\r\n stream MUST be the same as the MIME type of the original stream.\r\n\r\n The \"apt\" (associated payload type) parameter MUST be used to map the\r\n retransmission payload type to the associated original stream payload\r\n type. If multiple original payload types are used, then multiple\r\n \"apt\" parameters MUST be included to map each original payload type\r\n to a different retransmission payload type.", "notes": "This text only addresses the use of the media *sub*-type. Apparently,\r\nit is implied that the media *type* of the associated streams match,\r\nbut I could not find a statement to this end in the RFC.\r\n\r\n(In accordance with the language of RFC 4588, but contrary to BCP 13,\r\n RFC 4288, I have again used the traditional wording \"MIME type\" here\r\n instead of the currently recommended \"media type\".)\r\n\r\nfrom pending\r\n\r\n--VERIFIER COMMENT--\r\n\r\nThanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:\r\n\r\n\"We will be happy to archive these and migt consider them if we do a revision of the RFC. But an errata document would only make sense if there is something seriously hindering interoperability. I have not seen anything falling into this category (well, and there are implementations out there from the spec).\"", "submit_date": "2006-08-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Jose Rey", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "49", "doc-id": "RFC4587", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "\r\n(1) \"Updates\" relationship missing in RFC header & RFC index\r\n\r\nIn the Introduction (3rd paragraph on page 3) the RFC says:\r\n\r\n This document obsoletes RFC 2032 and updates the \"video/h261\" media\r\n type that was registered in RFC 3555.\r\n\r\nSimilar wording is in Section 6.1 (see below).\r\n\r\nTherefore, I expect that the RFC heading should have been amended\r\nby a \"Updates: 3555\" line, and that this relationship be visible in\r\nthe RFC index.\r\n\r\n\r\n(2) Misleading packetization specification\r\n\r\nOn page 4, in the first paragraph of Section 3.2, RFC 4587 says:\r\n\r\n [..]. The 512-bit frames are then interlaced with an audio stream\r\n and transmitted over px 64 kbps circuits according to specification\r\n H.221 [H221].\r\n ^^^^^^^^^^\r\n\r\nFor clarity, it should say:\r\n\r\n [..]. The 512-bit frames are then interlaced with an audio stream\r\n and transmitted over p x 64 kbps circuits according to specification\r\n H.221 [H221].\r\n ^^^^^^^^^^^\r\n\r\n(and/or replace the 'x' by an asterisk, '*' !)\r\n\r\n(2')\r\nThe same issue recurs on page 15, in the first item of Section 11.1,\r\nthe Normative Reference, [H261] .\r\n\r\n\r\n(3) Improper frequency specification\r\n\r\nAccording to the applicable ISO standards on Measures and Weights,\r\nthere is never a special sign to be written between the numeric value\r\nand the physical unit of any dimensioned physical value.\r\n(Preferrably, there should not even be any white space between.)\r\n\r\nTherefore, in Section 4.1 of RFC 4587, at the bottom of page 5,\r\nwhere the RFC says:\r\n\r\n [...]. For H.261 video streams, the RTP timestamp is based on\r\n| a 90-kHz clock. This clock rate is a multiple of the natural H.261\r\n frame rate (i.e., 30000/1001 or approximately 29.97 Hz). [...]\r\n\r\nit in fact should say:\r\n\r\n [...]. For H.261 video streams, the RTP timestamp is based on\r\n| a 90 kHz clock. This clock rate is a multiple of the natural H.261\r\n frame rate (i.e., 30000/1001 or approximately 29.97 Hz). [...]\r\n\r\n(Rigorous application of the above principles, taking 'bit' as a unit\r\nspecification, would also forbid data amount spellings like \"512-bit\"\r\nin item (2) above!)\r\n\r\n\r\n(4) misaligned 'ruler lines' above data format diagrams\r\n\r\nAccording to legacy and current RFC author guidelines, the ruler lines\r\nabove the two data format diagrams on page 6 (within Section 4.1):\r\n\r\n| 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\nshould be indented as follows:\r\n\r\n| 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n\r\n(5) improper wording (2 instances)\r\n\r\nNear the top of page 7, the explanations for the (I) and (V) bits\r\nboth contain the sentence:\r\n\r\n vvvvvvv\r\n [...]. The meaning of this bit should not be changed during the\r\n course of the RTP session.\r\n\r\nThis is abuse of language.\r\nThe *meaning* of the bit -- i.e., the bit *values* -- is given in the\r\ntext preceding the quoted sentence, and thus intrinsically cannot be\r\nchanged during the course of the RTP session.\r\nWhat in fact should not be changed during the RTP session is the\r\n*value* of these bits!\r\n\r\nTherefore, the RFC should say (in both places):\r\n\r\n vvvvv\r\n| [...]. The value of this bit should not be changed during the\r\n course of the RTP session.\r\n\r\n\r\n(6) typo\r\n\r\nIn Section 5, on page 9, the last sentence of the bullet (3) says:\r\n\r\n [...]. This mode is particularly\r\n efficient in point-to-point connection or when the number of\r\n decoders is low.\r\n\r\nIt should say:\r\n [...]. This mode is particularly\r\n| efficient in a point-to-point connection or when the number of\r\n decoders is low.\r\n\r\nor:\r\n [...]. This mode is particularly\r\n| efficient in point-to-point connections or when the number of\r\n decoders is low.\r\n\r\n\r\n(7) misleading section headlines\r\n\r\nIn the RFC text, Section\r\n\r\n 6. IANA Considerations\r\n\r\ncontains the following sub-sections:\r\n\r\n 6.1. Media Type Registrations\r\n\r\n 6.1.1. Registration of MIME Media Type video/H261\r\n\r\n 6.2. SDP Parameters\r\n\r\n 6.2.1. Usage with the SDP Offer Answer Model\r\n\r\nOnly Section 6.1[.1] contains information addressed to the IANA.\r\nTherefore, for clarity (and to avoid undue burden for the IANA),\r\nthe first two of the headlines quoted above should effectively be\r\nexchanged. And, there is only one (1) registration!\r\nHence, singular should be used.\r\n\r\nFurthermore, the text of Section 6.1 contains improper wording\r\nand has no trailing fullstop (dot) character:\r\n\r\n| This section describes the media types and names associated with this\r\n| payload format. The section updates the previous registered version\r\n in RFC 3555 [RFC3555]. This registration uses the template defined\r\n| in RFC 4288 [RFC4288]\r\n\r\nThus, the headline\r\n\r\n6. IANA Considerations\r\n\r\nshould be corrected to say, e.g.:\r\n\r\n6. Media Type video/H261\r\n\r\nand\r\n\r\n6.1. Media Type Registrations\r\n\r\n [... paragraph quoted above ... ]\r\n\r\nshould be replaced by:\r\n\r\n6.1 IANA Considerations\r\n\r\n| This section describes the media type and parameters associated with\r\n| this payload format. It updates the previous registered version in\r\n RFC 3555 [RFC3555]. This registration uses the template defined\r\n| in RFC 4288 [RFC4288].\r\n\r\n\r\n(8) typo\r\n\r\nThe last sentence (of the last bullet) of Section 6.2, on page 12,\r\nsays:\r\n [...]. These parameters are\r\n expressed as a MIME media type string, in the form of as a\r\n semicolon-separated list of parameters\r\n ^^^^\r\nIt should say:\r\n [...]. These parameters are\r\n| expressed as a MIME media type string, in the form of a\r\n semicolon-separated list of parameters\r\n\r\n\r\n(9) typo and misleading wording in Section 6.2.1\r\n\r\nThe first paragraph of Section 6.2.1, on page 12, says:\r\n\r\n When H.261 is offered over RTP using SDP in an Offer/Answer model\r\n [RFC3264] the following considerations are necessary.\r\n\r\nThis could easily be misunderstood as talking about an\r\n'SDP offer over RTP'.\r\nThe RFC should say instead (exchanging two pairs of words):\r\n\r\n When H.261 over RTP is offered using SDP in an Offer/Answer model\r\n [RFC3264] the following considerations are necessary.\r\n\r\nSubsequently, the paragraph with the headline \"Picture sizes and MPI\",\r\n\r\n Supported picture sizes and their corresponding minimum picture\r\n interval (MPI) information for H.261 can be combined. All picture\r\n sizes may be advertised to the other party, or only a subset of it.\r\n Using the recvonly or sendrev direction attribute, a terminal SHOULD\r\n announce those picture sizes (with their MPIs) that it is willing to\r\n receive. For example, CIF=2 means that receiver can receive a CIF\r\n picture and that the frame rate SHALL be less then 15 frames per\r\n second.\r\n\r\nShould be corrected and clarified to say:\r\n\r\n Supported picture sizes and their corresponding minimum picture\r\n interval (MPI) information for H.261 can be combined. All picture\r\n sizes may be advertised to the other party, or only a subset of it.\r\n| Using the recvonly or sendrec direction attribute, a terminal SHOULD\r\n announce those picture sizes (with their MPIs) that it is willing to\r\n| receive. For example, CIF=2 means that the SDP sender can receive a\r\n CIF picture and that the frame rate SHALL be less then 15 frames per\r\n second.\r\n\r\n(There is no 'sendrev' direction attribute, and it is important to\r\nexplicitely differentiate between senders and receivers of SDP and\r\nmedia, respectively!)\r\n\r\nFinally, the second paragraph on page 13,\r\n\r\n An example of media representation in SDP is as follows CIF at 15\r\n frames per second, QCIF at 30 frames per second and annex D\r\n\r\nshould better say:\r\n\r\n| An example of media representation in SDP is as follows:\r\n CIF at 15 frames per second, QCIF at 30 frames per second and annex D\r\n\r\nor, perhaps even better:\r\n\r\n| An example of media representation in SDP, for CIF at 15 frames per\r\n| second, QCIF at 30 frames per second and annex D, is as follows:\r\n", "correct_text": "", "notes": "from pending", "submit_date": "2006-10-31", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "50", "doc-id": "RFC4586", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " We can see that in configurations where both agents use the new\r\n timing rules each of them uses, at most, about 2.5% of the session\r\n bandwidth for RTP, which sums up to 5% of the session bandwidth for\r\n both.", "correct_text": " We can see that in configurations where both agents use the new\r\n timing rules each of them uses, at most, about 2.5% of the session\r\n bandwidth for RTCP, which sums up to 5% of the session bandwidth for\r\n both. ", "notes": "RTP -> RTCP\r\n\r\nfrom pending", "submit_date": "2006-08-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "51", "doc-id": "RFC4585", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "Errors (11)-(19) of 19", "orig_text": "(11) [formatting issue]\r\n\r\nIn Section 6, the text around the page break from page 31 to page 32\r\nis not formatted properly.\r\nThe RFC says:\r\n\r\n [...]\r\n audio and DTMF) or when codec changes occur, the payload type\r\n information may need to be conveyed explicitly as part of the FB\r\n message. This applies to all\r\n << page break >>\r\n payload-specific as well as application layer FB messages. It is\r\n up to the specification of an FB message to define how payload\r\n type information is transmitted.\r\n\r\nIt should say:\r\n\r\n [...]\r\n audio and DTMF) or when codec changes occur, the payload type\r\n information may need to be conveyed explicitly as part of the FB\r\n message. This applies to all payload-specific as well as\r\n << page break >>\r\n application layer FB messages. It is up to the specification of\r\n an FB message to define how payload type information is\r\n transmitted.\r\n\r\n\r\n(12) [inconsistent text]\r\n\r\nStill in Section 6, the second paragraph on page 32 (immediately\r\nfollowing the text quotation in item (11) above) says:\r\n\r\n vvv\r\n| This document defines two transport layer and three (video) payload-\r\n specific FB messages as well as a single container for application\r\n layer FB messages. Additional transport layer and payload-specific\r\n FB messages MAY be defined in other documents and MUST be registered\r\n through IANA (see Section 9, \"IANA Considerations\").\r\n\r\nIt should say:\r\n vvv\r\n| This document defines one transport layer and three (video) payload-\r\n specific FB messages as well as a single container for application\r\n layer FB messages. Additional transport layer and payload-specific\r\n FB messages MAY be defined in other documents and MUST be registered\r\n through IANA (see Section 9, \"IANA Considerations\").\r\n\r\nRationale:\r\nCf. the third paragraph of Section 6, on page 31, and\r\nthe subsequent pages, in particular page 34, where the\r\nsecond paragraph of Section 6.2 says:\r\n\r\n| A single general purpose transport layer FB message is defined in\r\n this document: Generic NACK. It is identified by means of the FMT\r\n parameter as follows:\r\n\r\n [...]\r\n\r\n(And so it does, per Section 6.2.1.)\r\n\r\n\r\n(13) [incomplete specification?]\r\n\r\nWithin Section 6.1, the last paragraph on page 33 says:\r\n\r\n Each RTCP feedback packet MUST contain at least one FB message in the\r\n FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or\r\n not multiple FB messages MAY be compressed into a single FCI field.\r\n| If this is the case, they MUST be of the same type, i.e., same FMT.\r\n| If multiple types of feedback messages, i.e., several FMTs, need to\r\n be conveyed, then several RTCP FB messages MUST be generated and\r\n SHOULD be concatenated in the same compound RTCP packet.\r\n\r\nI strongly suspect -- and this is supported by the examples in the\r\nRFC -- that feedback packets to be combined MUST also have the same\r\npayload type (PT), not only agree in their FMT values.\r\nOtherwise, there would be no way to carry the different PT values\r\nin the FB message according to the format specified in Figure 3.\r\n\r\nTherefore, the RFC should say:\r\n\r\n Each RTCP feedback packet MUST contain at least one FB message in the\r\n FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or\r\n not multiple FB messages MAY be compressed into a single FCI field.\r\n| If this is the case, they MUST be of the same type, i.e., same PT and\r\n| the same FMT. If multiple types of feedback messages, i.e., several\r\n| PTs and/or several FMTs, need to be conveyed, then several RTCP FB\r\n messages MUST be generated and SHOULD be concatenated in the same\r\n compound RTCP packet.\r\n\r\n(Authors, please supply alternative wording, if you desire.)\r\n\r\nNote:\r\nPerhaps, this issue arised because of the slightly differing\r\nsemantics implied for the various usages of the term \"FB message\"\r\nin Section 6.1 -- (a) the whole RTCP FB message, and (b) a semantic\r\nentity carried in the FCI field of that RTCP message.\r\nFuture updates to the RFC might try further clarifications of the\r\ntext to avoid this subtle sematic overloading.\r\n\r\n\r\n(14) [missing article]\r\n\r\nThe last paragraph of Section 6.3, at the bottom of page 35, says:\r\n\r\n The following subsections define the FCI formats for the payload-\r\n| specific FB messages, Section 6.4 defines FCI format for the\r\n application layer FB message.\r\n\r\nIt should say:\r\n\r\n The following subsections define the FCI formats for the payload-\r\n| specific FB messages, Section 6.4 defines the FCI format for the\r\n application layer FB message.\r\n\r\n\r\n(15) [extraneous words]\r\n\r\nThe second paragraph of Section 6.3.1.1, on page 36, says:\r\n\r\n Other RTP payload specifications such as RFC 2032 [6] already define\r\n| a feedback mechanism for some for certain codecs. An application\r\n supporting both schemes MUST use the feedback mechanism defined in\r\n this specification when sending feedback. For backward compatibility\r\n reasons, such an application SHOULD also be capable to receive and\r\n react to the feedback scheme defined in the respective RTP payload\r\n format, if this is required by that payload format.\r\n\r\nIt should say:\r\n\r\n Other RTP payload specifications such as RFC 2032 [6] already define\r\n| a feedback mechanism for certain codecs. An application supporting\r\n both schemes MUST use the feedback mechanism defined in this\r\n specification when sending feedback. For backward compatibility\r\n reasons, such an application SHOULD also be capable to receive and\r\n react to the feedback scheme defined in the respective RTP payload\r\n format, if this is required by that payload format.\r\n\r\n\r\n(16) [misleading wording]\r\n\r\nThe first paragraph of Section 6.3.2.2, on page 37, says:\r\n\r\n vvvvv\r\n| The Slice Loss Indication uses one additional FCI field, the content\r\n of which is depicted in Figure 6. The length of the FB message MUST\r\n be set to 2+n, with n being the number of SLIs contained in the FCI\r\n field.\r\n\r\nTo avoid the semantic overloading of the word \"field\", it should\r\nperhaps better say:\r\n vvvv\r\n| The Slice Loss Indication uses one additional FCI word, the content\r\n of which is depicted in Figure 6. The length of the FB message MUST\r\n be set to 2+n, with n being the number of SLIs contained in the FCI\r\n field.\r\n\r\n\r\n(17) [typo]\r\n\r\nThe first paragraph of Section 6.3.3.1, on page 39, says:\r\n\r\n v\r\n [...]. As this reference picture is\r\n| temporally further away then usual, the resulting predictively coded\r\n picture will use more bits.\r\n\r\nIt should say:\r\n v\r\n [...]. As this reference picture is\r\n| temporally further away than usual, the resulting predictively coded\r\n picture will use more bits.\r\n\r\n\r\n(18) [inappropriate wording]\r\n\r\nThe first paragraph of Section 8, on page 42, says:\r\n\r\n RTP packets transporting information with the proposed payload format\r\n are subject to the security considerations discussed in the RTP\r\n specification [1] and in the RTP/AVP profile specification [2]. This\r\n profile does not specify any additional security services.\r\n\r\nThe wording of the first sentence is inappropriate for this RFC.\r\n(It perhaps has been copied unchanged from an RFC with an RTP Payload\r\nspecification.)\r\n\r\nRFC 4585 should say instead:\r\n\r\n| RTP packets transporting information as defined in various payload\r\n| formats supporting this profile are subject to the security\r\n considerations discussed in the RTP specification [1] and in the\r\n RTP/AVP profile specification [2]. This profile does not specify any\r\n additional security services.\r\n\r\n\r\n(19) [redundant Ref.]\r\n\r\nThe Normative Reference [7] (in Section 11.1, on page 48) and\r\nthe Informative Reference [20] (in Section 11.2, on page 49)\r\nboth point to RFC 3448.\r\n([7] and [20] are referred to once each in the RFC text.)\r\n\r\nThis is unusual and unexpected. Only one pointer to RFC 3448\r\nshould have been specified. Authors, please check.\r\n", "correct_text": "", "notes": "from pending\r\n\r\n--VERIFIER COMMENT--\r\nThanks for the review. I have only quickly skimmed your comments\r\nand there does not seem to be anything serious.\r\n\r\nWe will be happy to archive these and migt consider them if\r\nwe do a revision of the RFC. But an errata document would\r\nonly make sense if there is something seriously hindering\r\ninteroperability. I have not seen anything falling into this\r\ncategory (well, and there are implementations out there from\r\nthe spec).\r\n", "submit_date": "2006-08-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Joerg Ott", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "111", "doc-id": "RFC4366", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(1) imprecise syntax description for `ciphersuites`\r\n\r\nThis is an issue inherited from RFC 2246, RFC 3546, and RFC 4346;\r\nI already have reported this issue against RFC 4346 (and RFC 4347\r\nas well).\r\n\r\nSection 7.4.1.2 of RFC 4346, on page 37 of RFC 4346 defines the syntax:\r\n\r\n uint8 CipherSuite[2]; /* Cryptographic suite selector */\r\n\r\nAccording to the specifications given in Section 4.3 of RFC 4346,\r\nvectors of type CipherSuite strictly must have byte lengths being\r\na multiple of 2.\r\nThis also means that the upper bound for a varaiable-length array\r\nof type CipherSuite should always be a multiple of 2.\r\n\r\nHence, the declaration in Section 2.1 of RFC 4366 (on page 5),\r\nan extended version of the basic declaration in Section 7.4.1.2\r\nof RFC 4346 (on top of page 38), stating\r\n\r\n struct {\r\n ProtocolVersion client_version;\r\n Random random;\r\n SessionID session_id;\r\n CipherSuite cipher_suites<2..2^16-1>;\r\n CompressionMethod compression_methods<1..2^8-1>;\r\n Extension client_hello_extension_list<0..2^16-1>;\r\n } ClientHello;\r\n\r\nshould better say:\r\n\r\n struct {\r\n ProtocolVersion client_version;\r\n Random random;\r\n SessionID session_id;\r\n| CipherSuite cipher_suites<2..2^16-2>;\r\n CompressionMethod compression_methods<1..2^8-1>;\r\n Extension client_hello_extension_list<0..2^16-1>;\r\n } ClientHello;\r\n\r\n\r\n(2) incomplete semantics specified for \"server_name\" extension\r\n\r\nSection 3.1 of RFC 4366, on page 9, defines the \"server_name\"\r\nextension as containing a *list* of `ServerName` structures.\r\n\r\nOn page 10, the same section says:\r\n\r\n It is RECOMMENDED that clients include an extension of type\r\n \"server_name\" in the client hello whenever they locate a server by a\r\n supported name type.\r\n\r\n A server that receives a client hello containing the \"server_name\"\r\n extension MAY use the information contained in the extension to guide\r\n its selection of an appropriate certificate to return to the client,\r\n and/or other aspects of security policy. In this event, the server\r\n SHALL include an extension of type \"server_name\" in the (extended)\r\n server hello. The \"extension_data\" field of this extension SHALL be\r\n empty.\r\n\r\n If the server understood the client hello extension but does not\r\n| recognize the server name, it SHOULD send an \"unrecognized_name\"\r\n ^^^\r\n alert (which MAY be fatal).\r\n\r\nand on page 19, Section 4 defines the error alert,\r\n\r\n - \"unrecognized_name\": this alert is sent by servers that receive a\r\n| server_name extension request, but do not recognize the server\r\n name. This message MAY be fatal. ^^^\r\n\r\nAll these clauses apparently state the semantics for the \"server_name\"\r\nextension solely in the case where the data field of the extension in\r\nthe (extended) Client Hello contains a *single* `ServerName` structure.\r\n\r\nIMHO, if the client, as allowed by the syntax, indeed specifies\r\nmultiple names in the \"server_name\" extension -- a feature that\r\nseems to be useful in certain scenarios --, it needs to get feedback\r\nfrom the server as to which of the specified names has been used for\r\nthe purpose described in the second paragraph cited above.\r\nHence, the server should better be instructed by the specification\r\nto include the selected name in the \"server_name\" extension returned\r\nto the client in the (extended) Server Hello.\r\nFor backwards compatibility, the specification should perhaps\r\nprescribe to omit this feedback, reverting to the specification\r\ncited above) in the case that the Client Hello received contained\r\nonly a single server name.\r\n\r\nIn parallel, the semantics of the \"unrecognized_name\" alerts should\r\nbe amended to mean: all received names are unrecognized.\r\n\r\n\r\n(3) incomplete / outdated referencing text\r\n\r\nThe paragraph of Section 3.2 spanning from page 11 to page 12, says:\r\n\r\n [...]. For example, if the negotiated\r\n\r\n length is 2^9=512, then for currently defined cipher suites (those\r\n defined in [TLS], [KERB], and [AESSUITES]), and when null compression\r\n is used, the record layer output can be at most 793 bytes: 5 bytes of\r\n headers, 512 bytes of application data, 256 bytes of padding, and 20\r\n bytes of MAC. [...]\r\n\r\nThis apparently is not up to date. I propose to either substitute\r\n\"[TLSbis],\" for \"[TLS],\" in the text above -- thus referring only to\r\ncurrent specifications --, or even to substitute \"[TLS] and [TLSbis],\"\r\nfor \"[TLS],\" there -- thus honoring to the predecessor.\r\n\r\n\r\n(4) spurious blank line\r\n\r\nWithin Section 3.6, the 5th paragraph on page 18 is interrupted\r\nby a blank line in the middle of a sentence.\r\nPerhaps this is a formatting artifact inherited from the page break\r\nthat was at this place in the text in RFC 3546.\r\n\r\nThus, the text body:\r\n\r\n Servers return a certificate response along with their certificate by\r\n sending a \"CertificateStatus\" message immediately after the\r\n \"Certificate\" message (and before any \"ServerKeyExchange\" or\r\n \"CertificateRequest\" messages). If a server returns a\r\n|\r\n \"CertificateStatus\" message, then the server MUST have included an\r\n extension of type \"status_request\" with empty \"extension_data\" in the\r\n extended server hello.\r\n\r\nshould be joined to say:\r\n\r\n Servers return a certificate response along with their certificate by\r\n sending a \"CertificateStatus\" message immediately after the\r\n \"Certificate\" message (and before any \"ServerKeyExchange\" or\r\n \"CertificateRequest\" messages). If a server returns a\r\n \"CertificateStatus\" message, then the server MUST have included an\r\n extension of type \"status_request\" with empty \"extension_data\" in the\r\n extended server hello.\r\n\r\n\r\n(5) punctuation issue in Informative Reference\r\n\r\nThe following Informative Reference entry on page 28 contains\r\nsyntactically inconsistent punctuation:\r\n\r\n [MAILINGLIST] J. Mikkelsen, R. Eberhard, and J. Kistler, \"General\r\n ClientHello extension mechanism and virtual hosting,\"\r\n ietf-tls mailing list posting, August 14, 2000.\r\n\r\nshould say:\r\n\r\n [MAILINGLIST] J. Mikkelsen, R. Eberhard, and J. Kistler, \"General\r\n| ClientHello extension mechanism and virtual hosting\",\r\n ietf-tls mailing list posting, August 14, 2000.", "correct_text": "", "notes": "All excerpts from the RFC text are taken literally, keeping their\r\noriginal formatting, and modified text is formatted in conformance\r\nwith RFC guidelines again.\r\n\r\nI use change bars ('|' in column 1) and casual up/down pointing\r\ntags ('^^^' / 'vvv' marks in extra lines) to emphasize the location\r\nof textual issues and/or proposed textual enhancements/corrections.\r\n\r\nIssue (2) above certainly needs discussion; perhaps you know what\r\nonce was intended. The other issues seem to be straightforward.\r\n\r\nfrom pending", "submit_date": "2006-05-29", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "David Hopwood", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "112", "doc-id": "RFC4365", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": " If these are desired, they must be provided by mechanisms that\r\n are outside the scope of the VPN mechanisms. For instance, the\r\n users can use secure protocols on an end-to-end basis, e.g.,\r\n IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc.\r\n\r\n", "correct_text": "\r\n\r\n If these are desired, they must be provided by mechanisms that\r\n are outside the scope of the VPN mechanisms. For instance, the\r\n users can use secure protocols on an end-to-end basis, e.g.,\r\n| IPsec, Secure Shell (SSH), Transport Layer Security (TLS), etc.\r\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\n\r\n", "notes": "", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2938", "doc-id": "RFC6321", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.4.1.2", "orig_text": "These are an IC:latitude element and an IC:longitude\r\nelement, each of which contains float values.", "correct_text": " These are an IC:latitude element and an IC:longitude\r\n element, each of which contains a float value.", "notes": "The existing text erroneously suggests that multiple values could be contained by each element.", "submit_date": "2011-08-15", "submitter_name": "Hamish Lawson", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2464", "doc-id": "RFC1123", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "4.1.2.6", "orig_text": " IMPLEMENTATION:\r\n The format of the 227 reply to a PASV command is not\r\n well standardized. In particular, an FTP client cannot\r\n assume that the parentheses shown on page 40 of RFC-959\r\n will be present (and in fact, Figure 3 on page 43 omits\r\n them).", "correct_text": " IMPLEMENTATION:\r\n The format of the 227 reply to a PASV command is not\r\n well standardized. In particular, an FTP client cannot\r\n assume that the parentheses shown on page 40 of RFC-959\r\n will be present (and in fact, Figure 3 on page 45 omits\r\n them).", "notes": "In RFC 959, Figure 3 is actually on page 45, not page 43.\n --VERIFIER NOTES-- \n I see figure 3 at the top of page 45.", "submit_date": "2010-08-15", "submitter_name": "Anthony Bryan", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "274", "doc-id": "RFC3420", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Normative References, it says:", "orig_text": " [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,\n Peterson, J., Sparks, R., Handley, M. and E. Schooler, \"SIP:\n Session Initiation Protocol\", RFC 3265, June 2002.", "correct_text": " [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,\n Peterson, J., Sparks, R., Handley, M. and E. Schooler, \"SIP:\n Session Initiation Protocol\", RFC 3261, June 2002.", "notes": "", "submit_date": "2005-06-08", "submitter_name": "Ged Davies", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "275", "doc-id": "RFC3420", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "The \"short title\" in the page headings, is missing an 's'. \n\nIt currently says:\n", "orig_text": "Internet Media Type message/ipfrag ", "correct_text": "Internet Media Type message/sipfrag ", "notes": "\n", "submit_date": "2004-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "52", "doc-id": "RFC4584", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.6", "orig_text": " IPv6 Neighbor Discovery changes are also defined in\r\n .\r\n\r\n New 'Home Agent' flag in router advertisement: #define\r\n ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */\r\n\r\n New Router flag with prefix information of the home agent:\r\n #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */\r\n \r\n As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent\r\n MUST include at least one prefix option with the Router Address (R)\r\n bit set. Advanced Socket API [1] defines data structure for prefix\r\n option as follows:", "correct_text": " IPv6 Neighbor Discovery changes are also defined in\r\n .\r\n\r\n New 'Home Agent' flag in router advertisement:\r\n \r\n #define ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */\r\n\r\n New Router flag with prefix information of the home agent:\r\n \r\n #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */\r\n\r\n As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent\r\n MUST include at least one prefix option with the Router Address (R)\r\n bit set. The Advanced Socket API [1] defines a data structure for\r\n the prefix option as follows:\r\n", "notes": "separation of machine readable text and RFC text, and missing articles\r\n\r\nfrom pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Samita Chakrabarti", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "53", "doc-id": "RFC4577", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(2) [orphaned inter-section references]\r\n\r\nSection 4.2.4 of RFC 4577 contains three (3) distinct references\r\nto itself. This cannot have been intended.\r\n\r\nWithin Section 4.2.2, the last two paragraphs on page 11 say:\r\n\r\n vvvvv\r\n A Domain Identifier is an eight-byte quantity that is a valid BGP\r\n| Extended Communities attribute, as specified in Section 4.2.4. If a\r\n particular OSPF instance has a non-NULL Domain Identifier, when\r\n routes from that OSPF instance are distributed by BGP as VPN-IPv4\r\n routes, the routes MUST carry the Domain Identifier Extended\r\n Communities attribute that corresponds to the OSPF instance's Primary\r\n Domain Identifier. If the OSPF instance's Domain Identifier is NULL,\r\n the Domain Identifier Extended Communities attribute MAY be omitted\r\n when routes from that OSPF instance are distributed by BGP;\r\n alternatively, a value of the Domain Identifier Extended Communities\r\n| attribute that represents NULL (see Section 4.2.4) MAY be carried\r\n with the route.\r\n ^^^^^\r\n If the OSPF instances of an OSPF domain are given one or more non-\r\n NULL Domain Identifiers, this procedure allows us to determine\r\n whether a particular OSPF-originated VPN-IPv4 route belongs to the\r\n same domain as a given OSPF instance. We can then determine whether\r\n the route should be redistributed to that OSPF instance as an inter-\r\n area route or as an OSPF AS-external route. Details can be found in\r\n| Sections 4.2.4 and 4.2.8.1.\r\n ^^^^^\r\n\r\nI am not sure what really was intended to say. Perhaps, the\r\nsecond instance of \"4.2.4\" should be replaced by \"4.2.6\".\r\n\r\nPlease check and supply corrected text.\r\n\r\n", "correct_text": "", "notes": "The references to section 4.2.4 should be changed to 4.2.6", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3111", "doc-id": "RFC4447", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6.3", "orig_text": "a) The first paragraph of Section 6.3, on page 22, says:\r\n\r\n As mentioned above, the Group ID field of the PWid FEC element, or\r\n the PW Grouping ID TLV used with the Generalized ID FEC element, can\r\n be used to withdraw all PW labels associated with a particular PW\r\n group. [...]\r\n\r\nIt should say:\r\n\r\n As mentioned above, the Group ID field of the PWid FEC element, or\r\n| the PW Grouping ID TLV used with the Generalized PWid FEC element,\r\n can be used to withdraw all PW labels associated with a particular PW\r\n group. [...]\r\n\r\nb) The second paragraph of Section 6.3, on top of page 23, says:\r\n\r\n If the Generalized FEC element is used, the AGI, SAII, and TAII are\r\n not present, the PW information length field is set to 0, the PW\r\n Grouping ID TLV is included, the Interface Parameters TLV is not\r\n present, and the Label TLV is not present. For the purpose of this\r\n document, this is called the \"wild card withdraw procedure\", and all\r\n PEs implementing this design are REQUIRED to accept such withdrawn\r\n message but are not required to send it. Note that the PW Grouping\r\n ID TLV only applies to PWs using the Generalized ID FEC element,\r\n while the Group ID only applies to PWid FEC element.\r\n\r\nIt should say:\r\n\r\n| If the Generalized PWid FEC element is used, the AGI, SAII, and TAII\r\n are not present, the PW information length field is set to 0, the PW\r\n Grouping ID TLV is included, the Interface Parameters TLV is not\r\n present, and the Label TLV is not present. For the purpose of this\r\n document, this is called the \"wild card withdraw procedure\", and all\r\n PEs implementing this design are REQUIRED to accept such withdrawn\r\n message but are not required to send it. Note that the PW Grouping\r\n| ID TLV only applies to PWs using the Generalized PWid FEC element,\r\n while the Group ID only applies to PWid FEC element.", "correct_text": "", "notes": " --VERIFIER NOTES-- \r\nThe terminology in the RFC is correct. \r\nIt is the \"generalized PW FEC Element\" and not the \"generalized PWid FEC element\"", "submit_date": "2006-11-09", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3125", "doc-id": "RFC5905", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "A.5.1.1", "orig_text": " /*\r\n * Calculate offset, delay and dispersion, then pass to the\r\n * clock filter. Note carefully the implied processing. The\r\n * first-order difference is done directly in 64-bit arithmetic,\r\n * then the result is converted to floating double. All further\r\n * processing is in floating-double arithmetic with rounding\r\n * done by the hardware. This is necessary in order to avoid\r\n * overflow and preserve precision.\r\n *\r\n * The delay calculation is a special case. In cases where the\r\n * server and client clocks are running at different rates and\r\n * with very fast networks, the delay can appear negative. In\r\n * order to avoid violating the Principle of Least Astonishment,\r\n * the delay is clamped not less than the system precision.\r\n */\r\n if (p->pmode == M_BCST) {\r\n offset = LFP2D(r->xmt - r->dst);\r\n delay = BDELAY;\r\n disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *\r\n 2 * BDELAY;\r\n } else {\r\n offset = (LFP2D(r->rec - r->org) + LFP2D(r->dst -\r\n r->xmt)) / 2;\r\n delay = max(LFP2D(r->dst - r->org) - LFP2D(r->rec -\r\n r->xmt), LOG2D(s.precision));\r\n disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *\r\n LFP2D(r->dst - r->org);\r\n }\r\n clock_filter(p, offset, delay, disp);\r\n", "correct_text": " /*\r\n * Calculate offset, delay and dispersion, then pass to the\r\n * clock filter. Note carefully the implied processing. The\r\n * first-order difference is done directly in 64-bit arithmetic,\r\n * then the result is converted to floating double. All further\r\n * processing is in floating-double arithmetic with rounding\r\n * done by the hardware. This is necessary in order to avoid\r\n * overflow and preserve precision.\r\n *\r\n * The delay calculation is a special case. In cases where the\r\n * server and client clocks are running at different rates and\r\n * with very fast networks, the delay can appear negative. In\r\n * order to avoid violating the Principle of Least Astonishment,\r\n * the delay is clamped not less than the system precision.\r\n */\r\n if (p->pmode == M_BCST) {\r\n offset = LFP2D(r->xmt - r->dst);\r\n delay = BDELAY;\r\n disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *\r\n 2 * BDELAY;\r\n } else {\r\n offset = (LFP2D(r->rec - r->org) + LFP2D(r->xmt -\r\n r->dst)) / 2;\r\n delay = max(LFP2D(r->dst - r->org) - LFP2D(r->xmt -\r\n r->rec), LOG2D(s.precision));\r\n disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *\r\n LFP2D(r->dst - r->org);\r\n }\r\n clock_filter(p, offset, delay, disp);\r\n", "notes": "Calculations of 'offset' and 'delay' have terms that are incorrectly swapped. In the calculation of 'offset', term 'r->dst' should be 'r->xmt', and term 'r->xmt' should be 'r->dst'. In the calculation of 'delay', term 'r->rec' should be 'r->xmt', and term 'r->xmt' should be 'r->rec'.\r\n\r\nSee the text from section 8:\r\n\r\n \"In the figure, the first packet transmitted by A contains only the\r\n origin timestamp t1, which is then copied to T1. B receives the\r\n packet at t2 and copies t1 to T1 and the receive timestamp t2 to T2.\r\n At this time or some time later at t3, B sends a packet to A\r\n containing t1 and t2 and the transmit timestamp t3. All three\r\n timestamps are copied to the corresponding state variables. A\r\n receives the packet at t4 containing the three timestamps t1, t2, and\r\n t3 and the destination timestamp t4. These four timestamps are used\r\n to compute the offset and delay of B relative to A, as described\r\n below.\r\n\r\n...\r\n\r\n \"The four most recent timestamps, T1 through T4, are used to compute\r\n the offset of B relative to A\r\n\r\n theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]\r\n\r\n and the round-trip delay\r\n\r\n delta = T(ABA) = (T4-T1) - (T3-T2).\"\r\n\r\nNoting that, from the perspective of A at time t4:\r\n\r\nT1 = t1 = origin timestamp (r->org)\r\nT2 = t2 = receive timestamp (r->rec)\r\nT3 = t3 = transmit timestamp (r->xmt)\r\nT4 = t4 = destination timestamp (r->dst)\r\n\r\nAn alternative correction would be to change the '+' to a '-' in the calculation of 'offset', and change the '-' to a '+' in the calculation of 'delay'. However, this would deviate from the operators used in the formulas from section 8.", "submit_date": "2012-02-16", "submitter_name": "Richard Walters", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "54", "doc-id": "RFC4571", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1", "orig_text": " The Audio/Video Profile (AVP, [RFC3550]) for the Real-time Transport\r\n Protocol (RTP, [RFC3551]) does not define a method for framing RTP\r\n and RTP Control Protocol (RTCP) packets onto connection-oriented\r\n transport protocols (such as TCP). However, earlier versions of", "correct_text": " The Audio/Video Profile (AVP, [RFC3551]) for the Real-time Transport\r\n Protocol (RTP, [RFC3550]) does not define a method for framing RTP\r\n and RTP Control Protocol (RTCP) packets onto connection-oriented\r\n transport protocols (such as TCP). However, earlier versions of", "notes": "\r\nApparently, the RFC numbers have been permuted inadvertently.", "submit_date": "2006-08-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "276", "doc-id": "RFC3418", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the text, it says: ", "orig_text": " 6.1. Informative References", "correct_text": " 6.2. Informative References\n", "notes": "", "submit_date": "2003-08-22", "submitter_name": "Glenn M. Keeni", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "277", "doc-id": "RFC3415", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Section A.1: ", "orig_text": " (a) \"system\" (subtree 1.3.6.1.2.1.1) [RFC3918]\n (b) \"snmp\" (subtree 1.3.6.1.2.1.11) [RFC3918]", "correct_text": " (a) \"system\" (subtree 1.3.6.1.2.1.1) [RFC3418]\n (b) \"snmp\" (subtree 1.3.6.1.2.1.11) [RFC3418]\n", "notes": "", "submit_date": "2002-12-27", "submitter_name": "Guan Hai Bing", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "311", "doc-id": "RFC3271", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": " Internet is for everyone - but it won't be if it cannot keep up with\r\n the explosive demand for its services, so we must dedicate ourselves\r\n to continuing its technological evolution and development of the\r\n technical standards the lie at the heart of the Internet revolution.\r\n", "correct_text": " Internet is for everyone - but it won't be if it cannot keep up with\r\n the explosive demand for its services, so we must dedicate ourselves\r\n to continuing its technological evolution and development of the\r\n technical standards that lie at the heart of the Internet revolution.\r\n", "notes": "", "submit_date": "2002-08-01", "submitter_name": "vinton g. cerf\"", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "61", "doc-id": "RFC4544", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(9) common problem with indiscontinuity tagging\r\n\r\nThe Session Stats Table defines and admits High-Capacity (64-bit)\r\nand Low-Capacity (32-bit) octet counters.\r\nIf both types of counters are implemented, according to the\r\nDESCRIPTION clauses of all these counters,\r\n\r\n [...]\r\n If this counter has suffered a discontinuity, the time of the\r\n last discontinuity is indicated in iscsiSsnDiscontinuityTime.\"\r\n\r\nHence, iscsiSsnDiscontinuityTime must indicate discontinuities\r\nin the HC and the LC counters, i.e. it must be changed whenever\r\none of the LC counters wraps back to zero, making it almost\r\nuseless for efficient surveillance of discontinuities in all\r\nthe other counters covered by this object.\r\nPerhaps, as it has been done in a few other IETF MIBs in the past,\r\ninclusion of additional 32-bit counters yielding the high part\r\n(most significant 32 bits) of the HC counters for use with SNMPv1\r\nmanagement stations would have allowed to change the semantics of\r\niscsiSsnDiscontinuityTime to avoid too frequent changes.", "correct_text": "", "notes": "\n --VERIFIER NOTES-- \nItem (9) - the situation in which \"one of the LC counters wraps back to\r\nzero\" is a regular increment of a continuous counter, i.e., it\r\nis not a discontinuity. Thus, this item is unfounded.", "submit_date": "2006-07-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "62", "doc-id": "RFC4543", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7", "orig_text": "In ENCR_NULL_AUTH_AES_GMAC, the IV is not included in either the \r\nplaintext or the additional authenticated data.", "correct_text": "In AES-GCM-ESP, the IV is not included in either the plaintext or \r\nthe additional authenticated data.", "notes": "This error might confuse the reader because it makes the text \r\ncontradict Figure 4.", "submit_date": "2006-07-06", "submitter_name": "David McGrew", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "63", "doc-id": "RFC4541", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " Additionally, if a non-Querier switch spoofs any General Queries (as\r\n addressed in Section 2.1 above, for Spanning Tree topology changes),\r\n the switch should use the null IP source address (::) when sending\r\n said queries. When such proxy queries are received, they must not be\r\n included in the Querier election process.", "correct_text": " Additionally, if a non-Querier switch spoofs any General Queries (as\r\n addressed in Section 2.1 above, for Spanning Tree topology changes),\r\n the switch should use the unspecified IP source address (::) when\r\n sending said queries. When such proxy queries are received, they\r\n must not be included in the Querier election process.\r\n", "notes": "The term, \"null\" IP address is inappropriate, according to the current\r\nIPv6 Address Architecture document. RFC 4541 should use the proper\r\nterm, \"unspecified\" address (cf. Section 2.5.2 of RFC 4291).\r\n\r\nfrom pending", "submit_date": "2006-11-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Morten Jagd Christensen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "64", "doc-id": "RFC4534", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "There are three terminology issues\r\n\r\na)\r\nThe combination of the two roles of \"Group Controller\" and\r\n\"Key Server\" is usually abbreviated as \"GC/KS\" , and such\r\ndoes RFC 4534. Consistently, the full expansion should be\r\nspelled \"Group Controller / Key Server\" to match the \"/\"\r\npresent in the acronym and to avoid the mis-understandable\r\nunstructured word grouping, \"Group Controller Key Server\".\r\n\r\nThis affects Section 3.2, in the second line on page 7, and\r\nthe second line of Section B.1.1, on page 13.\r\n\r\nb)\r\nIMHO, the wording, \"[the] rekey\" is sluggish and should be\r\nreplaced by \"[the] rekeying\".\r\nThis affects the Section titles,\r\n\"3.3. Rekey Policy\", that better should be: \"3.3. Rekeying Policy\"\r\nas well as\r\n \"B.5. GSAKMPv1 Rekey Policy\" and all\r\n \"B.5.*. Rekey ___\" , and\r\n \"B.6. GSAKMPv1 Rekey Policy ASN.1 Module\"\r\n\r\nOther changes:\r\n \"rekey protocol\" --> \"rekeying protocol\" and\r\n \"rekey message\" --> \"rekeying message\" (Section 3, page 5),\r\n \"Rekey SA\" --> \"Rekeying SA\" and\r\n \"During Rekey,\" --> \"During Rekeying,\" (Section 3.3, page 7),\r\n \"Rekey SAs\" --> \"Rekeying SAs\" (Appendix B, page 13),\r\n \"Rekey Protocol\" --> \"Rekeying Protocol\" (2x) ,\r\n \"rekey policy\" --> \"rekeying policy\" (2x) ,\r\n \"rekey messages\" --> \"rekeying messages\" ,\r\n \"rekey event\" --> \"rekeying event\" (2x) ,\r\n \"rekey message\" --> \"rekeying message\" ,\r\n \"rekey interval\" --> \"rekeying interval\" ,\r\n \"rekey process\" --> \"rekeying process\" ,\r\n \"the rekey\" --> \"the rekeying\" ,\r\n \"rekey delivery\" --> \"rekeying delivery\" ,\r\n \"handle rekey.\" --> \"handle rekeying.\" , (all in B.5., on page 22),\r\n etc. ...\r\n \"", "correct_text": "", "notes": "from pending", "submit_date": "2006-11-09", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2373", "doc-id": "RFC4650", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "\r\n\r\nIn Section 1, the last indented paragraph on page 4 says:\r\n\r\n However, the Diffie-Hellman key agreement protocol is known for\r\n its subtle security strengths in that it is able to provide full\r\n perfect forward secrecy (PFS) and further have to both parties\r\n actively involved in session key generation. This special\r\n security property (despite the somewhat higher computational\r\n costs) makes Diffie-Hellman techniques attractive in practice.", "correct_text": "It should say:\r\n\r\n However, the Diffie-Hellman key agreement protocol is known for\r\n its subtle security strengths in that it is able to provide full\r\n| perfect forward secrecy (PFS) and further have both parties\r\n actively involved in session key generation. This special\r\n security property (despite the somewhat higher computational\r\n costs) makes Diffie-Hellman techniques attractive in practice.", "notes": "", "submit_date": "2006-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "127", "doc-id": "RFC4314", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1.1", "orig_text": " The client has specified the \"d\" right in the SETACL command above\r\n and it expands to \"et\" on the server:\r\n\r\n C: A002 getacl INBOX/Drafts\r\n S: * ACL INBOX Fred rwipslxcetda David lrswideta\r\n S: A002 OK Getacl complete", "correct_text": " The client has specified the \"d\" right in the SETACL command above\r\n and it expands to \"et\" on the server:\r\n\r\n C: A002 getacl INBOX/Drafts\r\n S: * ACL INBOX/Drafts Fred rwipslxcetda David lrswideta\r\n S: A002 OK Getacl complete\r\n", "notes": "", "submit_date": "2005-12-31", "submitter_name": "Arnaud Taddei", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2309", "doc-id": "RFC5903", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "10.2", "orig_text": " [Err9] RFC Errata, Errata ID 9, RFC 4753,\r\n .\r\n", "correct_text": " [Err9] RFC Errata, Errata ID 9, RFC 4753; see\r\n .\r\n", "notes": "Rationale:\r\nA less experienced reader will likely have difficulties locating\r\nthe Errata entry given only the RFC Editor home page URL.\r\nThe RFC 'info' URIs have been introduced by RFC 5741 to provide\r\nstable canonical URIs for all information related to a given RFC;\r\nthus, the proper stable URI should be provided in the reference entry.\n --VERIFIER NOTES-- \nThe reference entry for Errata ID 9 is similar to how errata were referenced in previous RFCs (5550 and 5724). The URL of the main RFC Editor page was used intentionally, rather than the URL of the specific Errata ID or the RFC's info page (as in Alfred's corrected text). ", "submit_date": "2010-06-22", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2393", "doc-id": "RFC4409", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7", "orig_text": "The list of SMTP extensions provided on page 10 of RFC 4409\r\nunfortunately is incomplete. As far as I can see, the following\r\nRFCs with SMTP extensions predate the publication of RFC 4409:\r\n\r\n o RFC 2645 -- ATRN\r\n o RFC 2852 -- DELIVERBY\r\n o RFC 3865 (+ RFC 4095) -- NO-SOLICITING\r\n o RFC 4141 -- CONPERM, CONNEG\r\n[ o RFC 4405 ]\r\n", "correct_text": "", "notes": "Quickly browsing these RFCs, I found that only RFC 4405 has\r\nfollowed the specification in Section 7 of RFC 2476 (literally\r\ncarried over to RFC 4409):\r\n\r\n Future SMTP extensions SHOULD explicitly specify if they are valid on\r\n the Submission port.\r\n\r\nand contains a definitive statement to this end.\r\nRFC 4405 therefore arguably might be excluded from the list.\r\n\r\nIt would have been useful to have a complete list, with the\r\nproper applicability keywords for the above SMTP extensions.\r\n", "submit_date": "2006-05-16", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2401", "doc-id": "RFC4226", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "A.1", "orig_text": " Let IntDiv(a,b) denote the integer division algorithm that takes\r\n| input integers a, b where a >= b >= 1 and returns integers (q,r)\r\n|\r\n the quotient and remainder, respectively, of the division of a by b.\r\n (Thus, a = bq + r and 0 <= r < b.)", "correct_text": " Let IntDiv(a,b) denote the integer division algorithm that takes\r\n| input integers a, b where b >= 1 and returns integers (q,r), the\r\n quotient and remainder, respectively, of the division of a by b.\r\n (Thus, a = bq + r and 0 <= r < b.)", "notes": "inappropriate restriction specified + formatting flaw.\r\n\r\nOn page 17, Appendix A.1:\r\nThe restriction \"a >= b\" is not necessary and in fact inappropriate; the additional blank line seems to be an artifact of the editing process. Thus, the above text should better read [as above].\r\n", "submit_date": "2006-01-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2413", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "3", "orig_text": "The last two text lines of Section 3, on mid-page 6, say:\r\n v\r\n| ROTL^n(x) = ROTR^(w-x)(x)\r\n\r\n ROTR^n(x) = ROTL^(w-n)(x)", "correct_text": "They should say:\r\n v\r\n| ROTL^n(x) = ROTR^(w-n)(x)\r\n\r\n ROTR^n(x) = ROTL^(w-n)(x)", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "65", "doc-id": "RFC4532", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": " Servers indicate their support for this extended operation by\r\n providing a whoamiOID object identifier as a value of the\r\n 'supportedExtension' attribute type in their root DSE. The server\r\n SHOULD advertise this extension only when the client is willing and\r\n ^^^^^^^^^^\r\n able to perform this operation. ", "correct_text": " Servers indicate their support for this extended operation by\r\n providing a whoamiOID object identifier as a value of the\r\n 'supportedExtension' attribute type in their root DSE. The server\r\n SHOULD advertise this extension only when it is willing\r\n ^^\r\n and able to perform this operation.\r\n", "notes": "As far as I can see, the last sentence there is misleading and\r\ndoes not match the operational scenario; and hence, it should be\r\nclarified. According to the recommendations given, the client\r\nwill not try the operation if the OID is not offered by the server,\r\nand hence the server cannot know whether the client is willing\r\nto send the whoami Request; and in this case, the *server* will\r\nperform the operation, i.e., send the whoami Response.", "submit_date": "2006-07-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "66", "doc-id": "RFC4529", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1", "orig_text": " The control may be attached to any update operation to support\r\n conditional addition, deletion, modification, and renaming of the\r\n target object. The asserted condition is evaluated as an integral\r\n part the operation.", "correct_text": " The control may be attached to any update operation to support\r\n conditional addition, deletion, modification, and renaming of the\r\n target object. The asserted condition is evaluated as an integral\r\n| part of the operation.\r\n ^^^^", "notes": "from pending", "submit_date": "2006-07-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "67", "doc-id": "RFC4526", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "4", "orig_text": " Subject: Request for LDAP Protocol Mechanism Registration Object\n Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters\n Person & email address to contact for further information:\n Kurt Zeilenga Usage: Feature Specification:\n RFC 4526 Author/Change Controller: IESG Comments: none", "correct_text": " Subject: Request for LDAP Protocol Mechanism Registration\r\n Object Identifier: 1.3.6.1.4.1.4203.1.5.3\r\n Description: True/False filters\r\n Person & email address to contact for further information:\r\n Kurt Zeilenga \r\n Usage: Feature\r\n Specification: RFC 4526\r\n Author/Change Controller: IESG\r\n Comments: none\r\n\r\n", "notes": "\n --VERIFIER NOTES-- \n Although the RFC text has unfortunate line breaks, the registration with the IANA is accurate at http://www.iana.org/assignments/ldap-parameters", "submit_date": "2006-07-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "147", "doc-id": "RFC4275", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7", "orig_text": " [RFC4274] Haas, J. and S. Hares, Eds., \"Definitions of Managed\r\n Objects for the Fourth Version of Border Gateway Protocol\r\n (BGP-4)\", RFC 4274, January 2006.", "correct_text": " [RFC4273] Haas, J. and S. Hares, Eds., \"Definitions of Managed\r\n Objects for BGP-4\", RFC 4273, January 2006.", "notes": "All references in the text to RFC 4274 ( '[RFC4274]' )\r\nshould be changed to RFC 4273 ( '[RFC4273]' ).", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2572", "doc-id": "RFC5810", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "global", "orig_text": "The text on KEYINFO-TLV examples could be a little confusing.\r\n\r\nThe grammar is:\r\nKEYINFO-TLV := KeyID FULLDATA-TLV\r\nwhere the FULLDATA-TLV carries the KEYDATA. \r\nHowever, the examples dont show the text as being carried in the\r\nFULLDATA-TLV instead they would show something along the lines of:\r\nKEYINFO-TLV = KeyID=1, KEY_DATA=100\r\n", "correct_text": "The best way to represent this is:\r\nKEYINFO-TLV, V= {1, FULLDATA-TLV V={100}}\r\n", "notes": "", "submit_date": "2010-10-16", "submitter_name": "Jamal Hadi Salim", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2573", "doc-id": "RFC5810", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7.2 and App D.", "orig_text": "Section 7.2\r\nKEY_ID (in two places)\r\n\r\n\r\nAppendix D\r\nKEYDATA", "correct_text": "Section 7.2\r\nKeyID (both times)\r\n\r\n\r\nAppendix D\r\nKEY_DATA\r\n", "notes": "There is some small inconsistency in spelling the terms\r\nKeyID and KeyData. Sometimes the text refers to KEY_ID and \r\nKEY_DATA and sometimes KeyID and KEYDATA.\r\n", "submit_date": "2010-10-16", "submitter_name": "Jamal Hadi Salim", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2877", "doc-id": "RFC5473", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "A.2", "orig_text": " o The Class of Service field: ClassOfServiceIPv4 in [RFC5102], with\r\n a type of 5 and a length of 1 octet.\r\n", "correct_text": " o The Class of Service field: ipClassOfService in [RFC5102], with\r\n a type of 5 and a length of 1 octet.\r\n", "notes": "s/ClassOfServiceIPv4/ipClassOfService/ per IANA IPFIX registry, #5.", "submit_date": "2011-08-01", "submitter_name": "Paul Aitken", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "68", "doc-id": "RFC4524", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) referential inconsistency\r\n\r\nThe second paragraph of Section 1, on page 3 of RFC 4524, says:\r\n\r\n In the years that followed, X.500 Directory Services have evolved to\r\n incorporate new capabilities and even new protocols. In particular,\r\n the Lightweight Directory Access Protocol (LDAP) [RFC4510] was\r\n introduced in the early 1990s [RFC1487], with Version 3 of LDAP\r\n introduced in the late 1990s [RFC2251] and subsequently revised in\r\n| 2005 [RFC4510].\r\n\r\nIt should say:\r\n\r\n In the years that followed, X.500 Directory Services have evolved to\r\n incorporate new capabilities and even new protocols. In particular,\r\n the Lightweight Directory Access Protocol (LDAP) [RFC4510] was\r\n introduced in the early 1990s [RFC1487], with Version 3 of LDAP\r\n introduced in the late 1990s [RFC2251] and subsequently revised in\r\n| 2006 [RFC4510].\r\n ^\r\n\r\n(Rationale: RFC 451x and RFC 452x have been published in June 2006.)\r\n\r\n\r\n(2) typos\r\n\r\n(2a) The third paragraph of Section 1, on page 3 of RFC 4524, says:\r\n\r\n| While much of the material in RFC 1274 has been superceded by\r\n subsequently published ITU-T Recommendations and IETF RFCs, [...]\r\n\r\nIt should say:\r\n v\r\n| While much of the material in RFC 1274 has been superseded by\r\n subsequently published ITU-T Recommendations and IETF RFCs, [...]\r\n\r\n(2b) The third paragraph of Section 1.1, on page 3, says:\r\n\r\n The description of the 'domain' object class provided in this\r\n| document supercedes that found in RFC 2247. That is, Section 3.4 of\r\n this document replaces Section 5.2 of [RFC2247].\r\n\r\nIt should say:\r\n\r\n The description of the 'domain' object class provided in this\r\n| document supersedes that found in RFC 2247. That is, Section 3.4 of\r\n this document replaces Section 5.2 of [RFC2247].\r\n\r\n\r\n(3) extraneous (duplicated) text\r\n\r\nWithin Section 3.1 of RFC 4524, the first line on page 14,\r\n\r\n 3.3. documentSeriesExample:\r\n\r\nshould say:\r\n\r\n Example:\r\n\r\n\r\n(4) incomplete information\r\n\r\nWithin Appendix A of RFC 4524, I miss a note describing the fate\r\nof the 'pilotOrganization' object class (RFC 1274, Section 8.3.13).\r\n\r\nKurt:\r\n For completeness, it would be nice if you could provide\r\n supplementary text (similar to, and perhaps to be inserted\r\n after, section A.3 of RFC 4524) detailing the intentions of\r\n the authors regarding that object class.", "correct_text": "", "notes": " RFC 451x and RFC 452x have been published in June 2006.\r\n\r\nfrom pending", "submit_date": "2006-07-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "69", "doc-id": "RFC4521", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) Section 2.5 (page 5) -- Ref. tags\r\n\r\nThe text,\r\n vvvvvvvv\r\n Numerous elements of LDAP are described using ASN.1 [X.680] and are\r\n| encoded using a particular subset [Protocol, Section 5.2] of the\r\n Basic Encoding Rules (BER) [X.690]. To allow reuse of\r\n parsers/generators used in implementing the LDAP \"core\" technical\r\n specification [RFC4510], it is RECOMMENDED that extension elements\r\n (e.g., extension specific contents of controlValue, requestValue,\r\n responseValue fields) described by ASN.1 and encoded using BER be\r\n| subjected to the restrictions of [Protocol, Section 5.2].\r\n ^^^^^^^^\r\nshould say:\r\n\r\n Numerous elements of LDAP are described using ASN.1 [X.680] and are\r\n| encoded using a particular subset [RFC4511, Section 5.1] of the\r\n Basic Encoding Rules (BER) [X.690]. To allow reuse of\r\n parsers/generators used in implementing the LDAP \"core\" technical\r\n specification [RFC4510], it is RECOMMENDED that extension elements\r\n (e.g., extension specific contents of controlValue, requestValue,\r\n responseValue fields) described by ASN.1 and encoded using BER be\r\n| subjected to the restrictions of [RFC4511, Section 5.1].\r\n\r\n[ Note: the tags *and* the section numbers need correction! ]\r\n\r\n\r\n(2) Section 3.1 (page 6), 3rd and 4th paragraph -- Ref. tags\r\n\r\nThe text:\r\n\r\n An existing operation MAY be extended to return IntermediateResponse\r\n| messages [Protocol, Section 4.13].\r\n ^^^^^^^^ vvvvvvvv\r\n Specifications of controls SHALL NOT attach additional semantics to\r\n| the criticality of controls beyond those defined in [Protocol,\r\n Section 4.1.11]. A specification MAY mandate the criticality take on\r\n a particular value (e.g., TRUE or FALSE), where appropriate.\r\n\r\nshould say:\r\n\r\n An existing operation MAY be extended to return IntermediateResponse\r\n| messages [RFC4511, Section 4.13].\r\n\r\n Specifications of controls SHALL NOT attach additional semantics to\r\n| the criticality of controls beyond those defined in [RFC4511, Section\r\n 4.1.11]. A specification MAY mandate the criticality take on a\r\n particular value (e.g., TRUE or FALSE), where appropriate.\r\n\r\n\r\n(3) Section 3.1.2 (page 7), 3rd paragraph -- typo\r\n\r\nThe text:\r\n\r\n It is RECOMMENDED that designers consider alternative mechanisms for\r\n providing the function. For example, an extended operation issued\r\n subsequent to the Start TLS operation (hence, protected by the\r\n security layers negotiated by the Start TLS operation) might be used\r\n| to provided the desired function.\r\n ^\r\nshould say:\r\n\r\n It is RECOMMENDED that designers consider alternative mechanisms for\r\n providing the function. For example, an extended operation issued\r\n subsequent to the Start TLS operation (hence, protected by the\r\n security layers negotiated by the Start TLS operation) might be used\r\n| to provide the desired function.\r\n\r\n\r\n(4) Section 3.1.4 (page 8), 2nd bullet -- typo\r\n\r\nThe text:\r\n vvvv\r\n| - consistency: The resulting DIT state must be conform to schema\r\n and other constraints.\r\n\r\nshould say:\r\n\r\n| - consistency: The resulting DIT state must conform to schema and\r\n other constraints.\r\n\r\n\r\n(5) Section 3.2 (page 8) -- Ref. tag\r\n\r\nThe text:\r\n vvvvvvvv\r\n| Extended Operations [Protocol, Section 4.12] are the RECOMMENDED\r\n mechanism for defining new operations. [...]\r\n\r\nshould say:\r\n\r\n| Extended Operations [RFC4511, Section 4.12] are the RECOMMENDED\r\n mechanism for defining new operations. [...]\r\n\r\n\r\n(6) Section 3.4 (page 9), 1st paragraph -- Ref. tag\r\n\r\nThe text:\r\n vvvvvvvv\r\n| Unsolicited notifications [Protocol, Section 4.4] offer a capability\r\n for the server to notify the client of events not associated with the\r\n operation currently being processed.\r\n\r\nshould say:\r\n\r\n| Unsolicited notifications [RFC4511, Section 4.4] offer a capability\r\n for the server to notify the client of events not associated with the\r\n operation currently being processed.\r\n\r\n\r\n(7) Section 4 (page 9) -- Ref. tags\r\n\r\nThe text:\r\n vvvvvvvv\r\n| LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1\r\n| definition [Protocol, Appendix B] to be made.\r\n ^^^^^^^^\r\nshould say:\r\n\r\n| LDAP allows limited extension [RFC4511, Section 4] of the LDAP ASN.1\r\n| definition [RFC4511, Appendix B] to be made.\r\n\r\n\r\n(8) Section 5 (page 10), 1st paragraph -- Ref. tag\r\n\r\nThe text:\r\n\r\n Extensions defining LDAP schema elements SHALL provide schema\r\n| definitions conforming with syntaxes defined in [Models, Section\r\n 4.1]. [...]\r\n ^^^^^^\r\nshould say:\r\n\r\n Extensions defining LDAP schema elements SHALL provide schema\r\n| definitions conforming with syntaxes defined in [RFC4512, Section\r\n 4.1]. [...]\r\n\r\n\r\n(9) Section 9.1 (page 13) -- duplicate entry\r\n\r\nThe entry at the bottom of page 13,\r\n\r\n [RFC4512] Zeilenga, K., \"Lightweight Directory Access Protocol\r\n (LDAP): Directory Information Models\", RFC 4512, June\r\n 2006.\r\n\r\nshould be deleted.\r\nThis entry is a duplicate, and it recurs on page 14, at the proper\r\nplace according to the collation order (by ascending RFC#).", "correct_text": "", "notes": "Most important issue:\r\nApparently, the update of the Reference tags within the text has\r\nbeen performed incompletely after the assignment of RFC numbers\r\nto those many LDAP I-Ds, leaving 'unsatisfied' tags in the text\r\n(not listed in the References Sections), wherever these tags give\r\ndetailed citations, specifying a section or an Appendix there.\r\n\r\nThe errata detail items below are listed in textual order.\r\nI use change bars and tag lines to emphasize the corrections\r\nproposed and/or the issues in the original text.\r\nChanged text is re-adjusted to conform to RFC formatting rules.\r\n\r\nfrom pending", "submit_date": "2006-06-22", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "70", "doc-id": "RFC4519", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nAppendix A says:", "orig_text": " 18. Removed Section 2.4 (Source). Replaced the source table with\r\n explicit references for each definition.", "correct_text": " 18. Removed Section 4 (Source). Replaced the source table with\r\n explicit references for each definition.", "notes": "", "submit_date": "2006-07-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "71", "doc-id": "RFC4516", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "Appendix A.2", "orig_text": " Changed the text indicate that RFC 2255 is replaced ...", "correct_text": " Changed the text to indicate that RFC 2255 is replaced ...", "notes": " ", "submit_date": "2006-06-23", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "72", "doc-id": "RFC4515", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4", "orig_text": " The first example shows use of the matching rule \"caseExactMatch.\"", "correct_text": " The first example shows use of the matching rule \"caseExactMatch\".", "notes": "Source: apps", "submit_date": "2006-06-23", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "73", "doc-id": "RFC4514", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4", "orig_text": " This example shows the method of escaping of a special characters\r\n appearing in a common name:", "correct_text": " This example shows the method of escaping of special characters\r\n appearing in a common name:", "notes": "Source: apps", "submit_date": "2006-07-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "74", "doc-id": "RFC4512", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(E1) text truncation (?)\r\n\r\nApparently, the text of the first paragraph of Section 3.2,\r\non page 18 of RFC 4512, has been truncated inadvertently.\r\nThe RFC text says:\r\n\r\n A subentry is a \"special sort of entry, known by the Directory, used\r\n to hold information associated with a subtree or subtree refinement\"\r\n| [X.501]. Subentries are used in Directory to hold for administrative\r\n| and operational purposes as defined in [X.501]. Their use in LDAP is\r\n detailed in [RFC3672].\r\n\r\nI suspect that it should in fact say:\r\n\r\n A subentry is a \"special sort of entry, known by the Directory, used\r\n to hold information associated with a subtree or subtree refinement\"\r\n| [X.501]. Subentries are used in the Directory to hold attributes for\r\n| administrative and operational purposes as defined in [X.501]. Their\r\n use in LDAP is detailed in [RFC3672].\r\n\r\n\r\n(E2) typo\r\n\r\nIn Section 4.1.7.1, near the bottom of page 30, the explanation,\r\n\r\n FORM is specifies the name form associated with this DIT structure\r\n rule;\r\n\r\nshould say:\r\n\r\n| FORM specifies the name form associated with this DIT structure\r\n rule;\r\n\r\n\r\n(E3) typo\r\n\r\nThe first paragraph of Section 5.1, on page 36, says:\r\n\r\n An LDAP server SHALL provide information about itself and other\r\n information that is specific to each server. This is represented as\r\n a group of attributes located in the root DSE, which is named with\r\n| the DN with zero RDNs (whose [RFC4514] representation is as the\r\n zero-length string).\r\n\r\nIt should say:\r\n\r\n An LDAP server SHALL provide information about itself and other\r\n information that is specific to each server. This is represented as\r\n a group of attributes located in the root DSE, which is named with\r\n| the DN with zero RDNs (whose [RFC4514] representation is the zero-\r\n length string).\r\n\r\n\r\n(E4) word omission\r\n\r\nThe second paragraph of Section A.2.1, on page 49, says:\r\n\r\n The syntax was changed to disallow semicolon (U+003B)\r\n characters in order to appear to be consistent its natural language\r\n specification \"descr is the syntactic representation of an object\r\n descriptor, which consists of letters and digits, starting with a\r\n letter\". In a related change, the statement \"an AttributeDescription\r\n can be used as the value in a NAME part of an\r\n AttributeTypeDescription\" was deleted. RFC 2252 provided no\r\n specification of the semantics of attribute options appearing in NAME\r\n fields.\r\n\r\nIt should say:\r\n\r\n The syntax was changed to disallow semicolon (U+003B)\r\n| characters in order to appear to be consistent with its natural\r\n language specification \"descr is the syntactic representation of an\r\n object descriptor, which consists of letters and digits, starting\r\n with a letter\".\r\n In a related change, the statement \"an AttributeDescription can be\r\n used as the value in a NAME part of an AttributeTypeDescription\" was\r\n deleted. RFC 2252 provided no specification of the semantics of\r\n attribute options appearing in NAME fields.\r\n\r\n\r\nAnd these are my side notes for future consideration.\r\nThere are a couple of missing articles in the RFC text.\r\nI have noted the following places:\r\n\r\n\r\n(N1)\r\n\r\nIn Section 4.1.1, on page 24, the explanation,\r\n\r\n where:\r\n is object identifier assigned to this object class;\r\n [...]\r\n\r\nshould better say:\r\n\r\n where:\r\n| is the object identifier assigned to this object\r\n class;\r\n [...]\r\n\r\n\r\n(N2)\r\n\r\nIn Section 4.1.2,\r\n\r\na) on page 25, the literally same correction as (N1) applies, and\r\n\r\nb) the explanation:\r\n\r\n SYNTAX identifies value syntax by object identifier and may suggest\r\n a minimum upper bound;\r\n\r\nshould better say:\r\n\r\n| SYNTAX identifies the value syntax by its object identifier and may\r\n suggest a minimum upper bound;\r\n\r\nc) Finally, on top of page 26, the paragraph,\r\n\r\n If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING\r\n fields, if not specified, take their value from the supertype.\r\n\r\nshould better say:\r\n\r\n| If the SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING\r\n fields, if not specified, take their value from the supertype.\r\n\r\n\r\n(N3)\r\n\r\nIn Section 4.1.3, on page 27, -- similarly to (N1) --\r\nthe explanation,\r\n\r\n where:\r\n is object identifier assigned to this matching rule;\r\n [...]\r\n\r\nshould better say:\r\n\r\n where:\r\n is the object identifier assigned to this matching\r\n rule;\r\n [...]\r\n\r\n\r\n(N4)\r\n\r\nIn Section 4.1.7.2, on page 31, -- again like in (N1) --\r\nthe explanation,\r\n\r\n where:\r\n is object identifier that identifies this name form;\r\n [...]\r\n\r\nshould better say:\r\n\r\n where:\r\n is the object identifier that identifies this name\r\n form;\r\n [...]\r\n\r\n\r\n(N5)\r\n\r\nThe final sentence of Section 4.2, i.e. the 3rd paragraph on page 33,\r\nsays:\r\n\r\n The following subsections provide attribute type definitions for each\r\n of schema definition attribute types.\r\n\r\nIt should say:\r\n\r\n The following subsections provide attribute type definitions for each\r\n| of the schema definition attribute types.", "correct_text": "", "notes": "Source: apps", "submit_date": "2006-07-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2282", "doc-id": "RFC4823", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.4.4", "orig_text": "Item 8 in Section 7.4.4, on page 27 says:\r\n\r\n 8. The \"failed\" disposition type MAY NOT be used for the situation\r\n in which there is some problem in processing the message other\r\n| than interpreting the request for an MDN. The \"processed\" or\r\n| other disposition type with appropriate disposition modifiers is\r\n to be used in such situations.\r\n", "correct_text": " 8. The \"failed\" disposition type MAY NOT be used for the situation\r\n in which there is some problem in processing the message other\r\n| than interpreting the request for an MDN. The \"processed\"\r\n| disposition type with appropriate disposition modifiers MUST be\r\n used in such situations.\r\n", "notes": "The ABNF given in Section 7.4.3, on page 25,\r\n\r\n AS3-disposition-type = \"processed\" / \"failed\"\r\n\r\nexplicitely excludes \"other\" disposition types.\r\n\r\n\r\nSource: apps", "submit_date": "2007-05-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "75", "doc-id": "RFC4511", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(2) Typo\r\n\r\nSection 2, on page 4, contains the paragraph:\r\n v\r\n| The term \"SASL layer\" refers to Simply Authentication and Security\r\n Layer (SASL) services used in providing security services, as well as\r\n associations established by these services.\r\n\r\nIt should say:\r\n v\r\n| The term \"SASL layer\" refers to Simple Authentication and Security\r\n Layer (SASL) services used in providing security services, as well as\r\n associations established by these services.\r\n\r\n\r\n(3) Misrepresented relationship between ISO 10646 and Unicode\r\n\r\nSection 4.1.2 unfortunately has not corrected a misconception\r\ninitially spelled out in RFC 2251.\r\n\r\nThe first paragraph of Section 4.1.2, on page 7, says:\r\n\r\n The LDAPString is a notational convenience to indicate that, although\r\n strings of LDAPString type encode as ASN.1 OCTET STRING types, the\r\n| [ISO10646] character set (a superset of [Unicode]) is used, encoded\r\n following the UTF-8 [RFC3629] algorithm. [...]\r\n\r\nThe (..) enclosed note on the relationship of ISO 10646 and Unicode\r\nis *not* appropriate, as far as I know:\r\n\r\nUnicode covers exactly the same character repertoire as ISO 10646,\r\nbut it *adds* a lot of *semantics* to ISO 10646.\r\nThe character repertoire synchronization between ISO 10646 and\r\nUnicode is said to hold since 1993, and it is promised for all\r\nfuture updates.\r\n(Details can be found in Section 1.4 and Appendix C of\r\nThe Unicode Standard (book and online version), verbatim\r\nidentical in the Unicode 3.0 and Unicode 4.0 versions.)\r\n\r\nIn particular, this congruence holds for Unicode 3.2.0\r\n(and the coordinated edition of ISO 10646) that has been\r\nmade the invariable base for the new LDAP specs.\r\n\r\nTherefore, the above sentence should perhaps better be\r\ncorrected to say:\r\n\r\n The LDAPString is a notational convenience to indicate that, although\r\n strings of LDAPString type encode as ASN.1 OCTET STRING types, the\r\n| [ISO10646] character set (as detailed in [Unicode]) is used, encoded\r\n following the UTF-8 [RFC3629] algorithm. [...]\r\n\r\n(or similar).\r\n\r\n\r\n(4) Typo (word omission)\r\n\r\nThe 3rd paragraph of Section 4.2.2, on page 18, says:\r\n\r\n If the client receives a BindResponse where the resultCode is set to\r\n protocolError, it is to assume that the server does not support this\r\n| version of LDAP. While the client may be able proceed with another\r\n version of this protocol (which may or may not require closing and\r\n re-establishing the transport connection), how to proceed with\r\n another version of this protocol is beyond the scope of this\r\n document. Clients that are unable or unwilling to proceed SHOULD\r\n terminate the LDAP session.\r\n\r\nIt should say:\r\n vvvv\r\n| [...]. While the client may be able to proceed with\r\n another version of this protocol (which may or may not require\r\n closing and re-establishing the transport connection), how to proceed\r\n with another version of this protocol is beyond the scope of this\r\n document. [...]\r\n\r\n\r\nItems (2)..(4) above might be considered for an Errata Note\r\nto be posted to the RFC Editor's \"RFC Errata\" web pages.\r\nI propose that you submit an Author's Errata Note, based on the\r\nmaterial presented above, and/or choosing alternate text for (3).", "correct_text": "", "notes": "In any case, these items should be noted for future reference,\r\nwhenever once another revision of these RFCs is to be produced,\r\ne.g., for advancement on the Standards Track.\r\n\r\n[note: (1) contained general comments and has been removed.]\r\n\r\nAuthor saving on file for possible revision.\r\n\r\nfrom pending", "submit_date": "2006-06-23", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Jim Sermersheim", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2584", "doc-id": "RFC5782", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "1", "orig_text": "Rand and Vixie created a \r\nDNS-based distribution scheme that quickly became more popular than \r\nthe original BGP distribution. ", "correct_text": "Eric Ziegast, who was a system administrator for Vixie Enterprises \r\nwhere the RBL was hosted, created a DNS-based distribution scheme \r\nthat quickly became more popular than the original BGP distribution.", "notes": "Vixie asked me to make this correction, to properly credit the inventor of DNSBLs.", "submit_date": "2010-10-26", "submitter_name": "John Levine", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2585", "doc-id": "RFC6036", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2.5", "orig_text": " 84% support or plan DNS Authentication, Authorization, Accounting,\r\n and Auditing (AAAA) queries over IPv6, and all but one of these\r\n include reverse DNS lookup for IPv6.", "correct_text": " 84% support or plan DNS AAAA queries over IPv6, and all but one of\r\n these include reverse DNS lookup for IPv6.\r\n", "notes": "AAAA is not an acronym in this context; it is an RR type.", "submit_date": "2010-10-27", "submitter_name": "Brian Carpenter", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "219", "doc-id": "RFC3877", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.3", "orig_text": "ituAlarmPerceivedSeverity critical (3)", "correct_text": "alarmModelState 3", "notes": "\nHowever,\n ituAlarmPerceivedSeverity critical (3)\nshould be mapped to\n alarmModelState 6\nTo match the mapping shown in Section 5.4:\n alarmModelState -> ituAlarmPerceivedSeverity\n 1 -> clear (1)\n 2 -> indeterminate (2)\n 3 -> warning (6)\n 4 -> minor (5)\n 5 -> major (4)\n 6 -> critical (3)\n\n", "submit_date": "2005-08-08", "submitter_name": "Andreas Politze", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "76", "doc-id": "RFC4506", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) Section 6.2, page 18 - typo (word omission)\r\n\r\nThe words in the 9th line of the text,\r\n\r\n [...] \"followed by one or hexadecimal digits\" [...]\r\n\r\nshould say:\r\n\r\n [...] \"followed by one or more hexadecimal digits\" [...]\r\n ^^^^^^\r\n\r\n(2) Section 8, 2nd paragraph (page 22) - typo\r\n\r\nThe RFC says:\r\n\r\n Care must be take to properly encode and decode data to avoid\r\n attacks. [...]\r\n\r\nit should say:\r\n vv\r\n Care must be taken to properly encode and decode data to avoid\r\n attacks. [...]\r\n\r\n\r\n(3) Subtle inconsistency between Section 6.1 and Section 6.2\r\n\r\nOn page 17, Section 6.1 states the Notational Convention:\r\n\r\n (2) Terminal symbols are strings of characters surrounded by\r\n double quotes.\r\n ^^^^^^\r\nNevertheless, throughout the new Section 6.2 (on page 18), all\r\nterminal symbols, e.g. the \"generalized digits\" -- the terminals\r\nto build octal, decimal, and hexadecimal constants, are specified\r\nas characters surrounded by *single* quotes.\r\n ^^^^^^\r\nAlthough this style perhaps was inspired by the `C` language,\r\nIMHO, its use is inconsistent in that context.", "correct_text": "", "notes": "from pending", "submit_date": "2006-05-24", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Martin Stiemerling", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "77", "doc-id": "RFC4502", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "(1) clarification\r\n\r\nThe RFC 4502 text in Section 2.2, under bullet 3), on page 5,\r\nsays:\r\n\r\n Bit Definition\r\n\r\n 6 For WAN media, this bit is set for packets\r\n coming from one direction and cleared for\r\n packets coming from the other direction.\r\n It is an implementation-specific matter\r\n| as to which bit is assigned to which\r\n direction, but it must be consistent for\r\n all packets received by the agent. [...]\r\n\r\nThis text certainly is intended to always (and only) cover bit #6.\r\nTherefore, the wording, \"which bit is assigned\" is misleading;\r\nit should be \"which [bit] value is assigned\".\r\n\r\nThus, the above snippit sould better say:\r\n\r\n Bit Definition\r\n\r\n 6 For WAN media, this bit is set for packets\r\n coming from one direction and cleared for\r\n packets coming from the other direction.\r\n It is an implementation-specific matter\r\n| as to which bit value is assigned to which\r\n direction, but it must be consistent for\r\n all packets received by the agent. [...]\r\n\r\n\r\n(2) Ref. issue\r\n\r\nIn Section 3.2, the third paragraph on page 9 says:\r\n\r\n In the RMON MIB [RFC2819], the EntryStatus textual convention was\r\n introduced to provide this mutual exclusion function. Since then,\r\n this function was added to the SNMP framework as the RowStatus\r\n textual convention. The RowStatus textual convention is used for the\r\n definition of all new tables.\r\n\r\nThis text unfortunately has turned wrong by updating the (obsolete)\r\nreference \"[RFC1757]\" (in RFC 2102) to \"[RFC2819]\".\r\n(-- A very unusual event! --)\r\nThe text in RFC 2102 was correct, because RFC 1757 predates the\r\ninvention of the 'RowStatus' TC which was finalized in STD 58.\r\nBut STD 58 predates RFC 2819, and therefore, the clause,\r\n vvvvvvvvvv\r\n| Since then,\r\n this function was added to the SNMP framework\r\n as the RowStatus textual convention.\r\nhas turned wrong by the replacement of the Ref.!\r\n\r\n(NOTE: RFC 2819 in fact still makes use of the 'EntryStatus' TC,\r\n which already had been introduced in RFC 1271, the predecessor\r\n of RFC 1757 !)\r\n\r\nTo correct this issue without causing a need to update the\r\nReferences of RFC 4502 as well, I propose the following substitute\r\ntext as an Erratum for the text snippit above:\r\n\r\n vvvvvvvvvvvvvvvvvvvv\r\n| In the predecessors of the RMON MIB [RFC2819], the EntryStatus\r\n textual convention was introduced to provide this mutual exclusion\r\n function. Since then, this function was added to the SNMP framework\r\n as the RowStatus textual convention. The RowStatus textual\r\n convention is used for the definition of all new tables.\r\n\r\n\r\n(3) outdated Ref.\r\n\r\nThe DESCRIPTION clause of the protocolDirID OBJECT-TYPE,\r\non page 21/22 of RFC 4502, says:\r\n\r\n DESCRIPTION\r\n \"A unique identifier for a particular protocol. Standard\r\n identifiers will be defined in such a manner that they\r\n<< page break >>\r\n can often be used as specifications for new protocols - i.e.,\r\n a tree-structured assignment mechanism that matches the\r\n protocol encapsulation 'tree' and that has algorithmic\r\n assignment mechanisms for certain subtrees. See RFC 2074 for\r\n more details.\r\n\r\n [...]\r\n\r\nRFC 2074 has been obsoleted by RFC 2895 and RFC 2896.\r\nTherefore, the last sentence of this paragraph should better say:\r\n\r\n [...]. See RFC 2895 and\r\n RFC 2896 for more details.\r\n\r\n\r\n(4) MIB indexing issue #1\r\n\r\nAs stated in the text added by RFC 4502 to the DESCRIPTION clause\r\nof the addressMapEntry OBJECT-TYPE, the addressMapTable might run\r\nin problems due to the cumulative length of its index object\r\ninstances.\r\n\r\nTherefore, I suspect that it might have been better to replace the\r\nlast index object, addressMapSource, by an object mirroring the\r\naddressMapControlIndex object (direct use of addressMapControlIndex\r\nas the *last* index object might not be considered a valid option).\r\n\r\nNOTE:\r\nI know that it it too late now for any change, unfortunately.\r\n\r\n\r\n(5) MIB indexing issue #2\r\n\r\nThe DESCRIPTION clause of the TimeFilter TEXTUAL-CONVENTION,\r\non page 16, explains that an index object of type TimeFilter\r\nshould be included as the *first* INDEX component for a time-\r\nfiltered table:\r\n\r\n A time-filtered conceptual table is created by inserting a\r\n single object of SYNTAX TimeFilter as the first INDEX component\r\n in a copy of an existing basic conceptual table (i.e., any\r\n SEQUENCE without a TimeFilter INDEX component). [...]\r\n\r\nThe RMON2 MIB does not follow this rule for the following tables:\r\n - nlHostTable,\r\n - nlMatrixSDTable,\r\n - nlMatrixDSTable,\r\n - alHostTable,\r\n - alMatrixSDTable, and\r\n - alMatrixDSTable.\r\n\r\nSince there are arguably good reasons for the present indexing\r\nstructure of these tables, it might perhaps have been better\r\nto have the above DESCRIPTION of the TC modified to accommodate\r\nfor the existing practice.\r\n\r\n\r\n(6) textual issue\r\n\r\nThe first paragraph of the DESCRIPTION clause for the\r\nalMatrixTopNControlRateBase OBJECT-TYPE, on page 78, says:\r\n\r\n \"This object controls which alMatrix[SD/DS] entry that the\r\n alMatrixTopNEntries are sorted by, which view of the matrix\r\n table that will be used, as well as which table the results\r\n will be reported in.\r\n\r\nIt should perhaps better say (deleting 2 x 'that'):\r\n\r\n| \"This object controls which alMatrix[SD/DS] entry the\r\n alMatrixTopNEntries are sorted by, which view of the matrix\r\n| table will be used, as well as which table the results\r\n will be reported in.\r\n\r\n\r\n(7) wrong numerical limits in ASN.1 comment\r\n\r\nThe ASN.1 comments on the User History Collection Group,\r\nin the second paragraph on page 86, says:\r\n\r\n-- A sample value is stored in two objects - an absolute value and\r\n-- a status object. This allows numbers from -(2G-1) to +4G to be\r\n-- stored. The status object also indicates whether a sample is\r\n-- valid. This allows data collection to continue if periodic\r\n-- retrieval of a particular instance fails for any reason.\r\n\r\nBased on the specification of usrHistoryAbsValue and\r\nusrHistoryValStatus (on page93/94), I strongly suspect that the\r\nspecified limits are wrong, and that this text should say:\r\n\r\n-- A sample value is stored in two objects - an absolute value and\r\n-- a status object. This allows numbers from -(4G-1) to +(4G-1) to\r\n-- be stored. The status object also indicates whether a sample is\r\n-- valid. This allows data collection to continue if periodic\r\n-- retrieval of a particular instance fails for any reason.\r\n\r\n\r\n(8) inappropriate semantics specified in DESCRIPTION text\r\n for objects in the usrHistoryControlTable\r\n\r\nThe DESCRIPTION clause of the usrHistoryControlBucketsRequested and\r\nusrHistoryControlBucketsGranted objects (on page 87/88) seem to be\r\ngarbled a bit.\r\n\r\nThe latter contains the (3rd) paragraph:\r\n\r\n The associated usrHistoryControlBucketsRequested object\r\n should be set before or at the same time as this object\r\n to allow the probe to accurately estimate the resources\r\n required for this usrHistoryControlEntry.\r\n\r\nThis makes no sense here, because the usrHistoryControlBucketsGranted\r\nobject is read-only, and hence cannot be set.\r\n\r\nI strongly suspect that a similar coupling in fact is needed\r\nfor the usrHistoryControlObjects object in relation to the\r\nusrHistoryControlBucketsRequested object:\r\nThe probe cannot estimate the internal resource requirements,\r\nand hence determine the value of usrHistoryControlBucketsGranted\r\nwithout knowing the values of both the usrHistoryControlObjects\r\nand the usrHistoryControlBucketsRequested objects in a row.\r\n\r\nTherefore, I suspect that the above paragraph should be deleted,\r\nand re-inserted with a slight modification as the new second\r\nparagraph into the usrHistoryControlBucketsRequested DESCRIPTION\r\nclause, saying:\r\n vvvvvvv\r\n| The associated usrHistoryControlObjects object\r\n should be set before or at the same time as this object\r\n to allow the probe to accurately estimate the resources\r\n required for this usrHistoryControlEntry.\r\n\r\n(I intentionally have omitted the appropriate line re-folding\r\n here for clarity.)\r\n\r\n\r\n(9) two typos\r\n\r\nThe DESCRIPTION clause of the ControlString TEXTUAL-CONVENTION,\r\non page 95, contains two typos:\r\n\r\nThe paragraph:\r\n\r\n ^w Wait for the reply string that follows, which is\r\n terminated by the next command or the end of string.\r\n Partial and case-insensitive matching is applied, i.e.,\r\n if the reply string (any case combination) is found\r\n anywhere in the received string, then the a match is\r\n found. If the current timeout elapses without a match,\r\n then the remaining control string is ignored.\r\n\r\nshould say (deleting 'the' in 'the a') :\r\n\r\n ^w Wait for the reply string that follows, which is\r\n terminated by the next command or the end of string.\r\n Partial and case-insensitive matching is applied, i.e.,\r\n if the reply string (any case combination) is found\r\n| anywhere in the received string, then a match is found.\r\n If the current timeout elapses without a match, then\r\n the remaining control string is ignored.\r\n\r\nThe 4th-to-last line of page 95,\r\n\r\n ^ 0x1C\r\n\r\nshould say:\r\n\r\n ^\\ 0x1C\r\n\r\n\r\n(10) textual clarification\r\n\r\nIn the Appendix of RFC 4502 (Section 8), the paragraph below\r\nthe pseudo-code on page 133 says:\r\n\r\n The agent applies this function regardless of the lastActivationTime\r\n of the conceptual row in question. In other words, counter\r\n discontinuities are ignored (i.e., a conceptual row is deleted and\r\n then re-created later). An agent should consider an object instance\r\n 'changed' when it is created (either at restart time for scalars and\r\n static objects, or row-creation-time for dynamic tables).\r\n\r\nIt should better say:\r\n\r\n The agent applies this function regardless of the lastActivationTime\r\n of the conceptual row in question. In other words, counter\r\n| discontinuities (e.g., a conceptual row is deleted and then re-\r\n| created later) are ignored. An agent should consider an object\r\n instance 'changed' when it is created (either at restart time for\r\n scalars and static objects, or row-creation-time for dynamic tables).", "correct_text": "", "notes": "from pending", "submit_date": "2006-06-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "78", "doc-id": "RFC4501", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": " In particular, the \"dnsname\" field of the DNS URI is to be\r\n considered an internationalized domain name (IDN) unaware\r\n domain name slot, in the terminology of RFC 3940 [14].", "correct_text": " In particular, the \"dnsname\" field of the DNS URI is to be\r\n considered an internationalized domain name (IDN) unaware\r\n domain name slot, in the terminology of RFC 3490 [14].", "notes": "Reference 14 is RFC 3490 not RFC 3940.", "submit_date": "2006-05-23", "submitter_name": "Yitzchak M. Gottlieb", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "79", "doc-id": "RFC4483", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) Inconsistent Ref. to URI Specification\r\n\r\nThe text of RFC 4483 repeatedly refers to \"RFC2396 [7]\" .\r\nThis is misleading.\r\nEvery occurrence of \"RFC 2396\" should be replaced by \"RFC 3986\".\r\n\r\nNote: Section 10.1. Normative References, holds the proper\r\n reference to STD 66, RFC 3986 in its item [7] !\r\n\r\n\r\n(2) Outdated Ref. to HTTP 1.1 Specification\r\n\r\nItem [4] of Section 10.1 Normative References, points to the\r\noutdated original specification for HTTP 1.1, RFC 2016,\r\nwhich has been obsoleted by RFC 2616, 7 years ago.\r\n\r\nSince the HTTP ETAG mechanism (referred to in the text of RFC 4483)\r\nhas been clarified substantially in RFC 2616, the reference to\r\n\"RFC2068 [4]\" in Section 4, near the bottom of page 5 of RFC 4483,\r\nshould bhave been \"RFC2616 [4]\", and the item [4] of Section 10.1,\r\non page 15 of RFC 4483, should be replaced by a citation of RFC 2616\r\naccording to `rfc-ref.txt`.\r\n\r\n\r\n(3) (Mis)Use of SIP Terminology\r\n\r\nUnfortunately, RFC 4483 substantially adds to the confusion\r\nof precisely defined SIP (and other) terminology.\r\n\r\nIn particular, *all* occurrences of the term \"Header[s]\" in RFC 4483\r\nshould be corrected to say \"Header Field[s]\".\r\n\r\nRFC 4485, published just 2 weeks ahead of RFC 4483, explicitely\r\nposes the requirement for SIP extension documents to follow the\r\nestablished SIP terminology -- cf. Section 4.3 of RFC 4485\r\n(page 10), which says:\r\n\r\n Careful attention must be paid to the actual usage of terminology.\r\n Many documents misuse the terms header, header field, and header\r\n field values, for example. Document authors SHOULD do a careful\r\n review of their documents for proper usage of these terms.\r\n\r\nSee also RFC 4249, Section 3.1.1 (page 3) for a similar statement on\r\nthe proper usage of these terms in the context of IMF and MIME, and\r\nrelated (extension) specifications.", "correct_text": "", "notes": "from pending", "submit_date": "2006-06-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2310", "doc-id": "RFC5923", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2", "orig_text": "[[ in the last paragraph at the bottom of page 13: ]]\r\n\r\n The server, if it decides to reuse the connection, MUST cache in the\r\n alias table the identity (or identities) of the client as they appear\r\n| in the X.509 certificate subjectAlternativeName extension field. [...]\r\n ^^^^^^^^^^^", "correct_text": " The server, if it decides to reuse the connection, MUST cache in the\r\n alias table the identity (or identities) of the client as they appear\r\n| in the X.509 certificate subjectAltName extension field. [...]\r\n ^^^", "notes": "Rationale:\r\n Mis-spelling of the defined certificate extension name --\r\n see (for example) RFC 5280.", "submit_date": "2010-06-24", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "312", "doc-id": "RFC3267", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.3", "orig_text": " The FT field and the Q bit are defined in the same way as in\n Section 4.1.2. The P bits are padding and MUST be set to 0.", "correct_text": " The FT field and the Q bit are defined in the same way as in\n Section 4.3.2. The P bits are padding and MUST be set to 0.\n", "notes": "", "submit_date": "2002-07-29", "submitter_name": "Frederic Turgis", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "313", "doc-id": "RFC3266", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "Section 1 refers to RFC 2328 as follows:\n\n Accordingly, the address type \"IP6\" indicating an IPv6 address,\n should be allowed in the connection field, \"c=\", of the SDP. The\n ABNF already reflects this, though the \"Connection Data\" text under\n section 6 of RFC 2328 currently only defines the \"IP4\" address type.\n ^^^^\nIt should refer to RFC 2327.\n", "correct_text": "", "notes": "", "submit_date": "2004-01-15", "submitter_name": "Bernie Hoeneisen", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "314", "doc-id": "RFC3265", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the Header: ", "orig_text": " Updates: 2543", "correct_text": " Updates: 3261\n", "notes": "", "submit_date": "2002-07-23", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "315", "doc-id": "RFC3262", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "This document obsoletes RFC 2543.\n", "submit_date": "2002-07-04", "submitter_name": "Steve Conner", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "316", "doc-id": "RFC3261", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Section 25.1: ", "orig_text": " digest-uri-value = rquest-uri ; Equal to request-uri as\r\n specified by HTTP/1.1 ", "correct_text": " digest-uri-value = request-uri ; Equal to request-uri as\r\n specified by HTTP/1.1\r\n", "notes": "", "submit_date": "2003-10-03", "submitter_name": "RFC Editor", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "317", "doc-id": "RFC3253", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "The WebDAV working group maintains an errata list for RFC3253 at:\r\nhttp://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm", "submit_date": "2003-10-11", "submitter_name": "Julian Reschke", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "318", "doc-id": "RFC3247", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1", "orig_text": " Finally, there is an additional recommendation in [6] that an EF\r\n compliant node SHOULD NOT reorder packets within a micorflow.", "correct_text": " Finally, there is an additional recommendation in [6] that an EF\r\n compliant node SHOULD NOT reorder packets within a microflow.\r\n", "notes": "micorflow --> microflow", "submit_date": "2006-02-02", "submitter_name": "\"laercio cruvinel\"", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "319", "doc-id": "RFC3245", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": "4.2. Name server operator requirements\n\n RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt) describes the\n requirements for operating DNS root servers.\"", "correct_text": "4.2. Name server operator requirements\n\n RFC 2870 (http://www.ietf.org/rfc/rfc2870.txt) describes the\n requirements for operating DNS root servers.\"\n", "notes": "", "submit_date": "2004-01-02", "submitter_name": "Derrick D. Daugherty", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "449", "doc-id": "RFC2407", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "The section 4 header is missing from the document. Presently, the document is structured as follows:\n\n1. Abstract\n2. Introduction\n3. Terms and definitions\n 4.1 IPSEC naming scheme\n 4.2 IPSEC situation definition\n...etc.\n", "submit_date": "2004-03-04", "submitter_name": "Jan Wuyts", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "80", "doc-id": "RFC4479", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3", "orig_text": " It is central to this model that each attribute\r\n is affiliated with the service, person, or device because they\r\n describe that service, presentity, or device. This is in contrast to\r\n a model whereby the attributes are associated with the service,\r\n presentity, or device because they were reported by that service,\r\n presentity, or device. ", "correct_text": " It is central to this model that each attribute\r\n is affiliated with the service, person, or device because they\r\n describe that service, person, or device. This is in contrast to\r\n a model whereby the attributes are associated with the service,\r\n person, or device because they were reported by that service,\r\n person, or device. ", "notes": "\r\nRegarding the definition from Section 2, on top of page 4 of the RFC,\r\n\r\n Presentity: A presentity combines devices, services, and person\r\n information for a complete picture of a user's presence status on\r\n the network.\r\n\r\nIMHO the term \"presentity\" should have been replaced by \"person\" to keep this text passage\r\nconsistent with the terminology introduced in Section 2.", "submit_date": "2006-08-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "81", "doc-id": "RFC4470", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": " ).com 3600 IN NSEC +.com ( RRSIG NSEC )", "correct_text": " \\).com 3600 IN NSEC \\+.com ( RRSIG NSEC )", "notes": "Line should use the escape characters as defined in RFC 1035.", "submit_date": "2006-05-09", "submitter_name": "Sam Weiler", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "82", "doc-id": "RFC4455", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(1) typo\r\n\r\nSection 3.5 of RFC 4455, on page 11, says:\r\n\r\n The management of SCSI commands is beyond the scope of this MIB\r\n| module. Future SCSI Command MIB module can link to this MIB module,\r\n through the use of Object Identifiers (OIDs) or INDEX values of\r\n appropriate tables.\r\n\r\nIt should say:\r\n v\r\n The management of SCSI commands is beyond the scope of this MIB\r\n| module. Future SCSI Command MIB modules can link to this MIB module,\r\n through the use of Object Identifiers (OIDs) or INDEX values of\r\n appropriate tables.\r\n\r\n\r\n(2) typo\r\n\r\nSection 4.1 of RFC 4455, on page 11, says:\r\n\r\n The scsiDeviceGroup group contains the objects general to each SCSI\r\n instance: instance, device, and port objects. It contains also the\r\n objects referring to the transport(s) used by those SCSI instances.\r\n| This group is mandatory for all SCSI managed system.\r\n\r\nIt should say:\r\n\r\n The scsiDeviceGroup group contains the objects general to each SCSI\r\n instance: instance, device, and port objects. It contains also the\r\n objects referring to the transport(s) used by those SCSI instances.\r\n| This group is mandatory for all SCSI managed systems.\r\n ^\r\n\r\n(3) word omission\r\n\r\nThe second paragraph of Section 4.7, on page 12, says:\r\n\r\n Managed systems acting as a SCSI target device and port and running\r\n| at high speed supporting should implement this group.\r\n\r\nIt should say:\r\n\r\n Managed systems acting as a SCSI target device and port and running\r\n| at high speed supporting statistics should implement this group.\r\n ^^^^^^^^^^^\r\n\r\n\r\n(4) word omission\r\n\r\nThe second paragraph of Section 4.11, on page 13, says:\r\n\r\n Managed systems acting as a SCSI initiator device and port and\r\n running at high speed supporting should implement this group.\r\n\r\nIt should say:\r\n\r\n Managed systems acting as a SCSI initiator device and port and\r\n| running at high speed supporting statistics should implement this\r\n group.\r\n ^^^^^^^^^^^\r\n\r\n(5) text truncation\r\n\r\nThe DESCRIPTION clause of the scsiTransportFCP OBJECT-IDENTITY,\r\non page 24, says:\r\n\r\n \"This identity identifies a Fibre Channel Protocol for SCSI,\r\n Second Version.\"\r\n\r\nThis sentence omits the most significant word, \"transport\".\r\nIt should say:\r\n\r\n \"This identity identifies a Fibre Channel Protocol for SCSI,\r\n| Second Version, transport.\"\r\n ^^^^^^^^^^^\r\nor:\r\n vvvvvvvvvvvvvvvvvvv\r\n| \"This identity identifies transport via the Fibre Channel\r\n Protocol for SCSI, Second Version.\"\r\n\r\n\r\n(6) incomplete description, and incomplete functionality ??\r\n\r\nThe DESCRIPTION clause of the scsiPortBusyStatuses OBJECT-TYPE,\r\non page 30, says:\r\n\r\n [...]\r\n Discontinuities in the value of this counter can occur at re-\r\n initialization of the management system.\"\r\n\r\nAdmittedly, this is true, but more importantly, the counter can\r\nwrap back from 2^32-1 to 0 !!!\r\nThat should be noted there, and it should be detectable by means\r\nof some 'discontinuity time stamp' object in the MIB module.\r\n\r\n\r\n(7) as (6) above\r\n\r\nThe same issue as stated in item (6) above also holds for the\r\nscsiIntrDevOutResets OBJECT-TYPE, on page 33.\r\n\r\n\r\n(8) as (6) above\r\n\r\nThe same issue as stated in item (6) above also holds for all\r\ncounters in the SCSI Initiator Port Table, i.e. the DESCRIPTIONs\r\nof the scsiIntrPortOutCommands, scsiIntrPortWrittenMegaBytes,\r\nscsiIntrPortReadMegaBytes, and scsiIntrPortHSOutCommands\r\nOBJECT-TYPEs, on page 35.\r\n\r\n\r\n(9) typo\r\n\r\nThe ASN.1 comment on top of page 36,\r\n\r\n -- SCSI target device discovered or authorized to attach each of the\r\n -- SCSI initiator ports of each SCSI initiator device of each\r\n -- instance.\r\n\r\nshould say:\r\n v\r\n| -- SCSI target devices discovered or authorized to attach each of the\r\n -- SCSI initiator ports of each SCSI initiator device of each\r\n -- instance.\r\n\r\n\r\n(10) typo (spurious word)\r\n\r\nThe DESCRIPTION clause of the scsiDscTgtIndex OBJECT-TYPE, on page 37,\r\nsays:\r\n\r\n \"This object is an arbitrary integer used to uniquely identify\r\n a particular SCSI target device either discovered by, or\r\n| configured for use with, one or more ports scsiDscTgtName of\r\n a particular device within a particular SCSI instance.\"\r\n\r\nThe spurious word \"scsiDscTgtName\" should be deleted.\r\nThus, it should say:\r\n\r\n \"This object is an arbitrary integer used to uniquely identify\r\n a particular SCSI target device either discovered by, or\r\n| configured for use with, one or more ports of a particular\r\n device within a particular SCSI instance.\"\r\n\r\n\r\n(11) typo (spurious word)\r\n\r\nThe DESCRIPTION clause of the scsiDscTgtDevOrPort OBJECT-TYPE,\r\non page 37, says:\r\n\r\n \"This object indicates whether this entry describes a\r\n| configured SCSI target device name (and applies to all ports\r\n on the identified SCSI target device) or an individual SCSI\r\n target port.\"\r\n\r\nThe spurious word \"name\" should be deleted.\r\nThus, it should say:\r\n\r\n \"This object indicates whether this entry describes a\r\n| configured SCSI target device (and applies to all ports\r\n on the identified SCSI target device) or an individual SCSI\r\n target port.\"\r\n\r\n\r\n(12) similar to (6), and semantic overloading\r\n\r\nThe DESCRIPTION clause of the scsiDscTgtInCommands OBJECT-TYPE,\r\non page 38, says:\r\n\r\n [...]\r\n Discontinuities in the value of this counter can occur at re-\r\n initialization of the management system, and at other times as\r\n indicated by the value of scsiDscTgtLastCreation.\"\r\n\r\nThe literally same wording is repeated on page 39 in the DESCRIPTION\r\nclauses of the OBJECT-TYPEs\r\n- scsiDscTgtWrittenMegaBytes,\r\n- scsiDscTgtReadMegaBytes, and\r\n- scsiDscTgtHSInCommands.\r\n\r\nSee the explanations for item (6) above.\r\n\r\nThe DESCRIPTION clause of the scsiDscTgtLastCreation OBJECT-TYPE,\r\nat the bottom of page 39, says:\r\n\r\n \"This object represents the value of sysUpTime when this row\r\n| was created.\"\r\n\r\nCounter wrap-around isn't table row creation.\r\nThus, isn't the above referral heavy semantic overloading of\r\n\"Last Creation\" time ??\r\n\r\n\r\n(13) typo\r\n\r\nThe ASN.1 comment near the bottom of page 43,\r\n\r\n| --***** Table of SCSI Target Device Attached to local SCSI\r\n --***** Initiator Ports\r\n\r\nshould say:\r\n v\r\n| --***** Table of SCSI Target Devices Attached to local SCSI\r\n --***** Initiator Ports\r\n\r\n\r\n(14) as (6) above\r\n\r\nThe DESCRIPTION clauses, on page 49, of the OBJECT-TYPEs\r\n- scsiTgtPortInCommands,\r\n- scsiTgtPortWrittenMegaBytes,\r\n- scsiTgtPortReadMegaBytes, and\r\n- scsiTgtPortHSInCommands\r\ncontain the sentence,\r\n\r\n Discontinuities in the value of this counter can occur at re-\r\n initialization of the management system.\"\r\n\r\nthe explanations given for item (6) above apply here as well.\r\n\r\n\r\n(15) improper wording\r\n\r\nThe DESCRIPTION clause of the scsiTgtPortHSInCommands OBJECT-TYPE,\r\non page 49, says:\r\n\r\n \"This object represents the number of commands received. This\r\n| object provides support for systems that can quickly generate a\r\n large number of commands because they run at high speed.\r\n [...]\r\n\r\nBecause this object counts *incoming* commands, the word \"generate\"\r\nis considered improper and should be replaced by \"accept\" (or similar):\r\n\r\n \"This object represents the number of commands received. This\r\n| object provides support for systems that can quickly accept a\r\n large number of commands because they run at high speed.\r\n [...]\r\n\r\n\r\n(16) like (12) above\r\n\r\nThe SCSI Authorized Initiator table suffers from the same problems\r\nas the Target Device Discovered Table (Item (12) above):\r\n\r\nThe DESCRIPTION clauses (on pages 52/53) of the OBJECT-TYPEs\r\n- scsiAuthIntrAttachedTimes,\r\n- scsiAuthIntrOutCommands,\r\n- scsiAuthIntrReadMegaBytes,\r\n- scsiAuthIntrWrittenMegaBytes, and\r\n- scsiAuthIntrHSOutCommands\r\neach contain the identical sentence:\r\n\r\n Discontinuities in the value of this counter can occur at re-\r\n initialization of the management system, and at other times as\r\n indicated by the value of scsiAuthIntrLastCreation.\"\r\n\r\nand the DESCRIPTION clause of the scsiAuthIntrLastCreation OBJECT-TYPE,\r\non page 53, says:\r\n\r\n \"This object indicates the value of sysUpTime when this row was\r\n last created.\"\r\n\r\nCounter wrap-around isn't table row creation.\r\nThus, isn't the above referral heavy semantic overloading of\r\n\"Last Creation\" time ??\r\n\r\n\r\n(17) again, like (12) above\r\n\r\nThe SCSI LU table suffers from the same problems as above:\r\n\r\nThe DESCRIPTION clauses (on pages 60..62) of the OBJECT-TYPEs\r\n- scsiLuInCommands,\r\n- scsiLuReadMegaBytes,\r\n- scsiLuWrittenMegaBytes,\r\n- scsiLuInResets,\r\n- scsiLuOutTaskSetFullStatus, and\r\n- scsiLuHSInCommands\r\neach contain the identical sentence:\r\n\r\n Discontinuities in the value of this counter can occur at re-\r\n initialization of the management system, and at other times as\r\n indicated by the value of scsiLuLastCreation.\"\r\n\r\nwhile the DESCRIPTION clause of the scsiLuLastCreation OBJECT-TYPE,\r\non page 62, says:\r\n\r\n \"This object indicates the value of sysUpTime when this row was\r\n last created.\"\r\n\r\nAgain, counter wrap-around isn't table row creation.\r\nThus, isn't the above referral heavy semantic overloading of\r\n\"Last Creation\" time ??\r\n\r\n\r\n(18) MIB structure inconsistency ???\r\n\r\nOn page 66, RFC 4455 says:\r\n\r\n --********************** Notifications ******************************\r\n| -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 2 }\r\n ^^^\r\n\r\n scsiNotificationsPrefix OBJECT IDENTIFIER\r\n ::= { scsiNotifications 0 }\r\n\r\nThis is very notable, since on page 23, the same RFC has\r\nspecified:\r\n\r\n --****************** Structure of the MIB **************************\r\n| scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 }\r\n [...]\r\n ^^^\r\n\r\nAt least, giving different values for the same object name\r\n(though one instance is in an ASN.1 comment) is irritating.\r\n\r\nThe trailing OID component '0' is required for SNMPv1 backwards\r\ncompatibility. Since it is already contained in the effective\r\n'scsiNotifications' OID (as specified on page 23), the additional\r\nintroduction of 'scsiNotificationsPrefix' seems to be very\r\nredundant. Its use could be easily substituted by the use of\r\n'scsiNotifications' in the two NOTIFICATION-TYPE invocations\r\non page 66, which would have resulted in the OID assignments,\r\n\r\n scsiTgtDeviceStatusChanged NOTIFICATION-TYPE\r\n [...]\r\n ::= { scsiNotifications 1 }\r\n\r\nand\r\n\r\n scsiLuStatusChanged NOTIFICATION-TYPE\r\n [...]\r\n ::= { scsiNotifications 2 }\r\n\r\nas usual in IETF MIBs.\r\n\r\nThat is now too late to be corrected, but the misleading ASN.1 comment\r\non page 66 of the RFC, as noted above, should be corrected to say:\r\n\r\n --********************** Notifications ******************************\r\n| -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 }\r\n ^^^\r\n\r\n(19) typo\r\n\r\nThe ASN.1 comment on page 67,\r\n\r\n -- Conditionally mandatory groups to be included with\r\n -- the mandatory groups when the implementation has\r\n| -- SCSI target device.\r\n\r\nshould say:\r\n\r\n -- Conditionally mandatory groups to be included with\r\n -- the mandatory groups when the implementation has\r\n| -- SCSI target devices.\r\n ^\r\n\r\n(20) typo\r\n\r\nThe DESCRIPTION clause of the scsiInitiatorDeviceGroup OBJECT-GROUP\r\ninvocation, on page 71, says:\r\n\r\n \"This group is relevant for s SCSI initiator device and port.\"\r\n\r\nshould say:\r\n v\r\n| \"This group is relevant for a SCSI initiator device and port.\"\r\n\r\nor even better:\r\n\r\n| \"This group is relevant for SCSI initiator devices and ports.\"\r\n\r\n\r\n(21) duplicate / redundant text\r\n\r\nSection 10, on page 76, contains the 5th paragraph:\r\n\r\n We assume an HBA as the SCSI initiator device and a disk as the SCSI\r\n target device. We assume that the SCSI target device has one logical\r\n unit, addressed by Logical Unit Number set to 0 (LUN0), which is the\r\n default LUN. Parallel SCSI has only port identifiers, no port names.\r\n The transport pointer for parallel SCSI is set to 0 since there is no\r\n reference transport (SPI) MIB module.\r\n\r\nThis text is a slightly modified restatement of what is said in the\r\ndirectly preceeding paragraph.\r\nThus, this paragraph should be deleted.", "correct_text": "", "notes": "Notes from Keith:\r\nI think the only one of your corrections which is needed to avoid the\r\npossibility of causing confusion to a reader is the one regarding the\r\nOID of scsiNotifications. If an RFC Errata Note is created because\r\nof that one, and all the other typos that you have found are also\r\nincluded in the same RFC Errata Note, then my fear is that the one\r\nwhich could be important will get buried in the triviality of the\r\nothers. Thus, I suggest that an RFC Errata Note, if created, should\r\nonly mention the OID of scsiNotifications.\r\n\r\nI don't believe there are any items which need to be considered by the\r\nWG for a future update to the MIB module.\r\n\r\nfrom pending", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Keith McCloghrie", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "83", "doc-id": "RFC4455", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Page 66 says:", "orig_text": " --********************** Notifications ******************************\r\n -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 2 }", "correct_text": " --********************** Notifications ******************************\r\n -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 }", "notes": "There are two issues here:\r\n\r\n1) a typo in the ASN.1 comments. The correct OID is { scsiMIB 0 } because\r\nthat's what the MIB compiler will process, i.e., the MIB compiler will\r\nnot process the ASN.1 comment. It is not too late to correct the typo\r\nin the ASN.1 comment.\r\n\r\n2) In the development of the MIB, the change to use the OID structure\r\nrecommended by Appendix D of RFC 4181 caused the use of\r\nscsiNotificationsPrefix (as the means to include zero in the OIDs of\r\nthe notifications) to become no longer necessary, and it would have\r\nbeen better if it had been removed. But, it is now too late to remove\r\nscsiNotificationsPrefix.", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Keith McCloghrie", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "84", "doc-id": "RFC4450", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8", "orig_text": " This experiment would have been completely useless without\r\n participation of the members of the old-standards mailing list.\r\n Most notably, Pekka Savalo, Bob...", "correct_text": " This experiment would have been completely useless without\r\n participation of the members of the old-standards mailing list.\r\n Most notably, Pekka Savola, Bob...", "notes": "Typo in Pekka Savola's name", "submit_date": "2006-03-29", "submitter_name": "Sam Weiler", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "85", "doc-id": "RFC4448", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "1) a subtle typo\r\n\r\nSection 4.5 of RFC 4448, on top of page 12, says:\r\n\r\n The Ethernet PW management model follows the general PW management\r\n model defined in [RFC3985] and [PWE3-MIB]. Many common PW management\r\n facilities are provided here, with no additional Ethernet specifics\r\n necessary. Ethernet-specific parameters are defined in an additional\r\n MIB module, [PW-MIB].\r\n\r\nIt should say, replacing \"here\" by \"there\":\r\n\r\n The Ethernet PW management model follows the general PW management\r\n model defined in [RFC3985] and [PWE3-MIB]. Many common PW management\r\n| facilities are provided there, with no additional Ethernet specifics\r\n necessary. Ethernet-specific parameters are defined in an additional\r\n MIB module, [PW-MIB].\r\n\r\n\r\n(2) terminological issue / violation of reference model\r\n\r\nSection 4.4.1 of RFC 4448, on pp. 9/10, says:\r\n\r\n--- snip ---\r\n When the PE receives an Ethernet frame, and the frame has a VLAN tag,\r\n we can distinguish two cases:\r\n\r\n 1. The tag is service-delimiting. This means that the tag was\r\n placed on the frame by some piece of service provider-operated\r\n equipment, and the tag is used by the service provider to\r\n distinguish the traffic. For example, LANs from different\r\n customers might be attached to the same service provider\r\n switch, which applies VLAN tags to distinguish one customer's\r\n traffic from another's, and then forwards the frames to the PE.\r\n\r\n 2. The tag is not service-delimiting. This means that the tag was\r\n placed in the frame by a piece of customer equipment, and is\r\n not meaningful to the PE.\r\n\r\n Whether or not the tag is service-delimiting is determined by local\r\n configuration on the PE.\r\n--- snip ---\r\n\r\nIMHO, this is a very unfortunate explanation.\r\n\r\na) The term, \"service delimiting\", apparently here is defined\r\n by the origin of the tag, not by its function.\r\n I do not believe that this is the appropriate way to deal with;\r\n later on in RFC 4448, it (reasonably) seems to be permitted\r\n that a service-delimiting tag has been provided by a CE device!\r\n\r\nb) The situation described in bullet 1), with a provider owned\r\n switch, removes the PW terminating entity from the provider\r\n *edge*, turning it from a \"PE\" device into a \"P\" device,\r\n which is highly inconsistent with the service model developed\r\n in Section 1 of RFC 4448, and leads to a clash in terminology.\r\n To stay within that model, the \"coloring\" function described\r\n in bullet 1) must conceptionally be performed by the NSP\r\n function *within* the (PW terminating) PE device. (And it might\r\n as well be performed in customer equipment, i.e. at the CE.)\r\n\r\nPerhaps, the above text should be improved.\r\nI'll try at a first proposal:\r\n\r\n--- snip ---\r\n When the PE receives an Ethernet frame, and the frame has a VLAN tag,\r\n we can distinguish two cases:\r\n\r\n 1. The tag is service-delimiting.\r\n\t This means that the tag was introduced for the single purpose\r\n\t of identifying the frame for the PW service, e.g., to select a\r\n\t specific PW for transmission of the frame. A service-\r\n\t delimiting tag may have been added on the CE side or in the\r\n (conceptual) NSP function of the PE edge.\r\n\t Ordinarily, any service-delimiting tag will not be transmitted\r\n\t over the PW, i.e., it will be removed before PW encapsulation.\r\n\r\n 2. The tag is not service-delimiting. This means that the tag is\r\n not meaningful to the PW endpoints and must be transmitted over\r\n\t the PW.\r\n\t Such tag usually was placed in the frame by a piece of customer\r\n\t equipment, but it might as well be added or modified by the NSP\r\n\t function of the PW terminating PE device.\r\n\r\n Whether or not the tag is service-delimiting is determined by local\r\n configuration on the PE.\r\n--- snip ---", "correct_text": "", "notes": "from pending", "submit_date": "2006-05-25", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "86", "doc-id": "RFC4447", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "Abstract says:", "orig_text": " It is also possible to use pseudowires to\r\n provide low-rate Time Division Multiplexed and a Synchronous Optical\r\n NETworking circuit emulation over an MPLS-enabled network. This\r\n document specifies a protocol for establishing and maintaining the\r\n pseudowires, using extensions to Label Distribution Protocol (LDP).\r\n Procedures for encapsulating Layer 2 PDUs are specified in a set of\r\n companion documents.", "correct_text": " It is also possible to use pseudowires to\r\n| provide low-rate Time Division Multiplexed and Synchronous Optical\r\n NETworking circuit emulation over an MPLS-enabled network. This\r\n document specifies a protocol for establishing and maintaining the\r\n| pseudowires, using extensions to the Label Distribution Protocol\r\n (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a\r\n set of companion documents.", "notes": "use of articles", "submit_date": "2006-11-09", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "87", "doc-id": "RFC4444", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "", "orig_text": "(2) issue: non-use of appropriate TC (?)\r\n\r\nThe isisCircLevelIDOctet OBJECT-TYPE macro instance, on page 36,\r\ncontains the SYNTAX clause:\r\n\r\n isisCircLevelIDOctet OBJECT-TYPE\r\n SYNTAX Unsigned32(0..255)\r\n\r\nAfter comparison with similar context in the RFC, I suspect that it\r\nwould be appropriate to use the IsisUnsigned8TC TEXTUAL-CONVENTION\r\nin this place as well:\r\n\r\n isisCircLevelIDOctet OBJECT-TYPE\r\n| SYNTAX IsisUnsigned8TC\r\n\r\n\r\n(3) issue: unexpected indexing\r\n\r\nAs described in the SMIv2 RFCs, RFC 4444 extends various tables\r\nby \"reusing\" of common index objects. Surprisingly, there are\r\ntwo deviations from this practice I cannot detect any reason for:\r\n\r\n(3.1)\r\nThe isisSystemCounterTable (page 39 ff.) is indexed by the fresh,\r\nindependant index object, \"isisSysStatLevel\", while IMHO it would\r\nhave been logical to use the already defined index object of the\r\nisisSysLevelTable (page 25 ff.), \"isisSysLevelIndex\", for this\r\npurpose as well.\r\n\r\n(3.2)\r\nThe isisPacketCounterTable (page 46 ff.) is indexed in the 2nd place\r\nby the fresh, independant index object, \"isisPacketCountLevel\",\r\nwhile IMHO it would have been logical to use the full index structure\r\nof the isisCircLevelTable (page 34 ff.), including the index object,\r\n\"isisCircLevelIndex\" in the second place, for this purpose as well.\r\n\r\n\r\n(4) issue: many unusual UNITS clauses\r\n\r\nThe UNITS clause is intended a to contains a textual definition of\r\nthe units associated with the object (according to RFC 2578, Section\r\n7.2). Network management systems usually provide for narrow label\r\nspace in their display screens - expecting usual [physical] unit\r\nnames like \"bytes\", \"kilobytes\", \"seconds\", \"centiseconds\", \"Mbps\",\r\n\"packets\", \"frames\", \"cells\", \"percent\", etc.\r\n\r\nFor most packet counters, RFC 4444 specifies very unusual, lengthy\r\ntexts in the UNITS clauses that duplicate the text given in the\r\nrespective DESCRIPTION clauses.\r\nThis style should better have been avoided and might be noted as\r\nan issue for any potential future update to RFC 4444.\r\n\r\nFor example, the isisPacketCountCSNP OBJECT-TYPE declaration, on\r\npage 49 :\r\n\r\n isisPacketCountCSNP OBJECT-TYPE\r\n SYNTAX Counter32\r\n| UNITS \"Number of IS-IS CSNP frames seen in this direction at\r\n| this level\"\r\n MAX-ACCESS read-only\r\n STATUS current\r\n DESCRIPTION\r\n \"The number of IS-IS CSNPs seen in this\r\n direction at this level.\"\r\n REFERENCE \"{ISIS.aoi iSISControlPDUsSent (43)}\"\r\n ::= { isisPacketCounterEntry 7 }\r\n\r\nshould perhaps better say:\r\n\r\n isisPacketCountCSNP OBJECT-TYPE\r\n SYNTAX Counter32\r\n| UNITS \"frames\"\r\n MAX-ACCESS read-only\r\n STATUS current\r\n DESCRIPTION\r\n \"The number of IS-IS CSNPs seen in this\r\n direction at this level.\"\r\n REFERENCE \"{ISIS.aoi iSISControlPDUsSent (43)}\"\r\n ::= { isisPacketCounterEntry 7 }\r\n\r\n\r\n(5) errata(?): overly restrictive RowStatus object descriptions\r\n\r\nSome tables with conceptual rows that can be dynamically added\r\nor deleted, contain a control object with SYNTAX RowStatus\r\nand other control objects, e.g. with SYNTAX IsisAdminState.\r\n\r\nI expect that the latter objects have been intended to control\r\nthe activity of \"live\" table rows, without the need to deactivate\r\nthese rows via the RowStatus object before setting the AdminState\r\nto \"on\" or \"off\", so much the more the support for the\r\n'notInServcie' state of the RowStatus objects is explicitely\r\n\"not required\". Therefore, I strongly suspect that some RowStatus\r\nobject DESCRIPTION clauses have unintentionally been worded overly\r\nrestrictive and should been corrected to allow AdminStatus changes.\r\n\r\nSome other such clauses contain statements that are void due to the\r\nlack of accessible objects in those tables they could be applied to.\r\n\r\nI have identified the following instances of these issues:\r\n\r\n(5.3)\r\n\r\nThe DESCRIPTION clause of the isisCircExistState OBJECT-TYPE macro\r\ninstance, on page 31, says:\r\n\r\n DESCRIPTION\r\n \"The existence state of this circuit. Setting the state\r\n to 'notInService' halts the generation and processing of\r\n IS-IS protocol PDUs on this circuit. Setting the state\r\n to destroy will also erase any configuration associated\r\n with the circuit. Support for 'createAndWait' and\r\n 'notInService' is not required.\r\n\r\n| A row entry cannot be modified when the value of this\r\n| object is 'active'.\"\r\n\r\nIt should perhaps instead say:\r\n\r\n DESCRIPTION\r\n \"The existence state of this circuit. Setting the state\r\n to 'notInService' halts the generation and processing of\r\n IS-IS protocol PDUs on this circuit. Setting the state\r\n to destroy will also erase any configuration associated\r\n with the circuit. Support for 'createAndWait' and\r\n 'notInService' is not required.\r\n\r\n| Any other accessible object in this table row, except\r\n| isisCircAdminState, cannot be modified when the value\r\n| of this object is 'active'.\"\r\n\r\n(5.4)\r\n\r\nThe DESCRIPTION clause of the isisRAExistState OBJECT-TYPE macro\r\ninstance, on page 58, says:\r\n\r\n DESCRIPTION\r\n \"The existence state of this Reachable Address. This\r\n object follows the ManualOrAutomatic behaviors. Support\r\n for 'createAndWait' and 'notInService' is not required.\r\n\r\n| A row entry cannot be modified when the value of this\r\n| object is 'active'.\"\r\n\r\nIt should perhaps instead say:\r\n\r\n DESCRIPTION\r\n \"The existence state of this Reachable Address. This\r\n object follows the ManualOrAutomatic behaviors. Support\r\n for 'createAndWait' and 'notInService' is not required.\r\n\r\n| Any other accessible object in this table row, except\r\n| isisRAAdminState, cannot be modified when the value\r\n| of this object is 'active'.\"\r\n\r\n(5.5)\r\n\r\nThe DESCRIPTION clause of the isisIPRAExistState OBJECT-TYPE macro\r\ninstance, on page 65, says:\r\n\r\n DESCRIPTION\r\n \"The state of this IP Reachable Address. This object\r\n follows the ExistenceState and ManualOrAutomatic\r\n behaviors. Support for 'createAndWait' and\r\n 'notInService' is not required.\r\n\r\n| A row entry cannot be modified when the value of this\r\n| object is 'active'.\"\r\n\r\nIt should perhaps instead say:\r\n\r\n DESCRIPTION\r\n \"The state of this IP Reachable Address. This object\r\n follows the ExistenceState and ManualOrAutomatic\r\n behaviors. Support for 'createAndWait' and\r\n 'notInService' is not required.\r\n\r\n| Any other accessible object in this table row, except\r\n| isisIPRAAdminState, cannot be modified when the value\r\n| of this object is 'active'.\"\r\n\r\n\r\n(8) issue: on-the-wire inefficiency in notifications\r\n\r\nWhile admittedly the indexing structure of the MIB tables,\r\nand the resulting lack of suitable accessible objects, apparently has\r\nforced the introduction of the unusual and unusually large collection\r\nof special objects with 'MAX-ACCESS accessible-for-notify'\r\n(on pp. 71..74), some redundancies and inefficiencies in the\r\nobject groupings for notifications remain. Repeatedly, the\r\nnumber of objects could have been reduced by including properly\r\nindexed objects into the notifications object groups instead of\r\nseparate \"special\" objects. But this might have been considered\r\nacceptable for the sake of a consistent object grouping style.\r\n\r\nBut there is one redundancy that could easily have been avoided.\r\nThe isisDatabaseOverload NOTIFICATION-TYPE declaration, on page 74,\r\n\r\n isisDatabaseOverload NOTIFICATION-TYPE\r\n OBJECTS {\r\n isisNotificationSysLevelIndex,\r\n isisSysLevelState\r\n }\r\n\r\nincludes the object, \"isisSysLevelState\", that already carries\r\nthe required SysLevelIndex in the index part of its OID, because\r\nit is contained in the isisSysLevelTable.\r\nTherefore, without any loss of information for the receiver of the\r\nnotification, this declaration could have been simplified to specify:\r\n\r\n isisDatabaseOverload NOTIFICATION-TYPE\r\n OBJECTS {\r\n isisSysLevelState\r\n }", "correct_text": "", "notes": "This Errata Note has been split with some elements moved to EID 3321.\r\n\r\nAll excerpts from the RFC text are taken literally, keeping their\r\noriginal formatting, and modified text is formatted in conformance\r\nwith RFC guidelines again.\r\n\r\nI use change bars ('|' in column 1) and casual up/down pointing\r\ntags ('^^^' / 'vvv' marks in extra lines) to emphasize the location\r\nof textual issues and/or proposed textual enhancements/corrections.\r\n\r\nNaturally, items (3) and (8) cannot be addressed any more\r\n\"after the fact\" (i.e. publication of the RFC), and item (4)\r\nshould be addressed in a future update.\r\n\r\nfrom pending\n --VERIFIER NOTES-- \n(2) Rejected. Too late for this change. No functional effect.\r\n(3) Rejected. This is discussion not errata.\r\n(4) Rejected. Nothing wrong with original text.\r\n(5.3) Rejected. Pointless wordsmithing.\r\n(5.4) Rejected. Pointless wordsmithing.\r\n(5.5) Rejected. Pointless wordsmithing.\r\n(8) Rejected. This is discussion not errata. ", "submit_date": "2006-05-29", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "92", "doc-id": "RFC4433", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5.3.1", "orig_text": " The following table summarizes the behavior of the Assigned HA, based\r\n on the value of the destination IP address and Home Agent field of\r\n the Registration Request.\r\n\r\n Dest IP Addr HA field Processing at Assigned HA\r\n ------------ ------------ ----------------------------------\r\n...\r\n\r\n Table 1: Registration Request Handling at Assigned HA\r\n", "correct_text": " The following table summarizes the behavior of the Requested HA,\r\n based on the value of the destination IP address and the Home Agent\r\n Address field of the Registration Request.\r\n\r\n Dest IP Addr HA field Processing at Requested HA\r\n ------------ ------------ ----------------------------------\r\n...\r\n Table 1: Registration Request Handling at the Requested HA\r\n\r\n", "notes": "According to, e.g., the explanations in bullet 1 of Section 5.3,\r\n\"Assigned HA\" is not correct; the term to be used is \"Requested HA\";\r\nit will eventually become the \"Assigned HA\" if the conditions\r\nmentioned are met, but the behaviour described strictly applies\r\nto the \"Requested HA\" role.\r\n\r\nfrom pending", "submit_date": "2006-11-09", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3322", "doc-id": "RFC5162", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "3.6", "orig_text": "A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command\r\nor because messages were expunged in other connections (i.e., the\r\nVANISHED response without the EARLIER tag) also decrements the number\r\nof messages in the mailbox; it is not necessary for the server to\r\nsend an EXISTS response with the new value. It also decrements\r\nmessage sequence numbers for each successive message in the mailbox\r\n(see the example at the end of this section). Note that a VANISHED\r\nresponse caused by EXPUNGE, UID EXPUNGE, or messages expunged in\r\nother connections SHOULD only contain UIDs for messages expunged\r\nsince the last VANISHED/EXPUNGE response sent for the currently\r\nopened mailbox or since the mailbox was opened. That is, servers\r\nSHOULD NOT send UIDs for previously expunged messages, unless\r\nexplicitly requested to do so by the UID FETCH (VANISHED) command.\r\n\r\nNote that client implementors must take care to properly decrement\r\nthe number of messages in the mailbox even if a server violates this\r\nlast SHOULD or repeats the same UID multiple times in the returned\r\nUID set. In general, this means that a client using this extension\r\nshould either avoid using message numbers entirely, or have a\r\ncomplete mapping of UIDs to message sequence numbers for the selected\r\nmailbox.", "correct_text": "A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command\r\nor because messages were expunged in other connections (i.e., the\r\nVANISHED response without the EARLIER tag) also decrements the number\r\nof messages in the mailbox; it is not necessary for the server to\r\nsend an EXISTS response with the new value. It also decrements\r\nmessage sequence numbers for each successive message in the mailbox\r\n(see the example at the end of this section).\r\n\r\nNote that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or\r\nmessages expunged in other connections MUST only contain UIDs for\r\nmessages expunged since the last VANISHED/EXPUNGE response sent for\r\nthe currently opened mailbox or since the mailbox was opened. That is,\r\nservers MUST NOT send UIDs for previously expunged messages, unless\r\nexplicitly requested to do so by the UID FETCH (VANISHED) command.\r\nThis is required to prevent a possible race condition where new arrivals\r\nfor which the UID is not yet known by the client are expunged.", "notes": "If the servers were allowed to send VANISHED responses referring to non-existing UIDs, there's a possible race condition when new arrivals are expunged. This is due to the sequence-UID assymetry of EXISTS vs. VANISHED.\r\n\r\nNew arrivals are reported through EXISTS and their UIDs are not known to the client. Suppose the following scenario where two messages exist and their UIDs are 10 and 11. Two more messages arrive:\r\n\r\n* 4 EXISTS\r\n* VANISHED 12:20\r\n\r\nThe client has no way of knowing whether the two new arrivals have UIDs falling into the 12:20 range. As such, the client doesn't know whether there are two, three or four messages in the mailbox at this point.\r\n\r\nSee http://mailman2.u.washington.edu/pipermail/imap-protocol/2012-June/001781.html for details.\n --VERIFIER NOTES-- \nThis is a clear change to the intention of the document and is too large a change to be appropriate to an erratum. There is a problem here, but it is more properly handled by new work, which is being undertaken as http://datatracker.ietf.org/doc/draft-kundrat-qresync-arrived/", "submit_date": "2012-08-16", "submitter_name": "Jan Kundr\u00e1t", "verifier_id": "", "verifier_name": "Pete Resnick", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3323", "doc-id": "RFC5162", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "GLOBAL", "orig_text": "The \"ENABLE QRESYNC\"/\"ENABLE QRESYNC CONDSTORE\" command\r\nalso tells the server that it SHOULD start sending VANISHED responses\r\n(see Section 3.6) instead of EXPUNGE responses.", "correct_text": "The \"ENABLE QRESYNC\"/\"ENABLE QRESYNC CONDSTORE\" command\r\nalso tells the server that it MUST start sending VANISHED responses\r\n(see Section 3.6) instead of EXPUNGE responses.", "notes": "The explicit allowance for EXPUNGE being sent instead of VANISHED means that clients still have to maintain a full sequence-to-UID mapping, otherwise there is a risk of losing synchronization. Given that QRESYNC itself is an optional extension, I find it hard to imagine a case where the server cannot send a proper VANISHED response.\r\n\r\nIf this errata gets accepted, it will require rather heavy editing of the document; the notion of EXPUNGE responses being allowed is followed throughout the whole RFC, including the examples.\n --VERIFIER NOTES-- \nThe fact that this is a change to a normative requirement of the document, and (as the notes say) the fact that it would cause extensive changes to the rest of the document, makes it inappropriate as an erratum.", "submit_date": "2012-08-16", "submitter_name": "Jan Kundr\u00e1t", "verifier_id": "", "verifier_name": "Pete Resnick", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "88", "doc-id": "RFC4443", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) text omission ???\r\n\r\nI suspect that something went wrong in the publication process\r\nfor RFC 4443, leading to significant text omission.\r\n\r\nSymptoms:\r\n\r\no Text on top of page 5 apparently *continues* specifications\r\n that are not in the published text;\r\n\r\no Appendix A contains the change item:\r\n\r\n - Added specification that all ICMP error messages shall have exactly\r\n 32 bits of type-specific data, so that receivers can reliably find\r\n the embedded invoking packet even when they don't recognize the\r\n ICMP message Type.\r\n\r\n I could not find any text in the body of the RFC corresponding\r\n to this statement.\r\n\r\nTherefore, I suspect that general specifications for ICMPv6 error\r\nmessages have been dropped inadvertently from the end of Section\r\n2.1, at the bottom of page 4 in the published text, or that even\r\na subsection dealing with the peculiar requirements for ICMPv6\r\nerror messages has been dropped, just leaving in the published text\r\nthe single sentence at top of page 5.\r\n\r\nI expect the missing text to depict the general structure of the\r\nMessage Body of ICMPv6 error messages with all related explanations,\r\naccording to the above mentioned change note.\r\n\r\nAppendix A also states:\r\n\r\n - Removed the general packet format from Section 2.1. It refers to\r\n Sections 3 and 4 for packet formats now.\r\n\r\nThis is not literally true. The general format *is* in Section 2.1.\r\nBut in fact, it would be logical to have the (missing) specifications\r\nfor error messages -- including the 4 lines of test on top of page 5 --\r\nincorporated into (the start of) Section 3 (*before* the heading for\r\nSection 3.1.) instead of the end of Section 2.1.\r\n\r\n\r\n(2) possible textual improvement\r\n\r\nin the lower third of page 3, Section 2.1 says:\r\n\r\n The code field depends on the message type. It is used to create an\r\n additional level of message granularity.\r\n\r\nIt should perhaps better say:\r\n\r\n The code field depends on the message type. It is used to create an\r\n additional level of message type granularity.\r\n ^^^^^^\r\n\r\n(3) reference to old IPsec Architecture document\r\n\r\nSection 5.1, at the bottom of page 15, has been updated to point\r\nto the new IPsec Architecture document, RFC 4301, via the reference\r\ntag [SEC-ARCH]. But immediately below, in the first paragraph of\r\nSection 5.2, on top of page 16, the RFC text says:\r\n\r\n ICMP messages may be subject to various attacks. A complete\r\n discussion can be found in the IP Security Architecture [IPv6-SA].\r\n [...]\r\n\r\nIt remains unclear why the reference is made to the previous IPsec\r\nArchitecture document, RFC 2401, in this case.\r\nIn fact, RFC 4301 has simplified ICMP handling by the introduction\r\nof ICMP Type+Code as a Traffic Selector for the SPD, and therefore\r\ncontains restructured text on ICMP message processing.\r\nNevertheless, as far as I can see, RFC 4301 has not removed\r\nsignificant ICMP security related material from RFC 2401.\r\nThus, IMHO there is no reason to explicitely refer to the obsoleted\r\nspecification, RFC 2401 [IPv6-SA], instead of the current one,\r\nRFC 4301 [SEC-ARCH].\r\n\r\n\r\n(4) more issues with references\r\n\r\nAccording to Appendix A, RFC 4443 has\r\n\r\n - Separated References into Normative and Informative.\r\n\r\nThe latest RFC Authoring Internet draft revisions\r\n(cf. draft-rfc-editor-rfc2223bis-xx\r\n and draft-hoffman-rfc-author-guide-01)\r\nall have included the definition:\r\n Normative references specify documents that must be read\r\n to understand or implement the technology in the document,\r\n or whose technology must be present for the technology in\r\n the new RFC to work. [...] an informative reference might\r\n provide background or historical information to the reader.\r\n [...]\r\n\r\nThe separation performed does not match this definition.\r\n\r\n(4a)\r\nRFC 4443 refers to RFC 792 and RFC 1122 to point out the analogy\r\nto ICMP[v4], but it is a self-contained specification, and ICMPv6\r\ndoes not rely on the implementation of ICMP[v4] -- IPv6 only nodes\r\nare possible and even expected for the (far?) future.\r\nTherefore, the references [RFC-792] and [RFC-1122] should better\r\nhave been placed into section 7.2, Informative References, instead\r\nof Section 7.1, Normative References.\r\n\r\n(4b)\r\nRFC 4443 also lists in Section 7.1, Normative References, the\r\nreference to its obsoleted predecessor, RFC 2463 [RFC-2463].\r\nThis is a fatal lock on the Standards Track for RFC 4443:\r\nRFC 4443 can *not* be advanced above the level of RFC 2463,\r\nif the written procedures are taken literally !\r\n(Also, RFC 4443 contains all material from RFC 2463, and thus\r\nRFC 2463 is not needed to understand and/or implement RFC 4443.)\r\n\r\nTherefore, all references to obsoleted documents should be\r\nnamed Informative, and in the case of RFC 4443, [RFC-2463]\r\nshould have been moved into Section 7.2 as well.\r\n\r\n(4c)\r\nThe old IPv6 Addressing Architecture document, RFC 3513, has been\r\nreplaced by RFC 4291, published more than 5 weeks before RFC 4443.\r\n\r\nTherefore, in Section 7.2 of RFC 4443, the Informative Reference\r\n[IPv6-ADDR] should be have been changed to point to RFC 4291\r\ninstead of the obsolete RFC 3513.\r\n\r\n(4d)\r\nWhen following my recommendations in item (3) above, the\r\nInformative Reference [IPv6-SA] is not needed any more;\r\nits role has been taken over by the Reference [SEC-ARCH].\r\n\r\n\r\n(5) misleading change note\r\n\r\nThe second bulleted item in Appendix A,\r\n\r\n - Corrected typos in Section 2.4, where references to sub-bullet e.2\r\n were supposed to be references to e.3.\r\n\r\napparently is not correct; it must have been introduced in the\r\ndraft history, referring to a change in the draft.\r\nThe references in RFC 2463 to sub-bullet (e.2) were correct.\r\nRFC 4443 has inserted a new item (e.2) into the list, incrementing\r\nthe numbers of the previous sub-bullet (e.2) and all subsequent\r\nsub-bullets, thus making it necessary to increment the references.\r\nPerhaps, the latter had not been done in an early draft revision,\r\nand has then been corrected in a later one.\r\nThus, the above change note should not have been included in RFC 4443.", "correct_text": "", "notes": "from pending", "submit_date": "2006-04-19", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "89", "doc-id": "RFC4439", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "\r\nThe DESCRIPTION clause for the\r\nt11FamAutoReconfigure OBJECT-TYPE macro invocation says:", "orig_text": " If value of this object is 'true', the switch will\r\n send an RCF (ReConfigureFabric) to rebuild the\r\n Fabric.", "correct_text": " If the value of this object is 'true', the switch will\r\n send an RCF (ReConfigureFabric) to rebuild the\r\n Fabric.\r\n", "notes": "", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "90", "doc-id": "RFC4438", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "The DESCRIPTION clause of the t11NsRegClassOfSvc OBJECT-TYPE,on page 16/17, says:", "orig_text": " \"The class of service indicator. This object is an\r\n array of bits that contain a bit map of the classes of\r\n service supported by the associated port. If a bit in\r\n this object is 1, it indicates that the class of\r\n service is supported by the associated port. When a\r\n bit is set to 0, it indicates that no class of service\r\n is supported by this Nx_Port.\r\n\r\n If this object has not been not registered for a port,\r\n then the instance for that port is not instantiated.\"", "correct_text": " \"The class of service indicator. This object is an\r\n array of bits that contain a bit map of the classes of\r\n service supported by the associated port. If a bit in\r\n this object is 1, it indicates that the class of\r\n service is supported by the associated port. When all\r\n bits are set to 0, it indicates that no class of\r\n service is supported by this Nx_Port.\r\n\r\n If this object has not been registered for a port,\r\n then the instance for that port is not instantiated.\"\r\n", "notes": "", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Keith McCloghrie", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "91", "doc-id": "RFC4436", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1.1", "orig_text": " If a valid ARP Reply is received, the MAC address in the sender\n hardware address field (ar$sha) in the ARP Reply is matched against\n the target hardware address field (ar$tpa) in the ARP Request, and\n the IPv4 address in the sender protocol address field (ar$spa) of the\n ARP Reply is matched against the target protocol address field\n (ar$tpa) in the ARP Request. If a match is found, then the host\n continues to use that IPv4 address, subject to the lease re-\n acquisition and expiration behavior described in Section 4.4.5 of the\n DHCP specification [RFC2131].", "correct_text": " If a valid ARP Reply is received, where:\n \n (a) the address in the sender hardware address field (ar$sha) is\n the MAC address of the node being tested for, and\n (b) the address in the sender protocol address field (ar$spa) is\n the IPv4 address of the node being tested for,\n \n then the host concludes that its candidate IPv4 address is valid\n for this network and may continue to be used, subject to the lease\n re-acquisition and expiration behavior described in Section 4.4.5\n of the DHCP specification [RFC2131].\n", "notes": "", "submit_date": "2007-01-01", "submitter_name": "Bernard Aboba", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "7016", "doc-id": "RFC7839", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.4.1", "orig_text": " Length\r\n 4\r\n\r\n Operator-Identifier\r\n The Operator-Identifier is a variable-length Private Enterprise\r\n Number (PEN) ...", "correct_text": " Length\r\n 4\r\n\r\n Operator-Identifier\r\n The Operator-Identifier is a 32-bit Private Enterprise\r\n Number (PEN) ...", "notes": "Either the length is 4, and the contents are 32-bits. Or the length is >1, and the length is variable.\r\n\r\nMy guess is that the intention is to have a fixed length. The variable-length encoding from RFC 6757 is likely not needed here.\r\n\r\n\r\n*** verifier note ***\r\nSee Bernie Volz's reply in https://mailarchive.ietf.org/arch/msg/dhcwg/Y4yaYwaqxS0B2nWw5f4xER2fSMk/", "submit_date": "2022-07-07", "submitter_name": "Alan DeKok", "verifier_id": "", "verifier_name": "Eric Vyncke", "update_date": "2022-07-12 12:31:43"}, {"errata_id": "8119", "doc-id": "RFC7707", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.1.1.1", "orig_text": "1. The \"Universal\" bit (bit 6, from left to right) of the address is \r\nset to 1.", "correct_text": "1. The \"Universal\" bit (bit 7, from left to right) of the address is \r\nset to 1.", "notes": "The \"Universal\" bit is the bit #7 and not the bit #6.\n --VERIFIER NOTES-- \n Per https://mailarchive.ietf.org/arch/msg/opsec/Qjj4KSQ-xFy7ZjPCwHTM_jiJKj4/", "submit_date": "2024-09-24", "submitter_name": "Anvar Durmanov", "verifier_id": "", "verifier_name": "Mohamed Boucadair", "update_date": "2025-03-28 17:46:31"}, {"errata_id": "96", "doc-id": "RFC4425", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nInformative References say:", "orig_text": " [14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,\r\n \"SIP: Session Initiation Protocol\", RFC 2543, March 1999.", "correct_text": " [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., \r\n Sparks, R., Handley, M., and E. Schooler, \"SIP: Session Initiation \r\n Protocol\", RFC 3261, June 2002.", "notes": "\r\nInformative reference points to RFC 2543, but this has been outdated by RFC 3261.\r\nRFC 4425 gives an Informative Reference [14] to the SIP\r\nspecification, used only once, in section 4.7; but the\r\ncitation in section 10.2 points to the far outdated RFC 2543\r\nthat has been superseded by RFC 3261 on Jul 2 2002.\r\nBecause this obsolescence has happened so long ago, I have\r\nconjectured that it must have been ignored purposely following\r\nsubtle considerations, and it is not an editorial oversight.", "submit_date": "2006-03-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "97", "doc-id": "RFC4410", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) [contradiction in specification]\r\n\r\nThe last paragraph of Section 2, on page 6 of RFC 4410, says:\r\n\r\n SRMP is intended for general use under applications that need its\r\n vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv\r\n| services and may exist in parallel instances on the same host. The\r\n UDP port is therefore established ad hoc from available application\r\n ports; accordingly, it would not be appropriate to have a well-known\r\n port for SRMP.\r\n\r\nContrary to that, the first paragraph of Section 4.7, on page 15,\r\nsays:\r\n vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv\r\n| Each host will have a single instance of SRMP supporting all of its\r\n applications. Thus, the sender's source rate is the sum of the rates\r\n of all the clients of the same multicast group.\r\n\r\nWhat's true ? What's been intended ???\r\n\r\n\r\n(2) [simple erratum: inconsistent spelling]\r\n\r\nAt the bottom of page 7, Section 3.2 says:\r\n\r\n Receiver_Timestamp:\r\n| 16 bits Echo of the Receiver_Time_Stamp field (in milliseconds)\r\n of the receiver feedback message. If the sender has\r\n time delay between receiving the feedback and echoing\r\n the timestamp, it MUST adjust the Receiver_Timestamp\r\n value to compensate.\r\n\r\nTo adjust with the diagram on top of page 7 and the remainder of the\r\ntext, 'Receiver_Time_Stamp' should be spelled out 'Receiver_Timestamp'\r\nhere as well.\r\nThus, the RFC should say:\r\n\r\n Receiver_Timestamp:\r\n| 16 bits Echo of the Receiver_Timestamp field (in milliseconds)\r\n of the receiver feedback message. If the sender has\r\n time delay between receiving the feedback and echoing\r\n the timestamp, it MUST adjust the Receiver_Timestamp\r\n value to compensate.\r\n\r\n\r\n(3) [inconsistent message layout - danger of interoperability problems]\r\n\r\nThe diagram of the Bundle Header Format (Section 3.2, on page 7),\r\n\r\n 0 8 16 24 32\r\n +--------------+--------------+--------------+--------------+\r\n |Version| Type |fb_nr | flag | bundle_SN |\r\n +--------------+--------------+--------------+--------------+\r\n | Sender_ID |\r\n +--------------+--------------+--------------+--------------+\r\n | Receiver_ID |\r\n +--------------+--------------+--------------+--------------+\r\n | Sender_Timestamp | Receiver_Timestamp |\r\n +--------------+--------------+--------------+--------------+\r\n | ... |\r\n\r\n\r\nand the diagram of the Feedback Message Format (Section 3.3, on page 9),\r\n\r\n 0 8 16 24 32\r\n +--------------+--------------+--------------+--------------+\r\n |Version| Type | fb_nr| flag | X_r |\r\n +--------------+--------------+--------------+--------------+\r\n | Sender_Timestamp | Receiver_Timestamp |\r\n +--------------+--------------+--------------+--------------+\r\n | Sender_ID |\r\n +--------------+--------------+--------------+--------------+\r\n | Receiver_ID |\r\n +--------------+--------------+--------------+--------------+\r\n\r\nshow a surprising inconsistency in the order of the (otherwise\r\ncomparable) words {Sender_ID, Receiver_ID, S/R_Timestamps} .\r\nI suspect that this might give rise to implementation faults,\r\nleading to interoperability problems.\r\nIt better would have been avoided from the beginning by using\r\nthe same order of the fields.\r\n\r\nBTW: It strikes that in Section 3.2, the sequence of the field\r\nexplanations does not agree with the order in the diagram (as is\r\nthe case throughout the remainder of the RFC); instead, the\r\nexplanations of just those four fields is given in the order\r\nof the diagram and explanation sequence in Section 3.3.\r\nTherefore, the reader could be lead to the conjecture that the\r\ndiagram in Section 3.2 is in error and in fact should be aligned\r\nwith the diagram in Section 3.3.\r\n\r\n\r\n(4) [simple erratum: word twister]\r\n\r\nIn Section 3.6, near the top of page 12, the RFC says:\r\n\r\n Length:\r\n 16 bits Length of the payload data in octets (does not the\r\n include header).\r\n\r\nIt should say:\r\n\r\n Length:\r\n| 16 bits Length of the payload data in octets (does not include\r\n| the header).\r\n\r\n\r\n(5) [simple errata: inconsistent terminology]\r\n\r\nContrary to the remainder of the RFC text, Section 3.7 uses the\r\nfield name \"Sender Address\". To avoid the unfortunate embedded\r\nspace character, and to align this section with the remainder\r\nof the RFC, the term \"Sender_ID\" should be used.\r\nTherefore:\r\n\r\na) the diagram on page 12,\r\n\r\n 0 8 16 24 32\r\n +--------------+--------------+--------------+--------------+\r\n |Version| Type |111 | 00000 | reserved |\r\n +--------------+--------------+--------------+--------------+\r\n | DSN |\r\n +--------------+--------------+--------------+--------------+\r\n| | Sender Address |\r\n +--------------+--------------+--------------+--------------+\r\n\r\nshould be corrected to say:\r\n\r\n 0 8 16 24 32\r\n +--------------+--------------+--------------+--------------+\r\n |Version| Type |111 | 00000 | reserved |\r\n +--------------+--------------+--------------+--------------+\r\n | DSN |\r\n +--------------+--------------+--------------+--------------+\r\n| | Sender_ID |\r\n +--------------+--------------+--------------+--------------+\r\n\r\nb) the explanation (at the bottom of page 12),\r\n\r\n| Sender_ID:\r\n| The IP address of the sender of the message being NACKed.\r\n\r\nshould be corrected to say:\r\n\r\n| Sender_ID:\r\n| The ID of the sender of the message being NACKed.\r\n\r\nSee also item (6) below for the full rationale.\r\n\r\n\r\n(6) [incomplete specification - IPv4-centric]\r\n\r\nIn Section 4.2, the second paragraph on page 14 says:\r\n\r\n Also, the bundle length MUST NOT exceed LENGTH_MAX. If adding a new\r\n SRMP message will produce a greater length, the SRMP daemon MUST\r\n initialize a new bundle for the new SRMP messages, and the current\r\n| bundle should be transmitted immediately. The recommended value for\r\n| LENGTH_MAX is 1454 bytes (Ethernet MTU minus IP and UDP header\r\n| lengths).\r\n\r\nSimilarly, the first paragraph of Section 4.6, on page 15, says:\r\n\r\n TFMCC is designed for traffic with a fixed message size. The maximum\r\n| bundle size (including header) for SRMP is set to a configurable\r\n| maximum, typically 1454 bytes (Ethernet MTU minus IP and UDP header\r\n| lengths). The bundle size will be used in a TCP throughput equation,\r\n to get a desired source rate. However, in SRMP, the message size is\r\n variable because:\r\n\r\nWithout mention, the marked phrases are strictly IPv4-centric;\r\nthey do not apply to the case of IPv6.\r\n\r\nThe latter scenario is not excluded in the text, and the phrase,\r\n\"IPv4 addresses may be used.\" in the description of all Sender_ID\r\nand Receiver_ID fields supports the suspicion that IPv6 in fact\r\nwas intended to be supported.\r\n\r\nPlease supply improved wording for both text fragments.\r\n\r\n\r\n(7) [simple erratum: grammar (singular/plural mismatch)]\r\n\r\nThe first paragraph of Section 5, on page 17, says:\r\n\r\n SRMP operates in three distinct transmission modes in order to\r\n deliver varying levels of reliability: Mode 0 for multicast data that\r\n| does not require reliable transmission, Mode 1 for data that must be\r\n received reliably by all members of a multicast group, and Mode 2 for\r\n data that must be received reliably by a single dynamically\r\n determined member of a multicast group.\r\n\r\nIt should say:\r\n\r\n SRMP operates in three distinct transmission modes in order to\r\n deliver varying levels of reliability: Mode 0 for multicast data that\r\n| do not require reliable transmission, Mode 1 for data that must be\r\n received reliably by all members of a multicast group, and Mode 2 for\r\n data that must be received reliably by a single dynamically\r\n determined member of a multicast group.\r\n\r\nRationale: \"data\" *is\" plural.\r\n", "correct_text": "", "notes": "from pending", "submit_date": "2006-08-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Wes Eddy", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "98", "doc-id": "RFC4409", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "Issues with References:\r\n\r\na) Section 12 of RFC 4409 contains the entry:\r\n\r\n [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E.,\r\n and D. Crocker, \"SMTP Service Extensions\", STD 10,\r\n RFC 1869, November 1995.\r\n\r\n `STD 10` in fact should be `(ex) STD 10` according to rfcxx00.txt .\r\n The material from RFC 1869 has been incorporated into RFC 2821,\r\n and RFC 1869 has been reclassified to Historic.\r\n\r\n Therefore, this reference should not have been listed as a\r\n Normative Reference. The Ref. to RFC 2821 in fact catches all.\r\n\r\n\r\n Section 12 of RFC 4409, under [SMTP-MTA] also contains the entry:\r\n\r\n Partridge, C., \"Mail routing and the domain\r\n system\", STD 10, RFC 974, January 1986.\r\n\r\n `STD 10` in fact should better have been `(ex) STD 14` --\r\n rfcxx00.txt says: \"Now Historic.\" ^^\r\n\r\n The non-obsolete material from RFC 974 has been incorporated\r\n into RFC 2821 and RFC 974 has been reclassified as Historic.\r\n\r\n Therefore, this reference should not have been listed as a\r\n Normative Reference. The Ref. to RFC 2821 in fact catches all.\r\n\r\n\r\n Finally, the subsequent entry,\r\n\r\n Braden, R., \"Requirements for Internet Hosts -\r\n Application and Support\", STD 3, RFC 1123, October\r\n 1989.\r\n\r\n also is not needed any more, because the SMTP related material\r\n in RFC 1123 has been revised and incorporated into RFC 2821\r\n as well. The Ref. to RFC 2821 in fact catches all.\r\n\r\n\r\nb) Section 13 of RFC 4409, under [MESSAGE-FORMAT] contains the entry:\r\n\r\n Braden, R., \"Requirements for Internet Hosts -\r\n Application and Support\", STD 3, RFC 1123, October\r\n 1989.\r\n\r\n Similarly to the last item above, the IMF related material from\r\n RFC 1233 has been revised and incorporated into RFC 2822; thus\r\n this Ref. is not really needed any more.\r\n The Ref. to RFC 2822 in fact catches all.\r\n\r\n\r\nc) Section 13 of RFC 4409 contains the entry:\r\n\r\n [IPSEC] Kent, S. and R. Atkinson, \"Security Architecture\r\n for the Internet Protocol\", RFC 2401, November\r\n 1998.\r\n\r\n This Ref. was already outdated at the time of publication of\r\n RFC 4409; it should point to the current IPSEC Architecture\r\n document, RFC 4301 !\r\n\r\n BTW:\r\n This apparently is a `viral` legacy issue -- RFC 2476 also\r\n contained an outdated Ref., to the predecessor of RFC 2401 !", "correct_text": "", "notes": "", "submit_date": "2006-05-16", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "99", "doc-id": "RFC4408", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "1) On page 1, in the IESG notes, \"aParticipants\" should be\r\n \"Participants\".\r\n\r\n2) On page 40, the US-ASCII normative reference has an incorrectly\r\n indented second paragraph. Instead of:\r\n\r\n [US-ASCII] American National Standards Institute (formerly United\r\n States of America Standards Institute), \"USA Code for\r\n Information Interchange, X3.4\", 1968.\r\n\r\n ANSI X3.4-1968 has been replaced by newer versions with slight\r\n modifications, but the 1968 version remains definitive for\r\n the Internet.\r\n\r\n it should be:\r\n\r\n [US-ASCII] American National Standards Institute (formerly United\r\n States of America Standards Institute), \"USA Code for\r\n Information Interchange, X3.4\", 1968.\r\n\r\n ANSI X3.4-1968 has been replaced by newer versions with\r\n slight modifications, but the 1968 version remains\r\n definitive for the Internet.", "correct_text": "", "notes": "", "submit_date": "2006-05-16", "submitter_name": "Wayne Schlitt", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "100", "doc-id": "RFC4407", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1)\r\nOn page 3 of RFC 4407, the third paragraph,\r\n\r\n Note that the results of this algorithm are only as truthful as the\r\n headers contained in the message; if a message contains fraudulent or\r\n incorrect headers, this algorithm will yield an incorrect result.\r\n [...]\r\n\r\nshould say:\r\n\r\n Note that the results of this algorithm are only as truthful as the\r\n| header fields contained in the message; if a message contains\r\n| fraudulent or incorrect header fields, this algorithm will yield an\r\n incorrect result.\r\n [...]\r\n\r\n\r\n(2)\r\nOn page 3, the first sentence in Section 2,\r\n\r\n The PRA of a message is determined by the following algorithm:\r\n\r\nshould say more precisely:\r\n\r\n The PRA of a message is determined by the following algorithm,\r\n applied to the message header (i.e., the first mail header within\r\n the message, in case of a MIME message):\r\n\r\n\r\n(3)\r\nSubsequently, within the description of the six steps of the\r\nalgorithm (on page 3/4), the term `header` should always be replaced\r\nby `header field`, and `headers` should always be replaced by\r\n`header fields` (total of 16 occurrences).\r\n\r\n\r\n(4)\r\nOn page 4 (just below the emumerated algorithm steps), the paragraph,\r\n\r\n For the purposes of this algorithm, a header field is \"non-empty\" if\r\n and only if it contains any non-whitespace characters. Header fields\r\n that are otherwise relevant but contain only whitespace are ignored\r\n and treated as if they were not present.\r\n\r\nshould say:\r\n\r\n For the purposes of this algorithm, a header field is \"non-empty\" if\r\n| and only if its body contains any non-whitespace characters. Header\r\n| fields that are otherwise relevant but contain only whitespace bodies\r\n are ignored and treated as if they were not present.\r\n\r\n(5)\r\nImmediately following the paragraph mentioned above in item (4), still\r\non page 4, the substitutions from item (3) above should be applied to\r\nthe next two paragraphs and the last paragraph of Section 2 as well\r\n(total of 8 occurrences).\r\n\r\n\r\n(6)\r\nOn page 5, the first paragraph of section 3,\r\n\r\n The PRA, as described by this document, is extracted from message\r\n headers that have historically not been verified. Thus, anyone using\r\n the PRA for any purpose MUST be aware that the headers from which it\r\n is derived might be fraudulent, malicious, malformed, and/or\r\n incorrect. [...]\r\n\r\nshould say (apply item (3) above twice):\r\n\r\n The PRA, as described by this document, is extracted from message\r\n| header fields that have historically not been verified. Thus, anyone\r\n| using the PRA for any purpose MUST be aware that the header fields\r\n from which it is derived might be fraudulent, malicious, malformed,\r\n and/or incorrect. [...]\r\n\r\nand the second paragraph of Section 3,\r\n\r\n A message's PRA will often be extracted from a header field that is\r\n not normally displayed by existing mail user agent software. If the\r\n PRA is used as part of a mechanism to authenticate the message's\r\n origin, the message SHOULD NOT be displayed with an indication of its\r\n authenticity (positive or negative) without the PRA header field also\r\n being displayed.\r\n\r\nshould say:\r\n\r\n A message's PRA will often be extracted from a header field that is\r\n not normally displayed by existing mail user agent software. If the\r\n PRA is used as part of a mechanism to authenticate the message's\r\n origin, the message SHOULD NOT be displayed with an indication of its\r\n| authenticity (positive or negative) without the PRA header field body\r\n also being displayed.", "correct_text": "", "notes": "The RFC adds to the trouble of mis-used\r\nterminology from the Internet Message Format (IMF) framework;\r\nit repeatedly confuses the precisely defined terms, 'header',\r\n'header field', and 'header field body'.\r\n\r\nThe most recent summary of the IETF standardized IMF terminology\r\n(from RFC 2822 et al.) can be found on page 3 of RFC 4249:\r\n\r\n\r\n 3.1.1. Standard Terminology\r\n\r\n Terms related to the Internet Message Format are defined in\r\n [N2.RFC2822]. Authors specifying extension header fields should use\r\n the same terms in the same manner in order to provide clarity and\r\n* avoid confusion. For example, a \"header\" [I1.FYI18], [N2.RFC2822] is\r\n* comprised of \"header fields\", each of which has a \"field name\" and\r\n* usually has a \"field body\". Each message may have multiple\r\n* \"headers\", viz. a message header and MIME-part [N4.RFC2046] headers.\r\n\r\n* A message header has a Date header field (i.e., a field with field\r\n* name \"Date\"). However, there is no \"Date header\"; use of such non-\r\n* standard terms is likely to lead to confusion, possibly resulting in\r\n* interoperability failures of implementations.\r\n\r\n\r\nFor details, see Sections 2.1 and 2.2 of RFC 2822 and other places.\r\nI also recommend the terminology sections in RFC 4021 and RFC 3864.\r\n\r\nfrom pending", "submit_date": "2006-05-16", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "101", "doc-id": "RFC4404", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1", "orig_text": " The FCIP Entity table contains information about this entity's\r\n existing instances of FCIP entities.", "correct_text": " The FCIP Entity table contains information about this device's\r\n existing instances of FCIP entities.", "notes": "The present text is almost recursive nonsense.\r\n* Section 2. explains the terminology.\r\n* The DESCRIPTION clause of the fcipEntityInstanceTable OBJECT-TYPE\r\n definition (on page 9) correctly states:\r\n\r\n \"Information about this FCIP device's existing instances of\r\n FCIP entities.\"\r\n ^^^^^^\r\n\r\nfrom pending", "submit_date": "2006-03-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "102", "doc-id": "RFC4396", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.1.4", "orig_text": "For TYPE 3 units containing the last (trailing) modifier fragment,...", "correct_text": "For TYPE 3 units containing the complete modifiers,...", "notes": "from pending", "submit_date": "2006-03-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "122", "doc-id": "RFC4334", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "(1)\r\n\r\nIn the 3rd paragraph of section 1, on page 2 RFC 4334 says:\r\n\r\n For example, the same wireless station might use IEEE 802.1X to\r\n authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11\r\n \"hotspot.\" [...]\r\n ^^\r\nThe syntax error of that sentence should be corrected to say:\r\n\r\n For example, the same wireless station might use IEEE 802.1X to\r\n authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11\r\n| \"hotspot\". [...]\r\n ^^\r\n\r\n(2)\r\n\r\nAt the end of the 2nd paragraph of section 5, on page 6, the RFC says:\r\n\r\n [...]. Whenever this SSID disclosure is a\r\n concern, different peer certificates ought to be used for the each\r\n WLAN.\r\n ^^^^^^^^^^^^\r\nIt should say:\r\n\r\n [...]. Whenever this SSID disclosure is a\r\n| concern, different peer certificates ought to be used for each WLAN.\r\n\r\n\r\n(3)\r\n\r\nIn Section 7.1, on page 7, the Normative Reference,\r\n\r\n vvv\r\n [EAP] Aboba, B., Blunk, L., Vollbrechtand, J., Carlson, J.,\r\n and H. Levkowetz, \"Extensible Authentication Protocol\r\n (EAP)\", RFC 3748, June 2004.\r\n\r\nshould say:\r\n\r\n| [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and\r\n| H. Levkowetz, Ed., \"Extensible Authentication Protocol\r\n (EAP)\", RFC 3748, June 2004.\r\n\r\nand on page 8, the Normative Reference,\r\n\r\n v\r\n [X.690] ITU-T Recommendation X.660 Information Technology - ASN.1\r\n encoding rules: Specification of Basic Encoding Rules\r\n (BER), Canonical Encoding Rules (CER) and Distinguished\r\n Encoding Rules (DER), 1997.\r\n\r\nshould say:\r\n v\r\n| [X.690] ITU-T Recommendation X.690 Information Technology - ASN.1\r\n encoding rules: Specification of Basic Encoding Rules\r\n (BER), Canonical Encoding Rules (CER) and Distinguished\r\n Encoding Rules (DER), 1997.", "correct_text": "", "notes": " * The minor item (1) is included for completeness.\r\n * Items (1) and (2) are inherited from RFC 3770. \r\n\r\nfrom pending", "submit_date": "2006-03-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "383", "doc-id": "RFC2813", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.3", "orig_text": " The presence of a prefix is indicated with a single leading ASCII\r\n colon character (':', 0x3b), which MUST be the first character of the\r\n ^^^^\r\n message itself.", "correct_text": " The presence of a prefix is indicated with a single leading ASCII\r\n colon character (':', 0x3a), which MUST be the first character of the\r\n ^^^^\r\n message itself.\r\n", "notes": "", "submit_date": "2006-08-28", "submitter_name": "Huang Xiangkui", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "103", "doc-id": "RFC4389", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) typo??\r\n\r\nThe last paragraph of section 5 of RFC 4389, on page 12, says:\r\n\r\n A receives this NA, processing it as usual. Hence it creates a\r\n neighbor entry for B on interface 2 in the REACHABLE state and\r\n records the link-layer address p1.\r\n\r\nSince the packet described has been sent out by node P, on its\r\ninterface '1', to node A, and A has only a single interface\r\ninvolved in the scenarion, with link layer address 'a' (as explained\r\nat the beginning of section 5), \"on interface 2\" is improper in the\r\nsnippit above. (This may be the result of incomplete adaptation\r\nafter a copy-and-paste operation.) A minimal correction to resolve\r\nthis issue might be to name the receive interface by its link layer\r\naddress, hence changing the text above to say:\r\n\r\n A receives this NA, processing it as usual. Hence it creates a\r\n neighbor entry for B on interface 'a' in the REACHABLE state and\r\n records the link-layer address p1.\r\n\r\nor alternatively, more detailed:\r\n\r\n A receives this NA, processing it as usual. Hence it creates a\r\n neighbor entry for B on the interface with link layer address 'a'\r\n in the REACHABLE state and records the link-layer address p1.\r\n\r\n\r\n(2) typo!\r\n\r\nThe 3rd paragraph of Section 9, on page 13, says:\r\n\r\n This document does not introduce any new mechanisms for the\r\n protection of proxy Neighbor Discovery. That is, it does not provide\r\n a mechanism from authorizing certain devices to act as proxies, and\r\n it does not provide extensions to SEND to make it possible to use\r\n both SEND and proxies at the same time. [...]\r\n\r\nIt should perhaps better say ( applying 's/from/for/' ) :\r\n\r\n This document does not introduce any new mechanisms for the\r\n protection of proxy Neighbor Discovery. That is, it does not provide\r\n| a mechanism for authorizing certain devices to act as proxies, and\r\n it does not provide extensions to SEND to make it possible to use\r\n both SEND and proxies at the same time. [...]\r\n\r\n\r\n(3) outdated reference\r\n\r\nIn Section 11, Normative References, RFC 4389 contains the entry\r\n(on page 14) [ICMPv6], pointing to RFC 2463.\r\nBut exactly 3 weeks before RFC 4389, RFC 4443 has been published\r\nobsoleting and replacing RFC 2463. Hence that entry should have\r\nbeen updated to properly point to RFC 4443 instead.\r\n\r\n\r\nIf you agree with my 'diagnosis', I recommend that you submit an\r\nAuthor's Errata Note for RFC 4389 covering the three issues\r\nlisted above. But if you prefer, I can instead submit an Errata\r\nNote on my own, with your consent mailed to the RFC-Editor.", "correct_text": "", "notes": "from pending", "submit_date": "2006-04-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "104", "doc-id": "RFC4388", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.2", "orig_text": "(1) [word omission]\r\n\r\nThe second paragraph of section 4.2 of RFC 4388 says:\r\n\r\n The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering\r\n and troubleshooting activities at large DHCP installations, and is\r\n primarily intended as a method of gathering performance statistics\r\n about servers the load presented to them.\r\n\r\nIt should perhaps better say:\r\n\r\n The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering\r\n and troubleshooting activities at large DHCP installations, and is\r\n primarily intended as a method of gathering performance statistics\r\n| about servers and the load presented to them.\r\n ^^^^^\r\n\r\n\r\n(2) [improper wording]\r\n\r\nRFC 4388 repeatedly talks about\r\n\r\n \"[an] IP address most recently accessed by a client\"\r\n ^^^^^^^^^^^\r\nwhere, IMHO, it should talk about\r\n\r\n| \"[an] IP address most recently assigned to a client\"\r\n ^^^^^^^^^^^\r\nRationale:\r\n The client may access any IP address at any time. Such access\r\n is mostly unrelated to the protocol described in RFC 4338.\r\n\r\nThe affected places in the text I found are:\r\n- Section 5, first paragraph of both the second and the third\r\n bulleted items, on page 10 / 11, respectively;\r\n- Last paragraph on page 17 (within section 6.4.1).\r\n\r\n\r\n(3) [incomplete specification]\r\n\r\nThe second paragraph of Section 6.4.1, on page 17, says:\r\n\r\n In the event that an IP address appears in the \"ciaddr\" field of a\r\n DHCPLEASEQUERY message, if that IP address is one managed by the DHCP\r\n server, then that IP address MUST be set in the \"ciaddr\" field of a\r\n DHCPLEASEUNASSIGNED message.\r\n\r\nIt should in fact say:\r\n\r\n In the event that an IP address appears in the \"ciaddr\" field of a\r\n DHCPLEASEQUERY message, if that IP address is one managed by the DHCP\r\n server, then that IP address MUST be set in the \"ciaddr\" field of a\r\n| DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message returned.\r\n ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^\r\n\r\nRationale:\r\n From the remaining text, it can be inferred that the \"ciaddr\"\r\n field from the DHCPLEASEQUERY message should be copied to an\r\n DHCPRELEASEACTIVE reply message as well -- cf. section 6.4.2.\r\n\r\nIMHO, this copy should be performed generally, i.e. also in the case\r\ndescribed by the subsequent paragraph:\r\n\r\n If the IP address is not managed by the DHCP server, then a\r\n DHCPLEASEUNKNOWN message must be returned.\r\n\r\nthat therefore might be amended to say:\r\n\r\n If the IP address is not managed by the DHCP server, then a\r\n| DHCPLEASEUNKNOWN message MUST be returned, with that IP address\r\n| set in the \"ciaddr\" field.\r\n\r\n[The original 'must' should be a 'MUST' because the alternatives\r\nare also specified as a 'MUST' -- or else the specification would\r\nbe incomplete.]\r\n\r\nTaken together, it might be preferable to restate this fact by\r\nonly changing the first paragraph cited above as follows, and leave\r\nthe second paragraph unchanged with the exception of the 'must':\r\n\r\n In the event that an IP address appears in the \"ciaddr\" field of a\r\n| DHCPLEASEQUERY message, then that IP address MUST be set in the\r\n| \"ciaddr\" field of any reply returned.\r\n\r\n| If that IP address is one managed by the DHCP server, then it MUST\r\n| reply with a DHCPRELEASEACTIVE or DHCPLEASEUNASSIGNED message.\r\n\r\n If the IP address is not managed by the DHCP server, then a\r\n| DHCPLEASEUNKNOWN message MUST be returned.\r\n\r\nPlease comment on which alternative you prefer.", "correct_text": "", "notes": "This errata has been split to 3517 and 3518.\r\n\r\nVerified status applies only to item (1).", "submit_date": "2006-03-02", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "105", "doc-id": "RFC4368", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2", "orig_text": " C-FR RFC 3034 defines a label-switching-controlled Frame Relay\r\n (LC-FR) interface. Packets traversing such an interface carry\r\n labels in the DLCI field\r\n\r\n C-ATM RFC 3035 defines a label-switching-controlled ATM (LC-ATM)\r\n interface as an ATM interface controlled by the label switching\r\n control component. ", "correct_text": " LC-FR\r\n RFC 3034 defines a label-switching-controlled Frame Relay\r\n (LC-FR) interface. Packets traversing such an interface carry\r\n labels in the DLCI field\r\n\r\n LC-ATM\r\n RFC 3035 defines a label-switching-controlled ATM (LC-ATM)\r\n interface as an ATM interface controlled by the label switching\r\n control component. ", "notes": "The acronyms, \"C-FR\" and \"C-ATM\", do not appear elsewhere in the text.\r\nApparently, the first column has been cut off.", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "106", "doc-id": "RFC4384", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1)\r\n\r\nRFC 4384, in the table legend on page 6, and in Section 6,\r\nat the bottom of page 9, refers to ISO 3166-2 for numeric\r\ncountry codes. This is not correct.\r\n\r\nISO 3166-2 specifies codes for *subdivisions* of countries,\r\ne.g. the States of the U.S.A., or the provinces of Canada.\r\n\r\nThe numeric Country Codes apparently used in RFC 4384 in fact\r\nare defined and maintained as a part of ISO 3166-1 !\r\nThat Standard contains 3 tables: 2-character, 3-character,\r\nand numeric Country Codes. Unfortunately, only the first\r\ntable (also used for ccTLDs in the DNS) is made publicly\r\n(online) available by ISO; apparently this has generally\r\nraised the impression that ISO 3166-1 just comprised that\r\nsingle table. (This might have been the background for\r\nmentioning ISO 3166-2 in the RFC.)\r\n\r\nISO certainly would appreciate if many people bought the\r\nISO 3166-2 database when looking for the numeric country\r\ncodes, but probably neither ISOC/IETF nor the RFC author\r\nwould be participating in such earnings of ISO :-)\r\n\r\nTherefore, I propose to correct this flaw by means of an\r\nRFC Errata Note, as follows:\r\n\r\n\r\nRFC 4384, on mid-page 6, says:\r\n\r\n is the 10-bit ISO-3166-2 country code [ISO3166]\r\n\r\nWhere it should say:\r\n\r\n is the 10-bit ISO-3166-1 country code [ISO3166]\r\n ^^^\r\n\r\nAccordingly, the final sentence of Section 6, on page 9,\r\nsaying:\r\n\r\n [...]. Henk Uijterwaal suggested the use\r\n of the ISO-3166-2 country codes.\r\n\r\nshould say:\r\n\r\n [...]. Henk Uijterwaal suggested the use\r\n of the ISO-3166-1 numeric country codes.\r\n ^^^^^^^^^\r\n\r\n\r\n(2)\r\n\r\nAccording to the explanation in Section 3 (page 5), the \r\nfiled is 16 bit wide, and the last sentence on page 5 in Section 4\r\nemphasized the split format \":\". (The references to\r\n in section 4.1 are consistent with that terminology.)\r\n\r\nTherefore, in the table on page 6, the \":\" leaders in the\r\ncolumn titled \"Value\" are inappropriate.\r\nPerhaps, a 'minimally invasive' correction should modify the\r\nheadline, not the table entries:\r\n\r\nThe headline of the table on page 6,\r\n\r\n Category Value\r\n\r\nshould say:\r\n\r\n Category :\r\n\r\n\r\n(3)\r\n\r\nThe encoding diagram in section 4.2, on page 9, apparently\r\ncontains the concrete sample value, '0x10F2' (from the\r\nimmediately preceding example in Section 4.1), where it\r\nprobably should contain the abstract notion \"\".\r\nThe literal encoding as presented is misleading, hence\r\nthe following correction seems to be appropriate:\r\n\r\nRFC 4384, in section 4.2 on page 9 contains the diagram:\r\n\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0x02 | 0x0008 | Global Administrator |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Global Administrator (cont.) | 0x10F2 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\nThis diagram should say:\r\n\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0x02 | 0x0008 | Global Administrator |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Global Administrator (cont.) | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n\r\n(4)\r\n\r\nRFC 4384 makes a Normative Reference to RFC 1771.\r\nBut, almost 3 weeks ahead of the publication of RFC 4384,\r\nRFC 1771 has been obsoleted by RFC 4271.\r\n\r\nHas this obsolete reference been made intentionally (I cannot\r\nsee any immediate reason for doing so) -- or is it just an\r\neditorial oversight?", "correct_text": "", "notes": "from pending", "submit_date": "2006-02-27", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Ron Bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "107", "doc-id": "RFC4380", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) Inconsistency on cryptographic algorithm (MAC) requirements\r\n\r\nWithin section 5.2.2, on the upper half of page 21, RFC 4380 states:\r\n\r\n To maximize interoperability, this specification defines a default\r\n algorithm in which the authentication value is computed according the\r\n| HMAC specification [RFC2104] and the SHA1 function [FIPS-180].\r\n Clients and servers may agree to use HMAC combined with a different\r\n function, or to use a different algorithm altogether, such as for\r\n example AES-XCBC-MAC-96 [RFC3566].\r\n\r\n The default authentication algorithm is based on the HMAC algorithm\r\n according to the following specifications:\r\n\r\n| - the hash function shall be the SHA1 function [FIPS-180].\r\n - the secret value shall be the shared secret with which the client\r\n was configured.\r\n\r\nContrary to that, within Section 7.2.1, in the paragraph extending\r\nfrom page 39 to page 40, the same RFC says:\r\n\r\n If the shared secret contains sufficient entropy, the attacker would\r\n have to defeat the one-way function used to compute the\r\n authentication value. This specification suggests a default\r\n<>\r\n| algorithm combining HMAC and MD5. If the protection afforded by MD5\r\n was not deemed sufficient, clients and servers can agree to use a\r\n different algorithm, e.g., SHA1.\r\n\r\nI have been educated repeatedly that Security Considerations in RFCs\r\ncontain normative content when describing protocol behaviour.\r\nTherefore, it should not happen that text in Security Considerations\r\ncontradicts normative content of other sections of an RFC.\r\n\r\nRegarding the well known security issues that make MD5 appear much\r\nweaker than SHA-1, according to contemporary comprehension by the\r\ncryptographic community, the former specification (Section 5.2.2)\r\nseems to be the better choice.\r\nI therefore strongly recommend to publish an Author's Errata Note\r\nfor RFC 4380 correcting Section 7.2.1, replacing the snippit above\r\nby text conforming to the rules specified in Section 5.2.2, e.g.:\r\n\r\n If the shared secret contains sufficient entropy, the attacker would\r\n have to defeat the one-way function used to compute the\r\n| authentication value. This specification defines a default algorithm\r\n| combining HMAC and SHA-1. Clients and servers can agree to use a\r\n| different message authentication algorithm, e.g. AES-XCBC-MAC-96.\r\n| See Section 5.2.2 for details.\r\n\r\n\r\n(2) Incomplete IANA Considerations\r\n\r\nSection 9 of RFC 4380, on page 50, says:\r\n\r\n This memo documents a request to IANA to allocate a 32-bit Teredo\r\n IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4\r\n multicast address, as specified in Section 2.17.\r\n\r\nIt should say:\r\n\r\n| On requests documented in this memo, IANA has allocated a 32-bit\r\n| Teredo IPv6 service prefix, as specified in Section 2.6, a Teredo\r\n| IPv4 multicast address, as specified in Section 2.17, and a Teredo\r\n| UDP Port number, as specified in Section 2.7.\r\n\r\nRationale:\r\nAs per publication of the RFC, these assignments *have been* performed\r\nby the IANA; I propose modified wording reflecting this fact.\r\nApparently, an IANA assignment also has been performed on behalf of the\r\nTeredo proposal as documented in Section 2.7; for completeness, this\r\nassignment should be mentioned in the IANA Considerations section as\r\nwell. This will also serve as an easy-to-find \"pointer\" for readers\r\nlooking for the purpose of the assignment found in the IANA registry.\r\n\r\n\r\n(3) Various typos\r\n\r\nI have found a couple of apparent typos in RFC 4380. The sub-items\r\n below are pre-formatted for easy inclusion into an RFC errata note.\r\n\r\n\r\n(3.1) Section 5.2.2, page 21\r\n\r\nThe first paragraph on page 21 contains the sentence:\r\n\r\n [...]. Before transmission,\r\n the authentication value is computed according to the specified\r\n algorithm; on reception, the same algorithm is used to compute a\r\n target value from the content of the receive packet. [...]\r\n\r\nIt should say:\r\n\r\n [...]. Before transmission,\r\n the authentication value is computed according to the specified\r\n algorithm; on reception, the same algorithm is used to compute a\r\n| target value from the content of the received packet. [...]\r\n ^\r\n\r\n(3.2) Section 5.2.3, page 23\r\n\r\nThe second paragraph on page 23 [numbered list item 4)] says:\r\n\r\n [...]. The client SHOULD reply with a unicast Teredo bubble, sent\r\n to the source IPv4 address and source port of the local discovery\r\n bubble; the IPv6 source address of the bubble will be set to local\r\n Teredo IPv6 address; [...]\r\n\r\nIt should say:\r\n\r\n [...]. The client SHOULD reply with a unicast Teredo bubble, sent\r\n to the source IPv4 address and source port of the local discovery\r\n| bubble; the IPv6 source address of the bubble will be set to the local\r\n Teredo IPv6 address; [...]\r\n ^^^^\r\n\r\n(3.3) Section 5.2.7, page 27\r\n\r\nThe long paragraph in the middle of page 27 says:\r\n\r\n [...]. If the secondary\r\n qualification fails, the interval determination procedure will not be\r\n used, and the interval value will remain to the default value, 30\r\n seconds. [...]\r\n\r\nIt should say:\r\n\r\n [...]. If the secondary\r\n qualification fails, the interval determination procedure will not be\r\n| used, and the interval value will remain at the default value, 30\r\n seconds. [...]\r\n ^^^^\r\n\r\n(3.4) Section 5.2.9, page 30\r\n\r\nThe last paragraph of Section 5.2.9 says:\r\n\r\n [...] The nonce value and the date at which the packet was\r\n sent will be documented in a provisional peer entry for the IPV6\r\n destination. The ICMPv6 packet will then be sent [...]\r\n\r\nIt should say:\r\n\r\n [...] The nonce value and the date at which the packet was\r\n| sent will be documented in a provisional peer entry for the IPv6\r\n destination. The ICMPv6 packet will then be sent [...]\r\n ^^^^\r\n\r\n(3.5) Section 7.2, page 39\r\n\r\nThe last sentence of Section 7.2 says:\r\n\r\n [...] The attacker may have one of two objectives: it may try to\r\n deny service to the Teredo client by providing it with an address\r\n that is in fact unreachable, or it may try to insert itself as a\r\n relay for all client communications, effectively enabling a variety\r\n of \"man-in-the-middle\" attack.\r\n\r\nIt should say:\r\n\r\n [...] The attacker may have one of two objectives: it may try to\r\n deny service to the Teredo client by providing it with an address\r\n that is in fact unreachable, or it may try to insert itself as a\r\n relay for all client communications, effectively enabling a variety\r\n| of \"man-in-the-middle\" attacks.\r\n ^\r\n\r\n\r\n(4) Formatting issue\r\n\r\nRFC 4380 contains a striking number of spurious blank lines inserted\r\nin the middle of running text, interrupting proper paragraph formating.\r\n\r\nBrowsing through RFC 4380, I have found such spurious blank lines on\r\npages 23, 30, 33, 35, 41, 44, and 46.", "correct_text": "", "notes": "from pending", "submit_date": "2006-03-16", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Wes Eddy", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "108", "doc-id": "RFC4379", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n| Type = 1 (FEC TLV) | Length = 12 |\r\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n| Type = 1 (FEC TLV) | Length = 32 |\r\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "notes": "According to Section 3.3 of the LDP specification, RFC 3036,\r\nthe Lenght element of LDP TLVs measures the size of the Value\r\nelement in bytes.\r\nTherefore, 'Length = 12' is wrong, it should be 'Length = 32'.\r\n\r\nfrom pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "109", "doc-id": "RFC4377", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1", "orig_text": " One-hop Delay: The fixed delay experienced by a packet to\r\n reach the next hop resulting from the of\r\n the propagation latency, the transmission\r\n latency, and the processing latency.", "correct_text": " One-hop Delay: The fixed delay experienced by a packet to\r\n reach the next hop resulting from the sum\r\n of the propagation latency, the\r\n transmission latency, and the processing\r\n latency.", "notes": "Fix word omission. Insert \"sum\"\r\n", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "110", "doc-id": "RFC4367", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": " >From this model, it is clear that three entities in the system can\r\n potentially make false assumptions about the service provided by the\r\n server.", "correct_text": " From this model, it is clear that three entities in the system can\r\n potentially make false assumptions about the service provided by the\r\n server.", "notes": "", "submit_date": "2006-02-26", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2894", "doc-id": "RFC5473", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "A.1", "orig_text": "inPacketDeltaCount", "correct_text": "packetDeltaCount", "notes": "s/inPacketDeltaCount/packetDeltaCount/ (three times)\r\n\r\n- including figure 10.\r\n\r\nPer [RFC5102] and IANA's IPFIX registry, the correct name is \"packetDeltaCount\".", "submit_date": "2011-08-01", "submitter_name": "Paul Aitken", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2909", "doc-id": "RFC6313", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Figure 15", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Set ID = 2 | Length = 16 octets |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Template ID = 257 | Field Count = 2 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0| observationTimeMicroSec=324 | Field Length = 8 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0| digestHashValue = 326 | Field Length = 4 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Set ID = 2 | Length = 16 octets |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Template ID = 257 | Field Count = 2 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0| observationTimeMicrosec=324 | Field Length = 8 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0| digestHashValue = 326 | Field Length = 4 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n", "notes": "s/observationTimeMicroSec/observationTimeMicrosec/\r\n\r\nPer RFC5477 and IANA's IPFIX registry, the correct name is \"observationTimeMicroseconds\".", "submit_date": "2011-08-02", "submitter_name": "Paul Aitken", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "113", "doc-id": "RFC4364", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) Section 1 (Introduction)\r\n\r\nThe 1st paragraph on page 3 contains the sentence:\r\n\r\n [...]. The PE routers distribute, to the CE\r\n routers in a particular VPN, the routes from other the CE routers in\r\n that VPN. [...]\r\n\r\nIt should say:\r\n\r\n [...]. The PE routers distribute, to the CE\r\n| routers in a particular VPN, the routes from the other CE routers in\r\n that VPN. [...]\r\n ^^^^^^^^^\r\n\r\n\r\n(2) Section 3.3 (Populating the VRFs)\r\n\r\nThe last paragraph of Section 3.3, on mid-page 12, says:\r\n\r\n If an attachment circuit leads to a site which is in multiple VPNs,\r\n the attachment circuit may still associated with a single VRF, in\r\n which case the VRF will contain routes from the full set of VPNs of\r\n which the site is a member.\r\n\r\nIt should say:\r\n vvvv\r\n If an attachment circuit leads to a site which is in multiple VPNs,\r\n| the attachment circuit may still be associated with a single VRF, in\r\n which case the VRF will contain routes from the full set of VPNs of\r\n which the site is a member.\r\n\r\n\r\n(3) Section 6 (Maintaining Proper Isolation of VPNs)\r\n\r\nAt the bottom of page 26, and extending to page 27, the text says:\r\n\r\n The first condition ensure that any labeled packets received from\r\n non-backbone routers have a legitimate and properly assigned label at\r\n<< page break >>\r\n the top of the label stack. [...]\r\n\r\nIt should say:\r\n vv\r\n| The first condition ensures that any labeled packets received from\r\n non-backbone routers have a legitimate and properly assigned label at\r\n<< page break >>\r\n the top of the label stack. [...]\r\n\r\n\r\n(4) Section 7 (How PEs Learn Routes from CEs)\r\n\r\nThe descrition of 'technique #4', on mid-page 28 says:\r\n\r\n 4. The PE and CE routers may be BGP peers, and the CE router may\r\n use BGP (in particular, EBGP to tell the PE router the set of\r\n address prefixes that are at the CE router's site. (This\r\n technique can be used in stub VPNs or transit VPNs.)\r\n\r\nIt should say:\r\n vvv\r\n 4. The PE and CE routers may be BGP peers, and the CE router may\r\n| use BGP (in particular, EBGP) to tell the PE router the set of\r\n address prefixes that are at the CE router's site. (This\r\n technique can be used in stub VPNs or transit VPNs.)\r\n\r\n\r\n(5) Section 9 (Carriers' Carriers)\r\n\r\nThe last paragraph at the bottom of page 31 contains the sentence:\r\n\r\n [...]. All that\r\n is required is that the external routes be known to whatever routers\r\n are responsible for putting the label stack on a hitherto unlabeled\r\n packet and that there be label switched path that leads from those\r\n routers to their BGP peers at other sites. [...]\r\n\r\nIt should say:\r\n\r\n [...]. All that\r\n is required is that the external routes be known to whatever routers\r\n are responsible for putting the label stack on a hitherto unlabeled\r\n| packet and that there be a label switched path that leads from those\r\n routers to their BGP peers at other sites. [...]\r\n ^^^", "correct_text": "", "notes": "To facilitate the recognition of the text changes proposed,\r\nI have added change bars ('|') in column 1, and up/down pointing\r\nmarker lines ('^^^'/'vvv').\r\n\r\nfrom pending", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "123", "doc-id": "RFC4327", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "RFC 4327 makes use of the TruthValue textual convention defined in RFC\r\n2579.\r\n\r\nSeveral places in the text identify the enumerations of the textual\r\nconvention (\"true\" and \"false\") using their names and their numeric values\r\n(1 and 2 respectively).\r\n\r\nHowever, several references to the enumerations of the textual convention\r\nuse the incorrect numeric values.\r\n\r\nAll references to the enumerations of this textual convention in this RFC\r\nshould take the names (\"true\" and \"false\") as the definitive settings, and\r\nshould disregard the numeric values when stated incorrectly.\r\n\r\n", "submit_date": "2006-01-18", "submitter_name": "Adrian Farrel", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "124", "doc-id": "RFC4326", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.2", "orig_text": "When in the Reassembly State, the Receiver reads a 2-byte SNDU Length \r\nfield from the TS Packet payload. If the value is less than or equal to \r\n4, or equal to 0xFFFF, the Receiver discards the Current SNDU and", "correct_text": "When in the Reassembly State, the Receiver reads the first two bytes \r\nfrom the TS Packet payload. This value forms the first 2 bytes of the \r\nSNDU base header, which is a combination of the D-bit and the \r\nSNDU-Length. If the combined value is less than or equal to 4, or equal \r\nto 0xFFFF (i.e. D=1 and SNDU Length = 32768), the Receiver MUST discard \r\nthe Current SNDU and", "notes": "- Usage of last byte in a TS-Packet.\r\nSource: Bernhard Collini-Nocker & Gorry Fairhurst, 15th February 2006", "submit_date": "2006-08-02", "submitter_name": "Gorry Fairhurst", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "125", "doc-id": "RFC4322", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "General", "orig_text": "It's a pity that RFC 4322, published a few days *after* the new IPsec\r\nRFCs including the IKEv2 specification (RFC 4306), does not give a\r\nperspective on Opportunistic Encryption in the context of IKEv2.", "correct_text": "", "notes": "To facilitate the recognition of the text changes proposed,\r\nI have added change bars ('|') in column 1, and up/down pointing\r\nmarker lines ('^^^'/'vvv').\n --VERIFIER NOTES-- \nNo action proposed.", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2459", "doc-id": "RFC3413", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.1", "orig_text": " OBJECT snmpNotifyType\r\n SYNTAX INTEGER {\r\n trap(1)\r\n }\r\n MIN-ACCESS read-only\r\n DESCRIPTION\r\n \"Create/delete/modify access is not required.\r\n Support of the value notify(2) is not required.\"\r\n", "correct_text": " OBJECT snmpNotifyType\r\n SYNTAX INTEGER {\r\n trap(1)\r\n }\r\n MIN-ACCESS read-only\r\n DESCRIPTION\r\n \"Create/delete/modify access is not required.\r\n Support of the value inform(2) is not required.\"", "notes": "the enumeration value as stated: notify(2)\r\nthe enumeration value should be: inform(2)\r\n\r\nThis appears in section 4.2.1, \"Definitions\" for the SNMP-NOTIFICATION-MIB spanning the page break between page 54 and 55 and contained within the snmpNotifyBasicCompliance macro.", "submit_date": "2010-08-07", "submitter_name": "Mark Ellison", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "128", "doc-id": "RFC4312", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "\r\nInformative References need to be updated\r\n\r\nRationale:\r\nRFC 4312 apparently has been published a bit later than, but\r\nclosely coordinated with, the new IPsec document suite (RFC 430x).\r\n\r\nAccordingly, the Normative Reference [ESP] of RFC 4312 points to\r\nthe new ESP RFC 4303, as expected.\r\n\r\nBut surprisingly, the Informative References are not updated\r\nsimilarly.\r\nI would have expected [ARCH] pointing to RFC 4301 (that has\r\nobsoleted RFC 2401), and at least an additional Ref. to IKEv2\r\n(RFC 4306, which substantially amends/updates the old RFC 2409\r\n[IKE]) -- with title and text of Section 4 slightly adapted.\r\nThe current text and Ref. [IKE] even might lead to the mis-\r\nconception that the Camellia cipher would not be suitable for\r\nuse with IKEv2 (a statement certainly not intended by you).\r\n", "submit_date": "2006-02-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "114", "doc-id": "RFC4352", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "(1)\r\n\r\nIn Section 4.3.2.3 of RFC 4352, the first formula line on page 18,\r\n\r\n TS(i) = TS(i-1) + (DISi + 1) * frame duration, 2 < i < n\r\n\r\nshould say:\r\n\r\n TS(i) = TS(i-1) + (DISi + 1) * frame duration, 2 <= i <= n\r\n\r\n\r\n(2)\r\n\r\nThe 'Example Algorithm' in Section 4.5.1, on page 27, in the second\r\nhalf of Step 1, says:\r\n\r\n Return recovered timestamps as\r\n x(n) = t0 + n*L1 and associated ISF equal to isf0,\r\n for 0 < n < (t1 - t0)/L0\r\n goto End\r\n\r\nThis pseudocode fragment should say:\r\n\r\n for 0 < n < (t1 - t0)/L0\r\n Return recovered timestamps as\r\n x(n) = t0 + n*L0 and associated ISF equal to isf0\r\n goto End\r\n\r\n\r\n(3)\r\n\r\nIn Section 7.2, on page 32, the second item of the unnumbered list\r\nsays:\r\n\r\n - The media type (payload format name) is used in SDP \"a=rtpmap\" as\r\n the encoding name. [...]\r\n\r\nIt should say:\r\n\r\n - The media subtype (payload format name) is used in SDP \"a=rtpmap\"\r\n as the encoding name. [...]\r\n\r\n\r\n(4)\r\n\r\nWithin the second paragraph on page 33, Section 7.2.1 of RFC 4352\r\nsays:\r\n [...] As any receiver will\r\n be capable of receiving stereo frame type and perform local mixing\r\n within the AMR-WB+ decoder, there is normally only one reason to\r\n restrict to mono only: to avoid spending bit-rate on data that are\r\n not utilized if the front-end is only capable of mono.\r\n\r\nIt should say:\r\n [...] As any receiver will\r\n be capable of receiving stereo frame types and perform local\r\n mixing within the AMR-WB+ decoder, there is normally only one\r\n reason to restrict to mono only: to avoid spending bit-rate on\r\n data that are not utilized if the front-end is only capable of\r\n mono.", "correct_text": "", "notes": "from pending", "submit_date": "2006-02-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "115", "doc-id": "RFC4347", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) typo\r\n\r\nAt the top of page 3, Section 1 of RFC 4347 says:\r\n\r\n [...]. Unfortunately, although application layer\r\n security protocols generally provide superior security properties\r\n (e.g., end-to-end security in the case of S/MIME), they typically\r\n requires a large amount of effort to design -- in contrast to the\r\n relatively small amount of effort required to run the protocol over\r\n TLS.\r\n\r\nIt should say:\r\n\r\n [...]. Unfortunately, although application layer\r\n security protocols generally provide superior security properties\r\n (e.g., end-to-end security in the case of S/MIME), they typically\r\n| require a large amount of effort to design -- in contrast to the\r\n relatively small amount of effort required to run the protocol over\r\n TLS.\r\n\r\n\r\n(2) imprecise data description for `ciphersuites`\r\n\r\nThis is an issue inherited from RFC 4346 -- see my errata submission\r\non that RFC. For convenience, I repeat the details here.\r\n\r\nSection 7.4.1.2 of RFC 4346 (on p. 12 of RFC 4346) defines the syntax:\r\n\r\n uint8 CipherSuite[2]; /* Cryptographic suite selector */\r\n\r\nAccording to the specifications given in Section 4.3 of RFC 4346,\r\nvectors of type CipherSuite strictly must have byte lengths being a\r\nmultiple of 2.\r\nThis also means that the upper bound for a varaiable-length array\r\nof type CipherSuite should always be a multiple of 2.\r\n\r\nHence, the declaration in Section 4.2.1 of RFC 4347, on page 12,\r\n\r\n struct {\r\n ProtocolVersion client_version;\r\n Random random;\r\n SessionID session_id;\r\n opaque cookie<0..32>; // New field\r\n CipherSuite cipher_suites<2..2^16-1>;\r\n CompressionMethod compression_methods<1..2^8-1>;\r\n } ClientHello;\r\n\r\nshould say:\r\n\r\n struct {\r\n ProtocolVersion client_version;\r\n Random random;\r\n SessionID session_id;\r\n opaque cookie<0..32>; // New field\r\n| CipherSuite cipher_suites<2..2^16-2>;\r\n CompressionMethod compression_methods<1..2^8-1>;\r\n } ClientHello;\r\n\r\nThis change should be applied to the syntax summary in section 4.3.2,\r\non mid-page 21, as well.\r\n\r\n\r\n(3) missing white space\r\n\r\nIn Section 4.2.2 of RFC 4347, the lines on top of page 14,\r\n\r\n case hello_verify_request: HelloVerifyRequest; // New type\r\n case server_hello: ServerHello;\r\n case certificate:Certificate;\r\n case server_key_exchange: ServerKeyExchange;\r\n case certificate_request: CertificateRequest;\r\n case server_hello_done:ServerHelloDone;\r\n case certificate_verify: CertificateVerify;\r\n case client_key_exchange: ClientKeyExchange;\r\n case finished:Finished;\r\n\r\nshould say:\r\n\r\n case hello_verify_request: HelloVerifyRequest; // New type\r\n case server_hello: ServerHello;\r\n| case certificate: Certificate;\r\n case server_key_exchange: ServerKeyExchange;\r\n case certificate_request: CertificateRequest;\r\n| case server_hello_done: ServerHelloDone;\r\n case certificate_verify: CertificateVerify;\r\n case client_key_exchange: ClientKeyExchange;\r\n| case finished: Finished;\r\n\r\nThis change should be applied to the syntax summary in section 4.3.2,\r\non top of page 21, as well.\r\n\r\n\r\n(4) copy-and-paste issue (?)\r\n\r\nOn page 20, the first declaration in Section 4.3.2,\r\n\r\n enum {\r\n hello_request(0), client_hello(1), server_hello(2),\r\n hello_verify_request(3), // New field\r\n certificate(11), server_key_exchange (12),\r\n certificate_request(13), server_hello_done(14),\r\n certificate_verify(15), client_key_exchange(16),\r\n finished(20), (255)\r\n } HandshakeType;\r\n\r\nshould say, using the appropriate term:\r\n\r\n enum {\r\n hello_request(0), client_hello(1), server_hello(2),\r\n| hello_verify_request(3), // New value\r\n certificate(11), server_key_exchange (12),\r\n certificate_request(13), server_hello_done(14),\r\n certificate_verify(15), client_key_exchange(16),\r\n finished(20), (255)\r\n } HandshakeType;\r\n\r\n\r\n(5) Outdated Informative References\r\n\r\nRFC 4347 has been published several months after the new IPsec RFCs.\r\nIt therefore would have been preferrable to have the following\r\nreferences updated:\r\n\r\n [AH] : RFC 2402 --> RFC 4302\r\n\r\n [ESP] : RFC 2406 --> RFC 4303\r\n\r\nBTW: The Ref. \"[AH]\" does *not* appear anywhere in the text!\r\n\r\nAlso, The DCCP RFCs have been published a few weeks before RFC 4347;\r\ntherefore, the following Ref. update would have been appropriate:\r\n\r\n [DCCP] : \"Work in Progress\" --> RFC 4340, March 2006.\r\n\r\n\r\n(6) unexpected / inappropriate Reference\r\n\r\nPage 23 contains the inappropriate Informative Reference:\r\n\r\n [PHOTURIS] Karn, P. and W. Simpson, \"ICMP Security Failures\r\n Messages\", RFC 2521, March 1999.\r\n\r\nThis clearly should be:\r\n\r\n| [PHOTURIS] Karn, P. and W. Simpson, \"Photuris: Session-Key Management\r\n| Protocol\", RFC 2522, March 1999.\r\n\r\n(Cf. the citations to [PHOTURIS], in Section 4.2.1, on page 11.)", "correct_text": "", "notes": "All excerpts from the RFC text are taken keeping their original\r\nformatting, and modified text is formatted in conformance with\r\nRFC guidelines again.\r\n\r\nI use change bars ('|' in column 1) and casual up/down pointing\r\ntags ('^^^' / 'vvv' marks in extra lines) to emphasize the location\r\nof textual issues and/or proposed textual enhancements/corrections.\r\n\r\nfrom pending", "submit_date": "2006-05-29", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "116", "doc-id": "RFC4346", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Following references should all be to Section 12:\r\n\r\nSection 6:\r\n# See Section 11 for IANA Considerations for ContentType values.\r\n\r\nSection 7.2.2:\r\n# See Section 11 for IANA Considerations for alert values.\r\n\r\nSection 7.4:\r\n# See Section 11 for IANA Considerations for these values.\r\n\r\nSection 7.4.4:\r\n# Additional information describing the role of IANA in the allocation\r\n# of ClientCertificateType code points is described in Section 11.\r\n\r\nfrom pending", "submit_date": "2006-05-11", "submitter_name": "David Hopwood", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "117", "doc-id": "RFC4346", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(C2) imprecise data description for `ciphersuites`\r\n\r\nSection 7.4.1.2, on page 37 defines the syntax:\r\n\r\n uint8 CipherSuite[2]; /* Cryptographic suite selector */\r\n\r\nAccording to the specifications given in Section 4.3, vectors\r\nof type CipherSuite strictly must have byte lengths being a\r\nmultiple of 2.\r\nThis also means that the upper bound for a varaiable-length array\r\nof type CipherSuite should always be a multiple of 2.\r\nHence, the declaration in Section 7.4.1.2, on top of page 38,\r\n\r\n struct {\r\n ProtocolVersion client_version;\r\n Random random;\r\n SessionID session_id;\r\n CipherSuite cipher_suites<2..2^16-1>;\r\n CompressionMethod compression_methods<1..2^8-1>;\r\n } ClientHello;\r\n\r\nshould better say:\r\n\r\n struct {\r\n ProtocolVersion client_version;\r\n Random random;\r\n SessionID session_id;\r\n| CipherSuite cipher_suites<2..2^16-2>;\r\n CompressionMethod compression_methods<1..2^8-1>;\r\n } ClientHello;\r\n\r\nThis issue recurs in Appendix A.4.1 (2nd line from bottom of p.57)\r\nand at various places in other TLS RFCs, in particular in RFC 4347\r\nand RFC 4366 -- see my errata messages for these RFCs.\r\n\r\nHistorical Note:\r\n In SSL 2.0, the CipherSuite construct was 3 bytes long.\r\n Because 3 divides 2^16-1, <3..2^16-1> was an appropriate size\r\n range then. The issue has been introduced with SSL 3.0.\r\n\r\n\r\n(C3) missing Reference\r\n\r\nAppendix B, at the bottom of page 66, contains the Glossary item:\r\n\r\n RC2\r\n A block cipher developed by Ron Rivest at RSA Data Security, Inc.\r\n [RSADSI] described in [RC2].\r\n\r\nThere is no such Reference \"[RSADSI]\" in the Informative References\r\nSection, on pp. 82 ff. -- apparently, it has been prematurely deleted\r\nfrom RFC 2246. Perhaps, nothing would be lost when replacing the\r\nabove Glossary item by:\r\n\r\n RC2\r\n A block cipher developed by Ron Rivest described in [RC2].\r\n\r\n\r\n(C4) Outdated Normative Reference\r\n\r\nRFC 4346 has been jointly published with RFC 4366, which has\r\nobsoleted RFC 3546.\r\nTherefore, it would have been much more consistent to replace,\r\nin the Normative References Section, on page 82, the entry:\r\n\r\n [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,\r\n and T. Wright, \"Transport Layer Security (TLS)\r\n Extensions\", RFC 3546, June 2003.\r\n\r\nby:\r\n\r\n [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,\r\n and T. Wright, \"Transport Layer Security (TLS)\r\n| Extensions\", RFC 4366, April 2006.\r\n ^^^^^^^^^^^^^^^^\r\n\r\n(C5) unexpected / inappropriate Reference\r\n\r\nPage 83 contains the inappropriate Informative Reference:\r\n\r\n [TCP] Hellstrom, G. and P. Jones, \"RTP Payload for Text\r\n Conversation\", RFC 4103, June 2005.\r\n\r\nThis clearly should be:\r\n\r\n| [TCP] Postel, J., \"Transmission Control Protocol\", STD 7,\r\n| RFC 793, September 1981.\r\n\r\n(Cf. the single citation to [TCP], in the first paragraph of Section 1,\r\non page 4.)\r\n\r\n\r\nSimple textual issues (errata)\r\n==============================\r\n\r\n(E1) typo\r\n\r\nThe second paragraph of Section 3 of RFC 4346, on page 6, says:\r\n\r\n This document is not intended to supply any details of service\r\n definition or of interface definition, although it does cover select\r\n areas of policy as they are required for the maintenance of solid\r\n security.\r\n\r\nIt should perhaps say:\r\n\r\n This document is not intended to supply any details of service\r\n definition or of interface definition, although it does cover\r\n| selected areas of policy as they are required for the maintenance of\r\n solid security.\r\n\r\n(E2) copy-and-paste error (?)\r\n\r\nAt the bottom of page 11, Section 4.7 of RFC 4346 says:\r\n\r\n In public key encryption, a public key algorithm is used to encrypt\r\n data in such a way that it can be decrypted only with the matching\r\n private key. A public-key-encrypted element is encoded as an opaque\r\n vector <0..2^16-1>, where the length is specified by the signing\r\n algorithm and key.\r\n\r\nIt should say:\r\n\r\n In public key encryption, a public key algorithm is used to encrypt\r\n data in such a way that it can be decrypted only with the matching\r\n private key. A public-key-encrypted element is encoded as an opaque\r\n| vector <0..2^16-1>, where the length is specified by the encrypting\r\n algorithm and key.\r\n ^^^^^^^^^^\r\n\r\n(E3) typo\r\n\r\nThe beginning of the first paragraph of Section 6.1, on page 15,\r\n\r\n A TLS connection state is the operating environment of the TLS Record\r\n Protocol. It specifies a compression algorithm, and encryption\r\n algorithm, and a MAC algorithm. In addition, the parameters for\r\n\r\nshould say (replacing \"and\" by \"an\"):\r\n\r\n A TLS connection state is the operating environment of the TLS Record\r\n| Protocol. It specifies a compression algorithm, an encryption\r\n algorithm, and a MAC algorithm. In addition, the parameters for\r\n\r\n\r\n(E4) word twister\r\n\r\nNear the bottom of page 15, Section 6.1 says:\r\n\r\n compression algorithm\r\n An algorithm to be used for data compression. This specification\r\n must include all information the algorithm requires compression.\r\n\r\nIt should perhaps say:\r\n\r\n compression algorithm\r\n An algorithm to be used for data compression. This specification\r\n| must include all information the compression algorithm requires.\r\n\r\n\r\n(E5) improper indentation\r\n\r\nIn Section 7.4.1.1, on page 36, a headline is indented too much;\r\nthe text,\r\n\r\n Structure of this message:\r\n\r\n struct { } HelloRequest;\r\n\r\n Note: This message MUST NOT be included ...\r\n\r\nshould say:\r\n\r\n| Structure of this message:\r\n\r\n struct { } HelloRequest;\r\n\r\n Note: This message MUST NOT be included ...\r\n\r\n\r\n(E6) improper line (un)folding and irregular indentation\r\n\r\nIn Section 7.4.1.2, at the bottom of page 36, the text,\r\n\r\n struct {\r\n uint32 gmt_unix_time;\r\n opaque random_bytes[28];\r\n } Random;\r\n\r\n gmt_unix_time The current time and date in standard UNIX 32-bit\r\n format (seconds since the midnight starting Jan 1, 1970, GMT,\r\n ignoring leap seconds) according to the sender's internal clock.\r\n Clocks are not required to be set correctly by the basic TLS\r\n Protocol; higher-level or application protocols may define\r\n additional requirements.\r\n\r\n random_bytes\r\n 28 bytes generated by a secure random number generator.\r\n\r\nfollowing the layout style followed in the remainder of the document\r\nshould be formatted as:\r\n\r\n struct {\r\n uint32 gmt_unix_time;\r\n opaque random_bytes[28];\r\n } Random;\r\n\r\n| gmt_unix_time\r\n| The current time and date in standard UNIX 32-bit\r\n format (seconds since the midnight starting Jan 1, 1970, GMT,\r\n ignoring leap seconds) according to the sender's internal clock.\r\n Clocks are not required to be set correctly by the basic TLS\r\n Protocol; higher-level or application protocols may define\r\n additional requirements.\r\n\r\n| random_bytes\r\n| 28 bytes generated by a secure random number generator.\r\n\r\n\r\n(E7) improper line (un)folding\r\n\r\nThe last paragraph of Section 7.4.1.3, on page 40,\r\n\r\n compression_method The single compression algorithm selected by the\r\n server from the list in ClientHello.compression_methods. For\r\n resumed sessions this field is the value from the resumed session\r\n state.\r\n\r\nconsistently should be formatted as:\r\n\r\n| compression_method\r\n| The single compression algorithm selected by the server from the\r\n list in ClientHello.compression_methods. For resumed sessions\r\n this field is the value from the resumed session state.\r\n\r\n\r\n(E8) improper line (un)folding and irregular indentation\r\n\r\nIn Section 7.4.7.1, on page 48, the clauses,\r\n\r\n client_version The latest (newest) version supported by the\r\n client. This is used to detect version roll-back attacks.\r\n Upon receiving the premaster secret, the server SHOULD check\r\n that this value matches the value transmitted by the client in\r\n the client hello message.\r\n\r\n random\r\n 46 securely-generated random bytes.\r\n\r\nconsistently should be formatted as:\r\n\r\n| client_version\r\n| The latest (newest) version supported by the client. This is\r\n used to detect version roll-back attacks. Upon receiving the\r\n premaster secret, the server SHOULD check that this value\r\n matches the value transmitted by the client in the client hello\r\n message.\r\n\r\n random\r\n| 46 securely-generated random bytes.\r\n\r\nand subsequently, the clause,\r\n\r\n pre_master_secret\r\n This random value is generated by the client and is used to\r\n generate the master secret, as specified in Section 8.1.\r\n\r\nshould be:\r\n\r\n pre_master_secret\r\n| This random value is generated by the client and is used to\r\n| generate the master secret, as specified in Section 8.1.\r\n\r\n\r\n(E9) spurious text line\r\n\r\nDuring the removal of the \"EXPORT\" ciper suites from Appendix C,\r\na text line from RFC 2246 has been left there inadvertently.\r\nThe table, at the bottom of page 68,\r\n\r\n Key\r\n Exchange\r\n Algorithm Description Key size limit\r\n\r\n DHE_DSS Ephemeral DH with DSS signatures None\r\n DHE_RSA Ephemeral DH with RSA signatures None\r\n DH_anon Anonymous DH, no signatures None\r\n DH_DSS DH with DSS-based certificates None\r\n DH_RSA DH with RSA-based certificates None\r\n| RSA = none\r\n NULL No key exchange N/A\r\n RSA RSA key exchange None\r\n\r\nshould say:\r\n\r\n Key\r\n Exchange\r\n Algorithm Description Key size limit\r\n\r\n DHE_DSS Ephemeral DH with DSS signatures None\r\n DHE_RSA Ephemeral DH with RSA signatures None\r\n DH_anon Anonymous DH, no signatures None\r\n DH_DSS DH with DSS-based certificates None\r\n DH_RSA DH with RSA-based certificates None\r\n NULL No key exchange N/A\r\n RSA RSA key exchange None\r\n\r\n\r\n(E10) improper language\r\n\r\nDuring the addition of the third protocol variant, text in Appendix E\r\nhas become improper, stiil talking about \"both\" versions.\r\n\r\nThe second paragraph of Appendix E, on page 71,\r\n\r\n TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,\r\n supporting both is easy. TLS clients who wish [...]\r\n ^^^^\r\nshould say, e.g.:\r\n\r\n TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,\r\n| supporting all is easy. TLS clients who wish [...]\r\n ^^^\r\n\r\n\r\n(E11) improper line (un)folding\r\n\r\nAppendix E.1, near the bottom on page 73, contains the clause:\r\n\r\n challenge The client challenge to the server for the server to\r\n identify itself is a (nearly) arbitrary-length random. The TLS\r\n server will right-justify the challenge data to become the\r\n ClientHello.random data (padded with leading zeroes, if\r\n necessary), as specified in this protocol specification. If the\r\n length of the challenge is greater than 32 bytes, only the last 32\r\n bytes are used. It is legitimate (but not necessary) for a V3\r\n server to reject a V2 ClientHello that has fewer than 16 bytes of\r\n challenge data.\r\n\r\nThis should be formatted as:\r\n\r\n| challenge\r\n| The client challenge to the server for the server to identify\r\n itself is a (nearly) arbitrary-length random. The TLS server will\r\n right-justify the challenge data to become the ClientHello.random\r\n data (padded with leading zeroes, if necessary), as specified in\r\n this protocol specification. If the length of the challenge is\r\n greater than 32 bytes, only the last 32 bytes are used. It is\r\n legitimate (but not necessary) for a V3 server to reject a V2\r\n ClientHello that has fewer than 16 bytes of challenge data.\r\n\r\n\r\n\r\n(E12) punctuation issues in References\r\n\r\nThe following Normative Reference entries on page 81/82 contain\r\nsyntactically inconsistent punctuation.\r\n\r\n [AES] National Institute of Standards and Technology,\r\n \"Specification for the Advanced Encryption Standard (AES)\"\r\n FIPS 197. November 26, 2001.\r\nshould say:\r\n [AES] National Institute of Standards and Technology,\r\n \"Specification for the Advanced Encryption Standard\r\n| (AES)\", FIPS 197. November 26, 2001.\r\n ^\r\n\r\n [3DES] W. Tuchman, \"Hellman Presents No Shortcut Solutions To\r\n DES,\" IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.\r\nshould say:\r\n [3DES] W. Tuchman, \"Hellman Presents No Shortcut Solutions To\r\n| DES\", IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.\r\n ^^\r\n\r\n [DES] ANSI X3.106, \"American National Standard for Information\r\n Systems-Data Link Encryption,\" American National Standards\r\n Institute, 1983.\r\nshould say:\r\n [DES] ANSI X3.106, \"American National Standard for Information\r\n| Systems-Data Link Encryption\", American National Standards\r\n Institute, 1983.\r\n ^^\r\n\r\n [DSS] NIST FIPS PUB 186-2, \"Digital Signature Standard,\"\r\n National Institute of Standards and Technology, U.S.\r\n Department of Commerce, 2000.\r\nshould say: vv\r\n| [DSS] NIST FIPS PUB 186-2, \"Digital Signature Standard\",\r\n National Institute of Standards and Technology, U.S.\r\n Department of Commerce, 2000.\r\n\r\n\r\n [SHA] NIST FIPS PUB 180-2, \"Secure Hash Standard,\" National\r\n Institute of Standards and Technology, U.S. Department of\r\n Commerce., August 2001.\r\nshould say: vv\r\n| [SHA] NIST FIPS PUB 180-2, \"Secure Hash Standard\", National\r\n Institute of Standards and Technology, U.S. Department of\r\n Commerce., August 2001.\r\n\r\n\r\nSimilarly, the following Informative Reference entry on page 83,\r\n\r\n [RSA] R. Rivest, A. Shamir, and L. M. Adleman, \"A Method for\r\n Obtaining Digital Signatures and Public-Key\r\n Cryptosystems,\" Communications of the ACM, v. 21, n. 2,\r\n Feb 1978, pp. 120-126.\r\n\r\nshould say:\r\n\r\n [RSA] R. Rivest, A. Shamir, and L. M. Adleman, \"A Method for\r\n Obtaining Digital Signatures and Public-Key\r\n| Cryptosystems\", Communications of the ACM, v. 21, n. 2,\r\n Feb 1978, pp. 120-126.\r\n\r\n\r\n(E13) mis-spelled author name in Informative Reference\r\n\r\nThe name of Alan O. Freier has been mis-spelled on page 83, in the\r\nInformative Reference,\r\n\r\n [SSL3] A. Frier, P. Karlton, and P. Kocher, \"The SSL 3.0\r\n Protocol\", Netscape Communications Corp., Nov 18, 1996.\r\n\r\nwhich should say:\r\n vv\r\n| [SSL3] A. Freier, P. Karlton, and P. Kocher, \"The SSL 3.0\r\n Protocol\", Netscape Communications Corp., Nov 18, 1996.", "correct_text": "", "notes": "(Item C1 split to separate Errata ID 1896)\r\n\r\nAll excerpts from the RFC text are taken keeping their original\r\nformatting, and modified text is formatted in conformance with\r\nRFC guidelines again.\r\n\r\nI use change bars ('|' in column 1) and casual up/down pointing\r\ntags ('^^^' / 'vvv' marks in extra lines) to emphasize the location\r\nof textual issues and/or proposed textual enhancements/corrections.\r\n\r\nfrom pending", "submit_date": "2006-05-29", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "118", "doc-id": "RFC4345", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7.2", "orig_text": " [MIRONOV] Mironov, I., \"(Not So) Random Shuffles of RC4\", Advances\r\n in Cryptology -- CRYPTO 2002: 22nd Annual International\r\n Cryptology Conference, August 2002,\r\n .", "correct_text": " [MIRONOV] Mironov, I., \"(Not So) Random Shuffles of RC4\", Advances\r\n in Cryptology -- CRYPTO 2002: 22nd Annual International\r\n Cryptology Conference, August 2002, full version at\r\n \r\n", "notes": "", "submit_date": "2006-02-07", "submitter_name": "Ben Harris", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "119", "doc-id": "RFC4343", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "1", "orig_text": " The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\",\r\n \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this\r\n document are to be interpreted as described in [RFC2119].", "correct_text": " The key words \"MUST\" and \"MAY\" in this document are to be\r\n interpreted as described in [RFC2119].\r\n", "notes": "\r\nOther than in the above-quoted sentence, there are no\r\ninstances of \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", SHOULD\",\r\n\"SHOULD NOT\", \"RECOMMENDED\", or \"OPTIONAL\" in the RFC (and the\r\ninstances above surely cannot be interpreted as described in RFC\r\n2119; they are mere labels in the context of that sentence).\n --VERIFIER NOTES-- \nThe keyword paragraph is standard, and although words are mentioned that are later not used, this is not an error. ", "submit_date": "2006-02-26", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "120", "doc-id": "RFC4339", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5.3.3", "orig_text": " 4. It is sub-optimal to utilize the radio resources in 3GPP networks\r\n for DHCPv6 messages if there is a simpler alternative is\r\n available.\r\n \r\n\r\n", "correct_text": " 4. It is sub-optimal to utilize the radio resources in 3GPP networks\r\n for DHCPv6 messages if there is a simpler alternative available.", "notes": "from pending", "submit_date": "2006-03-02", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Ron Bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "121", "doc-id": "RFC4337", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": " Security considerations: See section 5 of RFC 4337.\r\n", "correct_text": " Security considerations: See section 4 of RFC 4337.\r\n", "notes": " \r\n\r\nThe Security Considerations *are* in Section 4 of RFC 4337.\r\nNote: This must have been a last-minute \"fix\", the draft was o.k.\r\n\r\nI recommend to have the IANA update the registrations accordingly.", "submit_date": "2006-03-19", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2336", "doc-id": "RFC5777", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2.8", "orig_text": "The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type\r\nUnsigned32. The value specifies the fractional seconds that are\r\nadded to Absolute-Start-Time value in order to determine when the\r\ntime window starts. If this AVP is absent from the Time-Of-Day-\r\nCondition AVP, then the fractional seconds are assumed to be zero.", "correct_text": "The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type\r\nUnsigned32. The value specifies the fractional seconds that are\r\nadded to Absolute-Start-Time value in order to determine when the\r\ntime window starts. The Absolute-Start-Fractional-Seconds represent \r\na 32-bit fraction field giving a precision of about 232 picoseconds \r\n( 1/((2^32)-1)) seconds ). If this AVP is absent from the Time-Of-Day-\r\nCondition AVP, then the fractional seconds are assumed to be zero.\r\nSee the Network Time Protocol [RFC 1305] for more precision.", "notes": "The AVP description lacked a explanation about what a fractional second is.", "submit_date": "2010-07-19", "submitter_name": "Francois Bard", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2460", "doc-id": "RFC4398", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "2", "orig_text": "2. The CERT Resource Record\r\n\r\n The CERT resource record (RR) has the structure given below. Its RR\r\n type code is 37.\r\n\r\n 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | type | key tag |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | algorithm | /\r\n +---------------+ certificate or CRL /\r\n / /\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|", "correct_text": "2. The CERT Resource Record\r\n\r\n The CERT resource record (RR) has the structure given below. Its RR\r\n type code is 37.\r\n\r\n 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | type | key tag |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | algorithm | /\r\n +---------------+ certificate or CRL /\r\n / /\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|", "notes": "In Section 2 (The CERT Resource Record) the table describing the wire format of the CERT RR is misaligned in such a way that it could lead to technical ambiguity of field positions within the packet structure.", "submit_date": "2010-08-07", "submitter_name": "Paul Freeman", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2461", "doc-id": "RFC5310", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "3.4", "orig_text": "The authentication data for the IS-IS IIH PDUs MUST be computed after\r\nthe IS-IS Hello (IIH) has been padded to the MTU size, if padding is \r\nnot explicitly disabled.", "correct_text": "The authentication data for the IS-IS IIH PDUs MUST be computed after\r\nthe IS-IS Hello (IIH) has been padded to the MTU size, if padding is\r\nnot explicitly disabled.\r\n\r\nISes (routers) that implement CRYPTO_AUTH authentication and initiate LSP\r\npurges MUST remove the body of the LSP and add the authentication TLV. ", "notes": "The RFC ignores the case of when an IS initiates a purge. Purges MUST be authenticated explicitly, otherwise the default protocol machinery will leave open a trivial attack.\n --VERIFIER NOTES-- \nThis issue appears to be correct, but does not qualify as something that can be addressed through the Errata System because it is a functional change to the document, not a typo. If the WG feels that it needs to be addressed, this should be captured in a new I-D.\r\n", "submit_date": "2010-08-12", "submitter_name": "Tony Li", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2462", "doc-id": "RFC5310", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "3.5", "orig_text": "An implementation MAY have a transition mode where it includes\r\nCRYPTO_AUTH information in the PDUs but does not verify this\r\ninformation. This is provided as a transition aid for networks in\r\nthe process of migrating to the new CRYPTO_AUTH-based authentication\r\nschemes.", "correct_text": "An implementation MAY have a transition mode where it includes\r\nCRYPTO_AUTH information in the PDUs but does not verify this\r\ninformation. This is provided as a transition aid for networks in\r\nthe process of migrating to the new CRYPTO_AUTH-based authentication\r\nschemes.\r\n\r\nISes implementing CRYPTO_AUTH authentication MUST NOT accept\r\nunauthenticated purges. ISes MUST NOT accept purges that contain\r\nTLVs other than the authentication TLV. These restrictions are\r\nnecessary to prevent a hostile system from receiving an LSP, setting\r\nthe Remaining Lifetime field to zero, and flooding it, thereby\r\ninitiating a purge without knowing the authentication password.", "notes": "The RFC ignores the case of purges. With explicit definition, purge packets would not include authentication, which would open a trivial vector for attack.\n --VERIFIER NOTES-- \nThis issue appears to be correct, but does not qualify as something that can be addressed through the Errata System because it is a functional change to the document, not a typo. If the WG feels that it needs to be addressed, this should be captured in a new I-D. ", "submit_date": "2010-08-12", "submitter_name": "Tony Li", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2463", "doc-id": "RFC3435", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix G", "orig_text": "On Page no 206 at the bottom you will see following :\r\n\r\nStep 2 - Delete Connection (dlcx) from ca to rgw2\r\n\r\n Requests rgw2 to delete the connection \"67890af54c9\":\r\n\r\n dlcx 2055 aaln/1@rgw1.whatever.net mgcp 1.0\r\n c: 9876543210abcdef\r\n i: 67890af54c9\r\n", "correct_text": "Step 2 - Delete Connection (dlcx) from ca to rgw2\r\n\r\n Requests rgw2 to delete the connection \"67890af54c9\":\r\n\r\n dlcx 2055 aaln/1@rgw2.whatever.net mgcp 1.0\r\n c: 9876543210abcdef\r\n i: 67890af54c9\r\n", "notes": "1. Need to visit Following link :\r\nhttp://tools.ietf.org/rfc/rfc3435.txt\r\n\r\n2. Go to Appendix G:\r\n\r\nAppendix G: Example Call Flows....................................194\r\n G.3 Connection Deletion........................................206\r\n G.3.1 Residential Gateway to Residential Gateway.................206 \r\n\r\n3. On Page no 206 at the bottom you will see following :\r\n\r\nStep 2 - Delete Connection (dlcx) from ca to rgw2\r\n\r\n Requests rgw2 to delete the connection \"67890af54c9\":\r\n\r\n dlcx 2055 aaln/1@rgw1.whatever.net mgcp 1.0\r\n c: 9876543210abcdef\r\n i: 67890af54c9\r\n\r\nit should be rgw2 i guess.\r\n\r\n-- NOTE from reviewing AD: This change affects page 207, not page 206.", "submit_date": "2010-08-13", "submitter_name": "Vishal Grover", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3544", "doc-id": "RFC5155", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.3", "orig_text": "o The Next Hashed Owner Name field is represented as an unpadded\r\n sequence of case-insensitive base32 digits, without whitespace.", "correct_text": "o The Next Hashed Owner Name field is represented as an unpadded \r\n sequence of case-insensitive base32hex digits, without whitespace.", "notes": "RFC 4648 Section 7 says: 'This encoding may be referred to as \"base32hex\". This encoding should not be regarded as the same as the \"base32\" encoding and should not be referred to as only \"base32\".'\r\n\r\nThere are many spots in RFC 5155 that use the term base32 where base32hex is the appropriate term. Section 3.3 above is the most important, but Section 1.1 uses the term as well Section 3 paragraph 4 and Section 3.2 paragraph 8.", "submit_date": "2013-03-10", "submitter_name": "Andy Newton", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "384", "doc-id": "RFC2812", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.3", "orig_text": " The presence of a prefix is indicated with a single leading ASCII\n colon character (':', 0x3b), which MUST be the first character of\n the message itself. ", "correct_text": " The presence of a prefix is indicated with a single leading ASCII\n colon character (':', 0x3a), which MUST be the first character of\n the message itself.\n", "notes": "", "submit_date": "2002-12-16", "submitter_name": "Jeroen Peschier", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "385", "doc-id": "RFC2812", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.3.1", "orig_text": " chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B", "correct_text": " chanstring = %x01-06 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B", "notes": "", "submit_date": "2004-06-10", "submitter_name": "Alejandro Grijalba", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "129", "doc-id": "RFC4309", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "5", "orig_text": "On page 6, the second paragraph of Section 5 says:\r\n\r\n Sequence Numbers are conveyed canonical network byte order. Extended\r\n Sequence Numbers are conveyed canonical network byte order, placing\r\n the high-order 32 bits first and the low-order 32 bits second.\r\n Canonical network byte order is fully described in RFC 791, Appendix\r\n B.\r\n\r\nThe text should perhaps better say:\r\n\r\n Sequence Numbers are conveyed in canonical network byte order.\r\n Extended Sequence Numbers are conveyed in canonical network byte\r\n order, placing the high-order 32 bits first and the low-order 32 bits\r\n second. Canonical network byte order is fully described in RFC 791,\r\n Appendix B.\r\n\r\nThe second half-sentence of the second sentence might even be considered\r\nredundant, fully comprised by the term 'canonical network byte order',\r\nand hence be omitted entirely. Doing that, and following the maxim of\r\n\"making RFC text as simple as possible\", the above text might be\r\nabreviated to say:\r\n\r\n Sequence Numbers and Extended Sequence Numbers are conveyed in\r\n canonical network byte order. Canonical network byte order is fully\r\n described in RFC 791, Appendix B.\r\n\r\nFinally, considering that the SPI is a 32-bit number and covered by\r\nthe same ordering rule as well, the text might - even shorter - say:\r\n\r\n All fields are conveyed in canonical network byte order. Canonical\r\n network byte order is fully described in RFC 791, Appendix B.\r\n\r\nPlease decide whether the initial text correction deserves an\r\nErrata Note, possibly including the additional enhancement(s).", "correct_text": "", "notes": "word omissions - and opportunity to simplify the text\r\n\r\nNOTE (2006-02-13)\r\nI do not think that any of these will lead to confusion or\r\ninteroperability concerns. Thus, I do not think that they warrant \r\nthe time and other resources need to generate Errata.\r\nRuss Housley\r\n\r\nfrom pending", "submit_date": "2006-02-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "130", "doc-id": "RFC4309", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nPage heading says:", "orig_text": "RFC 4309 Using AEC CCM Mode with IPsec ESP December 2005", "correct_text": "RFC 4309 Using AES CCM Mode with IPsec ESP December 2005", "notes": "\r\nIn RFC 4309 the page headings have a typo AES is misspelled as AEC.", "submit_date": "2006-01-05", "submitter_name": "Aaron Cohen", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "131", "doc-id": "RFC4307", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.1.3", "orig_text": " IKEv2 defines several possible algorithms for Transfer Type 1\r\n (encryption). These are defined below with their implementation\r\n status.", "correct_text": " IKEv2 defines several possible algorithms for Transform Type 1\r\n (encryption). These are defined below with their implementation\r\n status.\r\n", "notes": "", "submit_date": "2006-02-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "132", "doc-id": "RFC4305", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the header, it says:", "orig_text": "Obsoletes: 2404, 2406 ", "correct_text": "Obsoletes: 2402, 2406\n", "notes": "", "submit_date": "2006-02-20", "submitter_name": "Donald Eastlake III", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "133", "doc-id": "RFC4303", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.3.4", "orig_text": " NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire\r\n implementations, it will be necessary to examine all the extension\r\n headers to determine if there is a fragmentation header and hence\r\n that the packet needs reassembling prior to IPsec processing.", "correct_text": " NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire\r\n implementations, it will be necessary to examine all the extension\r\n headers to determine if there is a fragmentation header, and either\r\n the More flag or the Fragment Offset is non-zero. If so that packet\r\n needs reassembling prior to IPsec processing.\r\n", "notes": "", "submit_date": "2006-01-12", "submitter_name": "Vishwas Manral", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "134", "doc-id": "RFC4302", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.3.4", "orig_text": " NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire\r\n implementations, it will be necessary to examine all the extension\r\n headers to determine if there is a fragmentation header and hence\r\n that the packet needs reassembling prior to IPsec processing.\r\n", "correct_text": " NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire\r\n implementations, it will be necessary to examine all the extension\r\n headers to determine if there is a fragmentation header, and either\r\n the More flag or the Fragment Offset is non-zero. If so that packet\r\n needs reassembling prior to IPsec processing.\r\n", "notes": "", "submit_date": "2006-01-12", "submitter_name": "Vishwas Manral", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "135", "doc-id": "RFC4301", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "Appendix A2 says:", "orig_text": " Option/Extension Name Reference\r\n ----------------------------------- ---------\r\n MUTABLE BUT PREDICTABLE -- included in ICV calculation\r\n Routing (Type 0) [DH98]\r\n\r\n BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING\r\n TRANSIT)\r\n Hop-by-Hop options [DH98]\r\n Destination options [DH98]\r\n\r\n NOT APPLICABLE\r\n Fragmentation [DH98]\r\n", "correct_text": " Option/Extension Name Reference\r\n ----------------------------------- ---------\r\n MUTABLE BUT PREDICTABLE\r\n -- included in ICV calculation\r\n Routing (Type 0) [DH98]\r\n\r\n BIT INDICATES IF OPTION IS MUTABLE\r\n (CHANGES UNPREDICTABLY DURING TRANSIT)\r\n Hop-by-Hop options [DH98]\r\n Destination options [DH98]\r\n\r\n NOT APPLICABLE\r\n Fragmentation [DH98]", "notes": "Perhaps it should be formatted as shown above to avoid the overlap of the columns.", "submit_date": "2006-03-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "136", "doc-id": "RFC4296", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.2.1", "orig_text": " void rdma_read(socket_t s, ddp_addr_t s, ddp_addr_t d)", "correct_text": " rdma_read(socket_t s, ddp_addr_t s, length_t l, ddp_addr_t d)", "notes": "This is inconsistent with the detailed description of that primitive\r\ngiven subsequently on page 15 (2nd-to-last list paragraph), which\r\nspecifies four (4) arguments.\r\n\r\nThe latter, detailed spec is the appropriate version.", "submit_date": "2006-01-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "lars.eggert@nokia.com", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3545", "doc-id": "RFC5939", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.4.1", "orig_text": " a=acap:2 a=pcfg:1 t=1 a=1 ;Not allowed to embed \"pcfg\"\r\n", "correct_text": " a=acap:2 pcfg:1 t=1 a=1 ;Not allowed to embed \"pcfg\"\r\n", "notes": "The existing text, with \"a=\" before \"pcfg\", is outright syntactically incorrect per the syntax in the first paragraph of the section. The correction is needed for the text to be the intended demonstration of a semantic error.", "submit_date": "2013-03-11", "submitter_name": "Dale Worley", "verifier_id": "", "verifier_name": "Gonzalo Camarillo", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "143", "doc-id": "RFC4285", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Option Type | Option Length | Subtype |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Mobility SPI |", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Option Type | Option Length | Subtype |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Mobility SPI |\r\n", "notes": "", "submit_date": "2006-02-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "386", "doc-id": "RFC2812", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.3", "orig_text": " 244 RPL_STATSHLINE 244 RPL_STATSSLINE", "correct_text": " 244 RPL_STATSHLINE 245 RPL_STATSSLINE\n", "notes": "", "submit_date": "2003-01-18", "submitter_name": "Konstantin Zemlyak", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "137", "doc-id": "RFC4295", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(7) description too unspecific, and punctuation\r\n\r\nThe DESCRIPTION clause of the mip6HaCompliance2 MODULE-COMPLIANCE,\r\non page 95, says:\r\n\r\n \"The compliance statement for SNMP entities\r\n that implement the MOBILEIPV6-MIB and\r\n support monitoring of the home agent\r\n| functionality specifically the Home Agent List\r\n| and the home-agent-registration-related statistics,\r\n There are a number of INDEX objects [...]\r\n\r\nfor reasons as in item (5) and item (6) above,\r\nit should better say:\r\n\r\n \"The compliance statement for SNMP entities\r\n that implement the MOBILEIPV6-MIB and\r\n| support detailed monitoring of the home agent\r\n| functionality, specifically the Home Agent List\r\n| and the home-agent-registration-related statistics.\r\n There are a number of INDEX objects [...]\r\n\r\n\r\n(8) punctuation, and extraneous blank line\r\n\r\nThe DESCRIPTION clause of the mip6HaCompliance3 MODULE-COMPLIANCE,\r\non page 96, says:\r\n\r\n \"The compliance statement for SNMP entities\r\n that implement the MOBILEIPV6-MIB and\r\n support monitoring and control of the home agent\r\n| functionality specifically the Home Agent List\r\n| and the home-agent-registration-related statistics,\r\n|\r\n There are a number of INDEX objects [...]\r\n\r\nIt should say (see above items for rationale and similarity):\r\n\r\n \"The compliance statement for SNMP entities\r\n that implement the MOBILEIPV6-MIB and\r\n support monitoring and control of the home agent\r\n| functionality, specifically the Home Agent List\r\n| and the home-agent-registration-related statistics.\r\n There are a number of INDEX objects [...]\r\n\r\n\r\n(9) punctuation, and extraneous blank line\r\n\r\nThe DESCRIPTION clause of the mip6HaReadOnlyCompliance2\r\nMODULE-COMPLIANCE, on page 99, says:\r\n\r\n \"The compliance statement for SNMP entities\r\n that implement the MOBILEIPV6-MIB without support\r\n for read-write (i.e., in read-only mode) and\r\n support monitoring of the home agent\r\n| functionality specifically the Home Agent List\r\n and the home-agent-registration-related statistics.\r\n|\r\n There are a number of INDEX objects [...]\r\n\r\nIt should say (see above items for rationale and similarity):\r\n\r\n \"The compliance statement for SNMP entities\r\n that implement the MOBILEIPV6-MIB without support\r\n for read-write (i.e., in read-only mode) and\r\n support monitoring of the home agent\r\n| functionality, specifically the Home Agent List\r\n and the home-agent-registration-related statistics.\r\n There are a number of INDEX objects [...]\r\n\r\n\r\n(10) punctuation, and extraneous blank line\r\n\r\nThe DESCRIPTION clause of the mip6HaReadOnlyCompliance3\r\nMODULE-COMPLIANCE, on page 101, says:\r\n\r\n \"The compliance statement for SNMP entities\r\n that implement the MOBILEIPV6-MIB without support\r\n for read-write (i.e., in read-only mode) and\r\n? support monitoring and control of the home agent\r\n| functionality specifically the Home Agent List\r\n| and the home-agent-registration-related statistics,\r\n|\r\n There are a number of INDEX objects [...]\r\n\r\nIt should say (see above items for rationale and similarity):\r\n\r\n \"The compliance statement for SNMP entities\r\n that implement the MOBILEIPV6-MIB without support\r\n for read-write (i.e., in read-only mode) and\r\n support monitoring and control of the home agent\r\n| functionality, specifically the Home Agent List\r\n| and the home-agent-registration-related statistics.\r\n There are a number of INDEX objects [...]\r\n\r\nFurthermore, arguably the words \"and control\" should better be\r\ndeleted since write access is not required.", "correct_text": "", "notes": "The items below are presented in RFC textual order.\r\nI use change bars ('|' in column 1) and occasionally\r\nup/down pointing marker lines ('^^^'/'vvv') to emphasize\r\nthe location of textual issues and/or proposed corrections.\r\nModified text has been re-adjusted to match RFC formatting\r\nrules, where appropriate.\r\n\r\nfrom pending", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3554", "doc-id": "RFC4447", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5.2", "orig_text": "- Group ID\r\n\r\n An arbitrary 32-bit value that represents a group of PWs that is\r\n used to create groups in the PW space. The group ID is intended\r\n to be used as a port index, or a virtual tunnel index. To\r\n simplify configuration, a particular PW ID at ingress could be\r\n part of the virtual tunnel for transport to the egress router.", "correct_text": "- Group ID\r\n\r\n An arbitrary 32-bit value that represents a group of PWs that is\r\n used to create groups in the PW space. The group ID is intended\r\n to be used as a port index, or a virtual tunnel index. To\r\n| simplify configuration, a particular PW Group ID at ingress could\r\n be part of the virtual tunnel for transport to the egress router.", "notes": "\"PW ID\" should in fact be \"PW Group ID\"", "submit_date": "2006-11-09", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3555", "doc-id": "RFC4447", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5.3.2", "orig_text": "(2nd-to-last paragraph on page 13)\r\n\r\n The PW information length field contains the length of the SAII,\r\n TAII, and AGI, combined in octets. If this value is 0, then it\r\n| references all PWs using the specified grouping ID. In this case,\r\n there are no other FEC element fields (AGI, SAII, etc.) present, nor\r\n any interface parameters TLVs.", "correct_text": " The PW information length field contains the length of the SAII,\r\n TAII, and AGI, combined in octets. If this value is 0, then it\r\n| references all PWs using the grouping ID (specifed in the PW grouping\r\n| ID TLV). In this case, there are no other FEC element fields (AGI,\r\n SAII, etc.) present, nor any interface parameters TLVs.", "notes": "To make the context more clear", "submit_date": "2006-11-09", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3557", "doc-id": "RFC6896", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.1.1", "orig_text": "encoded as a HEX string holding the number\r\nof seconds since the UNIX epoch", "correct_text": "encoded as a DECIMAL string holding the number\r\nof seconds since the UNIX epoch", "notes": "The examples in Appendix A use decimal numbers for ATIME (eg ATIME: 1347265955), not hexadecimal.", "submit_date": "2013-03-18", "submitter_name": "James Manger", "verifier_id": "", "verifier_name": "Nevil Brownlee", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3558", "doc-id": "RFC5661", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "15.1.4.2", "orig_text": "In Table 5 Section 5.1 Page 342, NFS4ERR_DQUOT is defined as error number 69:\r\n\r\n \"| NFS4ERR_DQUOT | 69 | Section 15.1.4.2 |\"\r\n\r\nHowever, in Section 15.1.4.2 Page 349 it is identified as error code 19:\r\n\r\n \"15.1.4.2. NFS4ERR_DQUOT (Error Code 19)\"", "correct_text": " \"15.1.4.2. NFS4ERR_DQUOT (Error Code 69)\"\r\n\r\n", "notes": "I believe NFS4ERR_DQUOT is in fact 69 and the reference to error code 19 in Section 15.1.4.2 is a typo.\r\n\r\nIn RFC 3010, Error Code 19 was assigned to \"NFS4ERR_NODEV\" but that association appears to have suffered the same fate as RFC 3010 itself and there is no mention of NFS4ERR_NODEV in RFC 3530 which rendered that RFC obsolete.", "submit_date": "2013-03-19", "submitter_name": "Cal Turney", "verifier_id": "", "verifier_name": "Martin Stiemerling", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3559", "doc-id": "RFC5655", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.2.1", "orig_text": "(none)", "correct_text": "Units: milliseconds", "notes": "collectionTimeMilliseconds requires units of milliseconds.\r\n\r\nCompare with sections 8.2.7 and 8.2.14 in the same document.\r\n\r\nIANA's IPFIX IE registry requires the corresponding update.", "submit_date": "2013-03-20", "submitter_name": "Paul Aitken", "verifier_id": "", "verifier_name": "Benoit Claise", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3560", "doc-id": "RFC5655", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.2.11 + .18", "orig_text": "(none)", "correct_text": "Range: The valid range is 0-0.", "notes": "8.2.11 messageScope requires a value of 0 (\"The value of this Information Element MUST be written as 0\") but no range is given. The range should say \"0-0\". (Compare with text in RFC 5102).\r\n\r\nSimilarly for 8.2.18 sessionScope.\r\n\r\nNote to IANA: the changes are already done in the IPFIX registry, via the IE doctors (draft-ietf-ipfix-ie-doctors-07 procedure)", "submit_date": "2013-03-20", "submitter_name": "Paul Aitken", "verifier_id": "", "verifier_name": "Benoit Claise", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "138", "doc-id": "RFC4294", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(1) Page 7, Section 4.4\r\n\r\nThe RFC 4294 text says:\r\n\r\n 4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463\r\n\r\n ICMPv6 [RFC-2463] MUST be supported.\r\n\r\nIt should say:\r\n\r\n 4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443\r\n\r\n ICMPv6 [RFC-4443] MUST be supported.\r\n\r\nThe title of Section 4.4 in the Table of Contents should be\r\nadapted accordingly.\r\n\r\nRationale: RFC 4443 (replacing and obsoleting RFC 2463) has been\r\npublished exactly 3 weeks before RFC 4294, and hence should be\r\nused as the currently valid reference.\r\n\r\n\r\n(2) Page 7, Section 4.5.1\r\n\r\nRFC 4294 says:\r\n\r\n 4.5.1. IP Version 6 Addressing Architecture - RFC 3513\r\n\r\n The IPv6 Addressing Architecture [RFC-3513] MUST be supported as\r\n updated by [RFC-3879].\r\n\r\nIt should say:\r\n\r\n 4.5.1. IP Version 6 Addressing Architecture - RFC 4291\r\n\r\n The IPv6 Addressing Architecture [RFC-4291] MUST be supported.\r\n\r\nRationale: RFC 4291 (replacing and obsoleting RFC 3513, and thereby\r\nincorporating RFC 3879) has been published more than 8 weeks before\r\nRFC 4294, and hence should be used as the currently valid reference.\r\n\r\n\r\n(3) Page 8, Section 5.1\r\n\r\nRFC 4294 says:\r\n\r\n DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363],\r\n and [RFC-3596]. [...]\r\n\r\nIt should say:\r\n\r\n DNS is described in [RFC-1034], [RFC-1035], [RFC-3363], and\r\n [RFC-3596]. [...]\r\n\r\nAnd subsequently, where RFC 4294 says,\r\n\r\n - reverse addressing in ip6.arpa using PTR records [RFC-3152];\r\n\r\nit should say:\r\n\r\n - reverse addressing in ip6.arpa using PTR records [RFC-3596];\r\n\r\nRationale: RFC 3152 has been obsoleted and incorporated into RFC 3596.\r\n\r\n\r\n(4) Page 10, Section 6.1.1\r\n\r\nRFC 4294 says:\r\n\r\n 6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893\r\n\r\nIt should say:\r\n\r\n 6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 4213\r\n\r\nRationale: RFC 4213 (replacing and obsoleting RFC 2893) has been\r\npublished more than 6 months before RFC 4294, and hence should be\r\nused consistently as the currently valid reference. (The text body\r\nof the section has been updated accordingly, before publication.)\r\n\r\n\r\n(5) Page 11, Section 8.2\r\n\r\nRFC 4294 says:\r\n\r\n 8.2. Security Protocols\r\n\r\n ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported.\r\n\r\nIt should say:\r\n\r\n 8.2. Security Protocols\r\n\r\n ESP [RFC-4303] MUST be supported. AH [RFC-4302] MAY be supported.\r\n\r\nRationale: The new IPsec RFCs purposely have changed the requirement\r\nlevel for AH. From RFC 4301, page 9, 1st paragraph of Section 3.2 :\r\n\r\n [...] IPsec implementations MUST support ESP and MAY\r\n support AH. (Support for AH has been downgraded to MAY because\r\n experience has shown that there are very few contexts in which ESP\r\n cannot provide the requisite security services. Note that ESP can be\r\n used to provide only integrity, without confidentiality, making it\r\n comparable to AH in most contexts.)\r\n\r\nIn Section 13, RFC 4301 lists the differences from RFC 2401,\r\nand it states on page 74:\r\n\r\n o Support for AH in both IPv4 and IPv6 is no longer required.\r\n\r\nRFC 4294 does not give any arguments to override these statements.\r\n\r\n(The IPsec references in RFC 4294 apparently have been changed\r\n shortly before publication without due adaptation of the text.)\r\n\r\n\r\n(6) Section 12.1, Normative References :\r\n\r\n- The reference [RFC-2463] should be replaced by a reference to\r\n RFC 4443 according to item (1) above.\r\n\r\n- The reference [RFC-3152] (last item on page 14) should be deleted.\r\n That RFC has been obsoleted long time ago, and the material has been\r\n incorporated into RFC 3596 (see the entry [RFC-3596] on page 15)\r\n according to item (3) above.\r\n\r\n- The reference [RFC-3513] should be replaced by an entry [RFC-4291],\r\n containing the proper reference to RFC 4291, according to item (2)\r\n above.\r\n\r\n- The reference [RFC-3879] is not needed any more according to\r\n item (2) above; the material from RFC 3879 has been incorporated\r\n into RFC 4291, the successor of RFC 3513 -- see item (2) above.", "correct_text": "", "notes": "from pending\n --VERIFIER NOTES-- \nThis RFC is obsolete and new implementations should be referring to RFC 6434. ", "submit_date": "2006-04-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "139", "doc-id": "RFC4294", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.1", "orig_text": " Those nodes are NOT RECOMMENDED to support the experimental A6 and\r\n DNAME Resource Records [RFC-3363].\r\n", "correct_text": " Those nodes are NOT RECOMMENDED to support the experimental A6\r\n Resource Records [RFC-3363].\r\n", "notes": "", "submit_date": "2006-04-11", "submitter_name": "Mark Andrews", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "140", "doc-id": "RFC4293", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2.11", "orig_text": " The circumstances used in the compliance section are implementing\r\n IPv4, IPv6, or IPv6 router functions and having a bandwidth of less\r\n than 20MB, between 20MB and 650MB, or greater than 650MB.", "correct_text": " The circumstances used in the compliance section are implementing\r\n IPv4, IPv6, or IPv6 router functions and having a bandwidth of less\r\n| than 20Mbps, between 20Mbps and 650Mbps, or greater than 650Mbps.", "notes": "from pending", "submit_date": "2006-07-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2484", "doc-id": "RFC4875", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.2", "orig_text": "Erratum created by duplication from multipart Erratum 961 raised by Alfred Hoenes.\r\n\r\n(4) Section 6.2 -- missing article\r\n\r\nThe second paragraph of Section 6.2, on mid-page 17, says:\r\n\r\n [...]. When the integrity bit is set\r\n| in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent\r\n upstream until all Resv messages have been received from the\r\n downstream neighbors.\r\n\r\nMissing indefinite article.", "correct_text": " [...]. When the integrity bit is set\r\n| in the LSP_REQUIRED_ATTRIBUTE object, a Resv message MUST NOT be sent\r\n upstream until all Resv messages have been received from the\r\n downstream neighbors.\r\n", "notes": "", "submit_date": "2007-05-15", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3546", "doc-id": "RFC4122", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1.3", "orig_text": "The version number is in the most significant 4 bits of the time\r\nstamp (bits 4 through 7 of the time_hi_and_version field).", "correct_text": "The version number is in the most significant 4 bits of the time\r\nstamp (bits 0 through 3 of the time_hi_and_version field).", "notes": "We use network order (as far as I know, we use network order in this RFC both for bits and bytes). So, the most significant bits comes first and they are located in first bytes. So, 0 through 3.\r\n\r\n---VERIFIER NOTES ---\r\nThis erratum is correct as far as it goes, but, given other text in the RFC, so is erratum 1957. There is a pervasive problem in this RFC with inconsistent and unclear usage of bit numbering, which switches between several conventions. The diagram in Section 4.1.2 uses left-to-right bit numbering (the most significant bit is numbered 0), but much of the text (such as in Section 4.2.2) uses right-to-left bit numbering (the least significant bit is numbered 0). Most of the text uses big-ending byte order (network byte order), but some seems to assume little-ending, probably mistakes that come from the authors' familiarity with that convention.\r\n\r\nWith respect to the text in question, the first sentence of Section 4.1.3, we have the following situation:\r\n\r\n- The original text is correct if we assume right-to-left bit numbering and little-endian byte order.\r\n\r\n- Erratum 1957 is correct if we assume right-to-left bit numbering and big-endian byte order. This change also makes the first sentence of Section 4.1.3 consistent with the sixth bullet in Section 4.2.2.\r\n\r\n- Erratum 3546 is correct if we assume left-to-right bit numbering and big-endian byte order.\r\n\r\nIn the end, the real point is that this document needs a revision that carefully and thoroughly fixes every instance of byte numbering (or removes the byte numbering and refers only to \"most significant\" and \"least significant\"). Such a revision should also double-check the sample code in Appendix A to be sure it works in both big-ending and little-endian machines.\r\n\r\nHappily, it's not likely that misunderstandings here will cause actual interoperability problems: this isn't a situation where things need to be disassembled and reassembled. The algorithm merely turns a UUID into a URN, and the URN is thereafter a \"black box\", an unchanged identifier. The only issue would be whether different interpretations of the document would turn two different UUIDs into the same URN, and, given the number of bits involved, the likelihood of collisions in practice is small.", "submit_date": "2013-03-14", "submitter_name": "Askar Safin", "verifier_id": "", "verifier_name": "Barry Leiba", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3547", "doc-id": "RFC6844", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "s7.2", "orig_text": "auth Reserved [HB2011]\r\npath Reserved [HB2011]\r\npolicy Reserved [HB2011]", "correct_text": "auth Reserved [RFC6844]\r\npath Reserved [RFC6844]\r\npolicy Reserved [RFC6844]", "notes": "Better to use the datatracker history to find the values than the expired drafts.", "submit_date": "2013-03-15", "submitter_name": "Sean Turner", "verifier_id": "", "verifier_name": "Stephen Farrell", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3548", "doc-id": "RFC4295", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": "(in the DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE\r\ndeclaration, in the 12th line on page 28)\r\n\r\nThis object is a 64-bit version of mip6NodeOutOctets.", "correct_text": "This object is a 64-bit version of mip6NodeOutPkts.", "notes": "The DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE\r\ndeclaration, on page 28 of RFC 4295, apparently has been\r\ncloned from another object without proper editing, and thus\r\nrefers to a wrong object, mip6NodeOutOctets, where it should\r\nrefer to the object, mip6NodeOutPkts.", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3580", "doc-id": "RFC6550", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.9.1", "orig_text": " 1. Let C1 send a DAO containing a Target T with a Path Control\r\n 10000000b. Node N stores an entry associating 10000000b with\r\n the Path Control field for C1 and Target T.\r\n\r\n 2. Let C2 send a DAO containing a Target T with a Path Control\r\n 00010000b. Node N stores an entry associating 00010000b with\r\n the Path Control field for C1 and Target T.\r\n\r\n 3. Let C3 send a DAO containing a Target T with a Path Control\r\n 00001100b. Node N stores an entry associating 00001100b with\r\n the Path Control field for C1 and Target T.", "correct_text": " 1. Let C1 send a DAO containing a Target T with a Path Control\r\n 10000000b. Node N stores an entry associating 10000000b with\r\n the Path Control field for C1 and Target T.\r\n\r\n 2. Let C2 send a DAO containing a Target T with a Path Control\r\n 00010000b. Node N stores an entry associating 00010000b with\r\n the Path Control field for C2 and Target T.\r\n\r\n 3. Let C3 send a DAO containing a Target T with a Path Control\r\n 00001100b. Node N stores an entry associating 00001100b with\r\n the Path Control field for C3 and Target T.", "notes": "Bullet 2 and 3 seem wrong. I believe \"C1\" should be replaced by \"C2\" in bullet 2 and \"C1\" should be replaced by \"C3\" in bullet 3.\r\n\r\nThis issue was initially reported by Federico Consoli on the ROLL WG mailing list.", "submit_date": "2013-04-04", "submitter_name": "Tony Cheneau", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "141", "doc-id": "RFC4288", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2.2", "orig_text": " A Media type of \"image\" indicates that the content specifies or more\r\n separate images that require appropriate hardware to display. ...", "correct_text": " A Media type of \"image\" indicates that the content specifies one or\r\n more separate images that require appropriate hardware to display.\r\n ...\r\n", "notes": "", "submit_date": "2005-12-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "142", "doc-id": "RFC4286", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1.2", "orig_text": " 3.1.2. AdvertisementJitter\r\n\r\n This is the maximum time (in seconds) by which the\r\n AdvertisementInterval is perturbed for each unsolicited\r\n Advertisement. Note that the purpose of this jitter is to avoid\r\n synchronization of multiple routers on a network, hence choosing a\r\n value of zero is discouraged. This value MUST be an integer no less\r\n than 0 seconds and no greater than AdvertisementInterval.\r\n\r\n The AdvertisementJitter MUST be 0.025*AdvertisementInterval .", "correct_text": " 3.1.2. AdvertisementJitter\r\n\r\n This is the maximum time (in seconds) by which the\r\n AdvertisementInterval is perturbed for each unsolicited\r\n Advertisement. Note that the purpose of this jitter is to avoid\r\n synchronization of multiple routers on a network.\r\n The value of AdvertisementJitter is not independently configurable;\r\n it is a variable derived internally within the implementation\r\n from the configured value for AdvertisementInterval.\r\n\r\n The AdvertisementJitter MUST be set to 0.025*AdvertisementInterval.\r\n", "notes": "", "submit_date": "2005-12-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "400", "doc-id": "RFC2663", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.6", "orig_text": " the NAT device cannot safely assume that the segments containing\n FINs or SYNs will be the last packets of the session (i.e., there\n could be retransmissions).", "correct_text": " the NAT device cannot safely assume that the segments containing\n FINs or RSTs will be the last packets of the session (i.e., there\n could be retransmissions).\n", "notes": "", "submit_date": "2002-11-14", "submitter_name": "Javier Waisbrot", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "401", "doc-id": "RFC2661", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": "SSHTRESH", "correct_text": "SSTHRESH\r\n", "notes": "Occurs 3 times.\r\n\r\nfrom pending", "submit_date": "2007-03-17", "submitter_name": "Ming Deng", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "402", "doc-id": "RFC2656", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": " [2] The Harvest Information Discovery and Access System:\n ", "correct_text": " [2] Harvest: A distributed Search System:\n \n", "notes": "", "submit_date": "2002-09-04", "submitter_name": "Kang-Jin Lee", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4322", "doc-id": "RFC7511", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": "", "correct_text": "Additional security considerations of overexposure to solar \r\nradiation, or buffer-bloat in culturally important places, \r\nleading to excessive delayed packets, directly attributed\r\nto forgetting sunscreen, excessive adult beverages, etc, \r\nWILL result in a decreased reliability.\r\n\r\nThere are no actions requested at this time.", "notes": "", "submit_date": "2015-04-01", "submitter_name": "Joe Klein", "verifier_id": "", "verifier_name": "Nevil Brownlee", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "148", "doc-id": "RFC4274", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "\r\nThe final paragraph on page 8,\r\n\r\n The following table illustrates typical memory requirements of a\r\n router running BGP. We denote the average number of routes\r\n advertised by each peer as N, the total number of unique AS paths as\r\n A, the mean AS distance of the Internet as M (distance at the level\r\n of an autonomous system, expressed in terms of the number of\r\n autonomous systems), the number of octets required to store a network\r\n as R, and the number of bytes required to store one AS in an AS path\r\n| as P. It is assumed that each network is encoded as four bytes, each\r\n AS is encoded as two bytes, and each networks is reachable via some\r\n| fraction of all the peers (# BGP peers/per net). For purposes of the\r\n| estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).\r\n ^^^^ ^^^^\r\n\r\nand the table on page 9,\r\n vvvvvvvvvvvvvvvvvvv\r\n| # Networks Mean AS Distance # ASes # BGP peers/per net Memory Req\r\n| (N) (M) (A) (P) (MR)\r\n ---------- ---------------- ------ ------------------- -------------\r\n 100,000 20 3,000 20 10,400,000\r\n 100,000 20 15,000 20 20,000,000\r\n 120,000 10 15,000 100 78,000,000\r\n 140,000 15 20,000 100 116,000,000\r\n\r\nexhibit additional issues:\r\n\r\n- The text defines 'P' as\r\n \"the number of bytes required to store one AS in an AS path\"\r\n while apparently in the table (P) means\r\n \"# BGP peers/per net\".\r\n\r\n- 'S' in the formula in the last line of page 9 is not defined\r\n anywhere in the text.\r\n\r\n- \"# BGP peers/per net\" IMHO does not even make sense in the\r\n context of BGP, since BGP speakers represent ASes, not networks\r\n (prefixes).\r\n\r\nI do not have a proposal for an easy way to get rid of these\r\ninconsistencies.\r\nPlease check.\r\n\r\n", "correct_text": "", "notes": "There is clearly a problem with the text, but it does not impact interoperability and should be looked at when the RFC is revised.", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3778", "doc-id": "RFC4456", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": "The Non-Client peer must be fully meshed but the Client\r\n peers need not be fully meshed.", "correct_text": "The Non-Client peers must be fully meshed but the Client\r\n peers need not be fully meshed.", "notes": "This is a typo. Figure 4 shows multiple Non-Client peers.\r\nBut the text is referring to \"The Non-Client peer\". It should be\r\n\"The Non-Client peers\".", "submit_date": "2013-10-30", "submitter_name": "Ramakrishna DTV", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3777", "doc-id": "RFC4274", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "\r\n(5) like (4)\r\n\r\nSection 6.1.2, on page 8, exhibits similar symptoms as noted above.\r\nThe RFC says:\r\n\r\n To quantify the worst-case memory requirements for BGP, we denote the\r\n total number of networks in the Internet as N, the mean AS distance\r\n of the Internet as M (distance at the level of an autonomous system,\r\n expressed in terms of the number of autonomous systems), the total\r\n number of unique AS paths as A. Then the worst-case memory\r\n requirements (MR) can be expressed as\r\n\r\n MR = O(N + (M * A))\r\n\r\n Because a mean AS distance M is a slow moving function of the\r\n interconnectivity (\"meshiness\") of the Internet, for all practical\r\n purposes the worst-case router memory requirements are on the order\r\n| of the total number of networks in the Internet multiplied by the\r\n| number of peers that the local system is peering with. [...]\r\n\r\nApparently, the first part of that text has been revised eliminating\r\nthe role of the peering count. Thus the last sentence should have\r\nbeen updated accordingly, to make it match the new formula.\r\n\r\nThe second paragraph thus perhaps should say:\r\n\r\n Because a mean AS distance M is a slow moving function of the\r\n interconnectivity (\"meshiness\") of the Internet, for all practical\r\n purposes the worst-case router memory requirements are on the order\r\n| of the total number of networks in the Internet. [...]\r\n\r\n\r\n", "correct_text": "", "notes": "from errata 148\r\n\r\nRather than follow this suggestion (and drop the number of peers term out of the prose) it may be more would be more accurate to insert a number of peers term into the formula, e.g. MR = O(P * (N + (M * A))), where P is the number of peers.\r\n\r\nThis does not impact interoperability and thus should be looked at in any future update of the RFC.", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2586", "doc-id": "RFC2045", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1.", "orig_text": " All of the header fields defined in this document are subject to the\r\n general syntactic rules for header fields specified in RFC 822. In\r\n particular, all of these header fields except for Content-Disposition\r\n can include RFC 822 comments, which have no semantic content and\r\n should be ignored during MIME processing.\r\n\r\n", "correct_text": " All of the header fields defined in this document are subject to the\r\n general syntactic rules for header fields specified in RFC 822. In\r\n particular, all of these header fields\r\n can include RFC 822 comments, which have no semantic content and\r\n should be ignored during MIME processing.\r\n\r\n", "notes": "A header field Content-Disposition is not defined in this document. Therefore, the header fields defined in this document do not contain a field Content-Disposition and the exception is not necessary. It is also misleading because it looks as if the exception affected the Content-Disposition field defined in RFC2813 while it does not.", "submit_date": "2010-10-28", "submitter_name": "Christopher Yeleighton", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2587", "doc-id": "RFC5303", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2", "orig_text": "Add a clause e) to the end of \"Sending point-to-point IIH PDUs\" (section 8.2.3 of [ISIS]):\r\n\r\n", "correct_text": "Add a clause e) to the end of \"Sending point-to-point IIH PDUs\" (section 8.2.4 of [ISIS]):\r\n", "notes": "Though the ISIS reference name in \"Normative References\" have been updated to \"International Standard 10589:2002, Second Edition, 2002\" , the section reference was still to first edition of ISO/IEC 10589", "submit_date": "2010-10-29", "submitter_name": "Mohammad Fahad Imteyaz", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2588", "doc-id": "RFC5303", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2", "orig_text": "The current three-way \r\nstate of the adjacency with its neighbor on the link (as defined \r\nin new section 8.2.4.1.1 introduced later in the document) SHALL \r\nbe reported in the Adjacency Three-Way State field.", "correct_text": "The current three-way \r\nstate of the adjacency with its neighbor on the link (as defined \r\nin new section 8.2.5.1.1 introduced later in the document) SHALL \r\nbe reported in the Adjacency Three-Way State field.", "notes": "Though the ISIS reference name in \"Normative References\" have been updated to \"International Standard 10589:2002, Second Edition, 2002\" , the section reference was still to first edition of ISO/IEC 10589.", "submit_date": "2010-10-29", "submitter_name": "Mohammad Fahad Imteyaz", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2589", "doc-id": "RFC5303", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.2", "orig_text": "Add a section 8.2.4.1.1, \"Three-Way Handshake\", immediately prior to \"IIH PDU Processing\" (section 8.2.4.2 of [ISIS]):\r\n", "correct_text": "Add a section 8.2.5.1.1, \"Three-Way Handshake\", immediately prior to \"IIH PDU Processing\" (section 8.2.5.2 of [ISIS]):", "notes": "Though the ISIS reference name in \"Normative References\" have been updated to \"International Standard 10589:2002, Second Edition, 2002\" , the section reference was still to first edition of ISO 10589.", "submit_date": "2010-10-29", "submitter_name": "Mohammad Fahad Imteyaz", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "403", "doc-id": "RFC2655", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": " [2] The Harvest Information Discovery and Access System:\n ", "correct_text": " [2] Harvest: A distributed Search System:\n \n", "notes": "", "submit_date": "2002-09-04", "submitter_name": "Kang-Jin Lee", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3776", "doc-id": "RFC4274", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(4) inconsistency in updated text\r\n\r\nThe text of section 6.1 has been revised substantially from its\r\npredecessor, RFC 1774. Unfortunately, the modifications have\r\nnot been performed incompletely, leading to near-nonsense text.\r\nSection 6.1, on page 7, says:\r\n\r\n Immediately after the initial BGP connection setup, BGP peers\r\n exchange complete sets of routing information. If we denote the\r\n total number of routes in the Internet as N, the total path\r\n attributes (for all N routes) received from a peer as A, and assume\r\n that the networks are uniformly distributed among the autonomous\r\n systems, then the worst-case amount of bandwidth consumed during the\r\n| initial exchange between a pair of BGP speakers (P) is\r\n\r\n| BW = O((N + A) * P)\r\n ^^^^ ^^^^^\r\n\r\nThis makes no sense -- obviously you can't multiply by a non-numeric\r\nquantity P, \"a pair of BGP speakers\".\r\n\r\nI strongly suspect that it was the intention to say:\r\n\r\n Immediately after the initial BGP connection setup, BGP peers\r\n exchange complete sets of routing information. If we denote the\r\n total number of routes in the Internet as N, the total path\r\n attributes (for all N routes) received from a peer as A, and assume\r\n that the networks are uniformly distributed among the autonomous\r\n systems, then the worst-case amount of bandwidth consumed during the\r\n| initial exchange between a pair of BGP speakers is\r\n\r\n| BW = O((N + A))\r\n\r\nPlease verify.\r\n\r\n\r\n", "correct_text": "", "notes": "from errata 148\r\n\r\nThis has no impact on interoperability. It should be looked at on any update of the RFC.", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3775", "doc-id": "RFC4274", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "", "orig_text": "\r\n(7) some Ref's inappropriately named Normative\r\n\r\nThe References \"[BGP-VULN]\" and \"[SBGP]\" do not fulfill the\r\ncriteria for being used as Normative References.\r\nTheir inclusion in Section 11.1, on page 14, might formally be\r\nseen as inhibiting the progress of BGP-4 on the Standards Track.", "correct_text": "", "notes": "This was considered OK by the IETF and IESG of the time.\n --VERIFIER NOTES-- \nThe status of these references will have been considered by the IETF and the IESG of the time. The authors and reviewers of any future BGP document will evaluate the correct status of the references that they use.", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "6809", "doc-id": "RFC8986", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.10", "orig_text": "When N receives a packet whose IPv6 DA is S and S is a local End.DX2\r\nSID", "correct_text": "When N receives a packet whose IPv6 DA is S and S is a local End.DX2V\r\nSID\r\n", "notes": "Looks like a typo in the original text", "submit_date": "2022-01-05", "submitter_name": "Yuya Kawakami", "verifier_id": "", "verifier_name": "Andrew Alston", "update_date": "2022-05-26 13:30:42"}, {"errata_id": "2590", "doc-id": "RFC5303", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.2", "orig_text": " A received Point-to-Point IIH PDU may or may not contain the\r\n Point-to-Point Three-Way Adjacency option. If it does not, the\r\n link is assumed to be functional in both directions, and the\r\n procedures described in section 8.2.4.2 are followed.\r\n", "correct_text": " A received Point-to-Point IIH PDU may or may not contain the\r\n Point-to-Point Three-Way Adjacency option. If it does not, the\r\n link is assumed to be functional in both directions, and the\r\n procedures described in section 8.2.5.2 are followed.\r\n", "notes": "Though the ISIS reference name in \"Normative References\" have been updated to \"International Standard 10589:2002, Second Edition, 2002\" , the section reference was still to first edition of ISO 10589.", "submit_date": "2010-10-29", "submitter_name": "Mohammad Fahad Imteyaz", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2591", "doc-id": "RFC5303", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.2", "orig_text": " If the Neighbor System ID and Neighbor Extended Local Circuit ID\r\n fields match those of the local system, or are not present, the\r\n procedures described in section 8.2.4.2 are followed with the\r\n following changes:\r\n", "correct_text": " If the Neighbor System ID and Neighbor Extended Local Circuit ID\r\n fields match those of the local system, or are not present, the\r\n procedures described in section 8.2.5.2 are followed with the\r\n following changes:\r\n", "notes": "Though the ISIS reference name in \"Normative References\" have been updated to \"International Standard 10589:2002, Second Edition, 2002\" , the section reference was still to first edition of ISO 10589.", "submit_date": "2010-10-29", "submitter_name": "Mohammad Fahad Imteyaz", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "150", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.1.1", "orig_text": "The Phase 1 decision function is a separate process,f which completes \r\nwhen it has no further work to do.", "correct_text": "The Phase 1 decision function is a separate process, which completes \r\nwhen it has no further work to do.\r\n", "notes": "Clearly an editorial issue with a stray \"f\" in there. \r\n", "submit_date": "2006-01-26", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Ketan Talaulikar", "update_date": "2025-05-28 12:09:55"}, {"errata_id": "152", "doc-id": "RFC4253", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "12", "orig_text": " SSH_MSG_DISCONNECT 1\r\n SSH_MSG_IGNORE 2\r\n SSH_MSG_UNIMPLEMENTED 3\r\n SSH_MSG_DEBUG 4\r\n SSH_MSG_SERVICE_REQUEST 5\r\n SSH_MSG_SERVICE_ACCEPT 6\r\n SSH_MSG_KEXINIT 20\r\n SSH_MSG_NEWKEYS 21\r\n", "correct_text": " SSH_MSG_DISCONNECT 1\r\n SSH_MSG_IGNORE 2\r\n SSH_MSG_UNIMPLEMENTED 3\r\n SSH_MSG_DEBUG 4\r\n SSH_MSG_SERVICE_REQUEST 5\r\n SSH_MSG_SERVICE_ACCEPT 6\r\n SSH_MSG_KEXINIT 20\r\n SSH_MSG_NEWKEYS 21\r\n SSH_MSG_KEXDH_INIT 30\r\n SSH_MSG_KEXDH_REPLY 3\r\n", "notes": "\n --VERIFIER NOTES-- \nErrata IDs 152 and 1408 are combined to 1486.", "submit_date": "2006-01-23", "submitter_name": "denis bider", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "153", "doc-id": "RFC4241", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.5", "orig_text": " The CPE should return ICMPv6 Destination Unreachable message to\r\n a source address or silently discard the packets, when the original\r\n packet is destined for the unassigned prefix in the delegated prefix.", "correct_text": " The CPE should return an ICMPv6 Destination Unreachable message\r\n to the source address or silently discard the packet when the original\r\n packet is destined for an unassigned prefix in the delegated prefix.\r\n", "notes": "", "submit_date": "2005-12-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Bob Braden", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "349", "doc-id": "RFC3030", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": " The following dialogue illustrates the use of the large message\n extension to send a BINARYMIME object to two recipients using the\n CHUNKING and PIPELINING extensions:\n\n R: \n R: 220 cnri.reston.va.us SMTP service ready\n S: EHLO ymir.claremont.edu\n R: 250-cnri.reston.va.us says hello\n R: 250-PIPELINING\n R: 250-BINARYMIME\n R: 250 CHUNKING\n S: MAIL FROM: BODY=BINARYMIME\n S: RCPT TO:\n S: RCPT TO:\n R: 250 ... Sender and BINARYMIME ok\n R: 250 ... Recipient ok\n R: 250 ... Recipient ok\n S: BDAT 100000\n S: (First 10000 octets of canonical MIME message data)", "correct_text": "", "notes": "You can see the last line is missing a 0.\n", "submit_date": "2003-01-14", "submitter_name": "Emmanuel Papirakis", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3788", "doc-id": "RFC4960", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.1", "orig_text": " An endpoint shall keep a counter on the total number of consecutive\r\n retransmissions to its peer (this includes retransmissions to all the\r\n destination transport addresses of the peer if it is multi-homed),\r\n including unacknowledged HEARTBEAT chunks. \r\n", "correct_text": "An endpoint shall keep a counter on the total number of consecutive\r\nretransmissions to its peer (this includes data retransmissions \r\nto all the destination transport addresses of the peer if it is \r\nmulti-homed),including the number of unacknowledged HEARTBEAT \r\nchunks observed on the path which currently is used for data \r\ntransfer. Unacknowledged HEARTBEAT chunks observed on paths \r\ndifferent from the path currently used for data transfer shall \r\nnot increment the association error counter, as this could lead \r\nto association closure even if the path which \r\ncurrently is used for data transfer is available (but idle). \r\n", "notes": "RFC4960 Endpoint Failure detection mechanism is deficient in that \r\nHB failures on some failing paths may take the association down, even \r\nif other paths are working perfectly, but simply at the time no data \r\nor HBs are being sent on the working paths.\r\n\r\nThe situation occurs when the association is idle \r\n(no data is being transmitted) and the HBI settings on \r\nthe failing paths are much more aggressive than the HBI \r\nset on the working paths. RFC6458 allows for specification \r\nof the HBI on a per destination address whereby\r\nsuch in-homogeneous setting of the HBI can occur.\r\n\r\nThe solution proposed to the issue is to demand that\r\nHB failures observed on paths different from the path \r\ncurrently used for data transfer do\r\nnot contribute to the association error counter. \r\nHB failures observed on the path currently used for \r\ndata transfer, when this path is idle, \r\n shall contribute to the association error counter. \r\nThereby supporting Endpoint Failure detection when the\r\nassociation is idle. When the association is transmitting data, \r\nthe fate of the data transmissions and retransmissions \r\nwill serve to instantiate Endpoint Failure detection.", "submit_date": "2013-11-06", "submitter_name": "Karen Nielsen", "verifier_id": "", "verifier_name": "Martin Stiemerling", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3774", "doc-id": "RFC4274", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "\r\n(6) typos / grammar\r\n\r\nIn Section 10, the second paragraph on page 13 says:\r\n\r\n| BGP uses TCP MD5 option for validating data and protecting against\r\n spoofing of TCP segments exchanged between its sessions. The usage\r\n of TCP MD5 option for BGP is described at length in [RFC2385]. The\r\n TCP MD5 Key management is discussed in [RFC3562]. BGP data\r\n| encryption is provided using the IPsec mechanism, which encrypts the\r\n| IP payload data (including TCP and BGP data). The IPsec mechanism\r\n| can be used in both the transport mode and the tunnel mode. The\r\n| IPsec mechanism is described in [RFC2406]. Both the TCP MD5 option\r\n| and the IPsec mechanism are not widely deployed security mechanisms\r\n for BGP in today's Internet. Hence, it is difficult to gauge their\r\n| real performance impact when using with BGP. However, because both\r\n| the mechanisms are TCP- and IP-based security mechanisms, the Link\r\n Bandwidth, CPU utilization and router memory consumed by BGP would be\r\n| the same as any other TCP- and IP-based protocols.\r\n\r\nIt should say, correcting grammar and unclear semantics:\r\n\r\n| BGP uses the TCP MD5 option for validating data and protecting\r\n against spoofing of TCP segments exchanged between its sessions. The\r\n usage of TCP MD5 option for BGP is described at length in [RFC2385].\r\n The TCP MD5 Key management is discussed in [RFC3562]. BGP data\r\n| encryption is provided using the IPsec ESP mechanism, which encrypts\r\n| the IP payload data (including TCP and BGP data). The IPsec ESP\r\n| mechanism can be used in both transport mode and tunnel mode. The\r\n| IPsec ESP mechanism is described in [RFC2406]. Both the TCP MD5\r\n| option and IPsec ESP are not widely deployed security mechanisms\r\n for BGP in today's Internet. Hence, it is difficult to gauge their\r\n| real performance impact when used with BGP. However, because both\r\n| mechanisms are TCP- and IP-based security mechanisms, the Link\r\n Bandwidth, CPU utilization and router memory consumed by BGP would be\r\n the same as any for other TCP- and IP-based protocols.\r\n\r\n(I am in doubt whether the last sentence is appropriate;\r\n at least, \"the same as\" should better be replaced by \"similar as\".\r\n Preferrably, I would delete that sentence.)\r\n\r\nFinally, the 4th paragraph on page 13,\r\n v\r\n| Such flexible TCP- and IP-based security mechanisms, allow BGP to\r\n prevent insertion/deletion/modification of BGP data, any snooping of\r\n the data, session stealing, etc. [...]\r\n\r\nshould say:\r\n\r\n| Such flexible TCP- and IP-based security mechanisms allow BGP to\r\n prevent insertion/deletion/modification of BGP data, any snooping of\r\n the data, session stealing, etc. [...]\r\n\r\n\r\n", "correct_text": "", "notes": "from errata 148", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3773", "doc-id": "RFC4274", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(3) typos (multiple missing articles)\r\n\r\nSection 4 of RFC 4274, on page 6, says:\r\n\r\n Whenever a BGP speaker detects an error in a peer connection, it\r\n shuts down the peer and changes its FSM state to IDLE. BGP speaker\r\n requires a Start event to re-initiate an idle peer connection. If\r\n the error remains persistent and BGP speaker generates a Start event\r\n automatically, then it may result in persistent peer flapping.\r\n Although peer oscillation is found to be wide-spread in BGP\r\n implementations, methods for preventing persistent peer oscillations\r\n are outside the scope of base BGP specification.\r\n\r\n\r\n", "correct_text": "It should say:\r\n\r\n Whenever a BGP speaker detects an error in a peer connection, it\r\n| shuts down the peer and changes its FSM state to IDLE. A BGP speaker\r\n requires a Start event to re-initiate an idle peer connection. If\r\n| the error remains persistent and the BGP speaker generates a Start\r\n event automatically, then it may result in persistent peer flapping.\r\n Although peer oscillation is found to be wide-spread in BGP\r\n implementations, methods for preventing persistent peer oscillations\r\n| are outside the scope of the base BGP specification.\r\n\r\n", "notes": "from errata 148", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3772", "doc-id": "RFC4274", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(2) typo\r\n\r\nSection 2.3 contains (on page 5) the state description:\r\n\r\n ACTIVE: State in which BGP peer is trying to acquire a peer\r\n| by listening and accepting TCP connection.\r\n\r\n\r\n\r\n", "correct_text": " ACTIVE: State in which BGP peer is trying to acquire a peer\r\n| by listening and accepting a TCP connection.\r\n ^^^\r\n\r\n(An alternative correction, replacing 'connection' by 'connections',\r\n does not precisely reflect the desired behaviour.)\r\n\r\n\r\n", "notes": "from errata 148", "submit_date": "2006-07-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2581", "doc-id": "RFC5797", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " | STOU | base | Store Unique | a | o | 959, 1123 |", "correct_text": " | STOU | base | Store Unique | s | o | 959, 1123 |", "notes": "RFC0959 has defined STOU as FTP (S)ervice command, but not (A)ccess Control command", "submit_date": "2010-10-19", "submitter_name": "VicTor Smirnoff", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2582", "doc-id": "RFC3447", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "8.1.2", "orig_text": " 4. If Result = \"consistent,\" output \"valid signature.\" Otherwise,\r\n output \"invalid signature.\"", "correct_text": " 4. If Result = \"consistent\", output \"valid signature\". Otherwise,\r\n output \"invalid signature\".", "notes": "This report acually addresses a previous report, EID=2177,\r\nand provides an improved version of the corrected text.\r\n\r\nNote to Verifier: Please merge this Errata Note with EID=2177;\r\n i.e. update the Corrected Text there as shown above, and reject\r\n this Errata Note.", "submit_date": "2010-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2583", "doc-id": "RFC5518", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.1", "orig_text": "If the DKIM signature contains an i= field, the domain name from\r\nthat field is used; otherwise, the domain name from the DKIM\r\nsignature d= field is used.", "correct_text": "The domain name from the DKIM signature d= field is used.", "notes": "RFC 5672 clarifies that the d= domain is the primary identity in a DKIM signature.", "submit_date": "2010-10-26", "submitter_name": "John Levine", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5003", "doc-id": "RFC4960", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "10.1", "orig_text": " o Receive Unacknowledged Message\r\n\r\n Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer\r\n size, [,stream id] [, stream sequence number] [,partial\r\n flag] [,payload protocol-id])", "correct_text": " O) Receive Unacknowledged Message\r\n\r\n Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer\r\n size, [,stream id] [, stream sequence number] [,partial\r\n flag] [,payload protocol-id])", "notes": "This is part of a lettered list of items, and surrounding sublists use lowercase \"o\" as a bullet. This item appears to have been mis-corrected to an \"o\" sublist item when it should be item \"O)\" of the primary list, as evidenced by the preceding item \"N)\" and following \"P)\"", "submit_date": "2017-04-24", "submitter_name": "Max Mattes", "verifier_id": "", "verifier_name": "Spencer Dawkins", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "154", "doc-id": "RFC4240", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.3", "orig_text": " A number of MIME registrations, which could be used here, have\r\n parameters, for instance, video/DV. To accommodate this, and retain\r\n compatibility with the SIP URI structure, the MIME-type parameter\r\n separator (semicolon, %3b) and value separator (equal, %d3) MUST be\r\n escaped. For example: ^^^\r\n\r\n sip:annc@ms.example.net; \\\r\n play=file://fs.example.net//clips/my-intro.dvi; \\\r\n content-type=video/mpeg%3bencode%d3314M-25/625-50", "correct_text": " A number of MIME registrations, which could be used here, have\r\n parameters, for instance, video/DV. To accommodate this, and retain\r\n compatibility with the SIP URI structure, the MIME-type parameter\r\n separator (semicolon, %3b) and value separator (equal, %3d) MUST be\r\n escaped. For example:\r\n\r\n sip:annc@ms.example.net; \\\r\n play=file://fs.example.net//clips/my-intro.dvi; \\\r\n content-type=video/mpeg%3bencode%3d314M-25/625-50\r\n", "notes": "", "submit_date": "2006-01-23", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "155", "doc-id": "RFC4238", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": " This specification registers the E2U+VPIM and E2U+Voice services\r\n according to the specifications and guidelines in RFC 3761 [ENUM]\r\n and the definitions in this document.", "correct_text": " This specification registers the E2U+VPIM:LDAP and E2U+VPIM:Mailto\r\n services according to the specifications and guidelines in RFC 3761\r\n [ENUM] and the definitions in this document.", "notes": "[Note: The RFC text uses \"\" vs. \":\"\r\n in a non-systematical manner. I suspect the difference is not meant to\r\n be significant in the text. Systematical usage of only one of these\r\n two styles would be preferrable in derived (and other future) work.\r\n I have intentionally omitted the trailing \":\" after \"Mailto\" above.]", "submit_date": "2005-11-30", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "156", "doc-id": "RFC4237", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " IANA has registered an LDAP Object Identifier for use in this\r\n technical specification, according to the following template:", "correct_text": " IANA has registered an LDAP Object Identifier for use in this\r\n technical specification, according to the following template.\r\n This Object Identifier, 1.3.6.1.1.11, is referred to as the\r\n \"IANA-ASSIGNED-OID\" in the body of this memo.\r\n", "notes": "", "submit_date": "2005-11-30", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "157", "doc-id": "RFC4237", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2", "orig_text": " (IANA-ASSIGNED-OID.1 NAME 'vPIMUser'\r\n SUP 'top'\r\n ... )", "correct_text": " (IANA-ASSIGNED-OID.1.1 NAME 'vPIMUser'\r\n SUP 'top'\r\n ... )", "notes": "Note: IANA assigned OID 1.3.6.1.1.11 to IANA-ASSIGNED-OID. See .\r\n", "submit_date": "2005-11-30", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "158", "doc-id": "RFC4235", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " \n \n ", "correct_text": " \n \n ", "notes": "The proposed version of text is consistent with the rest of the document,\r\nincluding the schema in section 4.4.\r\n", "submit_date": "2006-10-24", "submitter_name": "Michael Procter", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "159", "doc-id": "RFC4234", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "2.4", "orig_text": " External representations of terminal value characters will vary\r\n according to constraints in the storage or transmission environment.\r\n Hence, the same ABNF-based grammar may have multiple external\r\n encodings, such as one for a 7-bit US-ASCII environment, another for\r\n a binary octet environment, and still a different one when 16-bit\r\n Unicode is used. Encoding details are beyond the scope of ABNF,\r\n although Appendix A (Core) provides definitions for a 7-bit US-ASCII\r\n environment as has been common to much of the Internet.", "correct_text": " External representations of terminal value characters will vary\r\n according to constraints in the storage or transmission environment.\r\n Hence, the same ABNF-based grammar may have multiple external\r\n encodings, such as one for a 7-bit US-ASCII environment, another for\r\n a binary octet environment, and still a different one when 16-bit\r\n Unicode is used. Encoding details are beyond the scope of ABNF,\r\n although Appendix B (CORE ABNF OF ABNF) provides definitions for\r\n a 7-bit US-ASCII environment as has been common to much of the\r\n Internet.\r\n", "notes": "\n --VERIFIER NOTES-- \n Fixed in RFC 5234.", "submit_date": "2006-01-31", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "160", "doc-id": "RFC4234", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.10", "orig_text": " Strings, Names formation\r\n\r\n Comment\r\n\r\n Value range\r\n\r\n Repetition\r\n\r\n Grouping, Optional\r\n\r\n Concatenation\r\n\r\n Alternative\r\n", "correct_text": " Strings, Names formation\r\n\r\n Comment\r\n\r\n Value range\r\n\r\n Grouping, Optional\r\n\r\n Repetition\r\n\r\n Concatenation\r\n\r\n Alternative\r\n\r\n", "notes": "This re-ordering aligns the table with the prose description and the\r\nmeta-grammar in section 4.", "submit_date": "2005-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "161", "doc-id": "RFC4229", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "\r\nReference tags for RFC 2109 [5] should be replaced by reference tags for RFC 2965 [15].\r\n\r\nRationale:\r\nRFC 2109 [5] has been obsoleted by RFC 2965 [15], and the latter\r\napparently contains the current specification for the Set-Cookie\r\n(and the Set-Cookie2) Header Field.\r\n\r\nNevertheless, the registration for 'Set-Cookie' in Subsection\r\n2.1.96 of RFC 4229 (on page 36) refers to RFC 2109 [5] as the\r\nnormative Specification document.\r\n\r\nI suspect that this particular Registration should be updated\r\nimmediately to point to RFC 2965 [15] .\r\n", "submit_date": "2006-01-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4702", "doc-id": "RFC7849", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Abstract", "orig_text": " This document defines a profile that is a superset of the connection\r\n to IPv6 cellular networks defined in the IPv6 for Third Generation\r\n Partnership Project (3GPP) Cellular Hosts document. This document\r\n defines a profile that is a superset of the connections to IPv6\r\n cellular networks defined in \"IPv6 for Third Generation Partnership\r\n Project (3GPP) Cellular Hosts\" (RFC 7066).\r\n\r\n Both mobile hosts and mobile devices with the capability to share\r\n their 3GPP mobile connectivity are in scope.\r\n", "correct_text": " This document defines a profile that is a superset of the connection \r\n to IPv6 cellular networks defined in \"IPv6 for Third Generation \r\n Partnership Project (3GPP) Cellular Hosts\" (RFC 7066). This document \r\n defines an IPv6 profile that a number of operators recommend in order \r\n to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless \r\n network (including a 3GPP cellular network) with a special focus on \r\n IPv4 service continuity features. \r\n\r\n Both mobile hosts and mobile devices with the capability to share \r\n their 3GPP mobile connectivity are in scope. ", "notes": "The first occurrence seems to be an older duplicate.", "submit_date": "2016-05-28", "submitter_name": "Denis Ovsienko", "verifier_id": "", "verifier_name": "Nevil Brownlee", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "162", "doc-id": "RFC4227", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9", "orig_text": " Although service provisioning is a policy matter, at a minimum, all\r\n implementations MUST provide the following tuning profiles:\r\n\r\n for authentication: http://iana.org/beep/SASL/DIGEST-MD5\r\n\r\n for confidentiality: http://iana.org/beep/TLS (using the\r\n TLS_RSA_WITH_AES_EDE_CBC_SHA cipher)\r\n\r\n for both: http://iana.org/beep/TLS (using the\r\n TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side\r\n certificates)\r\n", "correct_text": " Although service provisioning is a policy matter, at a minimum, all\r\n implementations MUST provide the following tuning profiles:\r\n\r\n for authentication: http://iana.org/beep/SASL/DIGEST-MD5\r\n\r\n for confidentiality: http://iana.org/beep/TLS (using the\r\n TLS_RSA_WITH_AES_128_CBC_SHA cipher)\r\n\r\n for both: http://iana.org/beep/TLS (using the\r\n TLS_RSA_WITH_AES_128_CBC_SHA cipher supporting client-side\r\n certificates)\r\n", "notes": "--VERIFIER NOTES--\r\nIt was first reported to us by Alfred H\u00eenes with helpful comments by Philip\r\nNesser.", "submit_date": "2006-02-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Eamon O'Tuathail", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "163", "doc-id": "RFC4226", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9", "orig_text": " Oracle AuthO()\n --------------\n A = ALG(K,C)\n C = C + 1\n Return O to B", "correct_text": " Oracle AuthO()\n --------------\n A = ALG(K,C)\n C = C + 1\n Return A to B\n ^^", "notes": "\nSection A.4.1, Paragraph 3, Lemma 1 definition, top of page 19\n\nThe description of Lemma 1 defines P_ {N,m} (z) using the term Z_ {n}\nand it should actually be Z_ {N}.\n P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]\nShould be:\n P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{N}]\n ^^^\n\nSection E.2, Paragraph 4, bottom of page 32\n 32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is\n significantly better than a 9-digit HOTP value.\nShould be:\n 32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is\n significantly better than a 12-digit HOTP value.\n ^^\n\nIn Author's Addresses, Page 35, David Naccache's contact information should be:\n\n David Naccache\n ENS, DI\n 45 rue d'Ulm\n 75005 Paris, France\n and\n Information Security Group,\n Royal Holloway,\n University of London, Egham,\n Surrey TW20 0EX, UK\n\n EMail: david.naccache@ens.fr, david.naccache@rhul.ac.uk\n\n", "submit_date": "2005-12-26", "submitter_name": "M'Raihi, David", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "165", "doc-id": "RFC4217", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nAbstract says:", "orig_text": "This document\r\n is intended to provide TLS support for FTP in a similar way to that\r\n provided for SMTP in RFC 2487, \"SMTP Service Extension for Secure\r\n SMTP over Transport Layer Security\", and HTTP in RFC 2817, \"Upgrading\r\n to TLS Within HTTP/1.1.\".", "correct_text": "This document\r\n is intended to provide TLS support for FTP in a similar way to that\r\n provided for SMTP in RFC 3207, \"SMTP Service Extension for Secure\r\n SMTP over Transport Layer Security\", and HTTP in RFC 2817, \"Upgrading\r\n to TLS Within HTTP/1.1.\".", "notes": "\r\nthe remainder of the text (including the References section)\r\ncorrectly refers to RFC 3207 that once had obsoleted RFC 2487", "submit_date": "2005-11-09", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "166", "doc-id": "RFC4211", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1", "orig_text": " algorithmIdentifier identifiers the signature algorithm and an\r\n associated parameters used to produce the POP value.\r\n\r\n signature contains the POP value produce.", "correct_text": " algorithmIdentifier identifies the signature algorithm and\r\n associated parameters used to produce the POP value.\r\n\r\n signature contains the POP value produced\r\n", "notes": " ", "submit_date": "2005-11-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "190", "doc-id": "RFC4052", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.2", "orig_text": " [6] Trowbridge, S., Bradner, S., and F. Baker, \"Procedure for\n Handling Liaison Statements Between Standards Bodies\",\n June 2004.", "correct_text": " [6] Trowbridge, S., Bradner, S., and F. Baker, \"Procedures for \n Handling Liaison Statements to and from the IETF\", BCP 103, \n RFC 4053, April 2005.\n", "notes": "\nAlso reported by Loa Andersson on Mon, 25 Jul 2005 14:21:06 +0200.\n\n\n", "submit_date": "2005-05-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "191", "doc-id": "RFC4051", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.3.5", "orig_text": "Identifier:\r\n http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160\r\n\r\n...\r\n\r\n\r\n", "correct_text": "Identifier:\r\n http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160\r\n\r\n...\r\n\r\n", "notes": "In Section 2.3.5, the two URLs should have their right-most slash (\"/\") replaced with a pound sign (\"#\").", "submit_date": "2005-11-08", "submitter_name": "Donald Eastlake III", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "220", "doc-id": "RFC3866", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4", "orig_text": " A server SHOULD indicate that it supports storing attributes with\n language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4\n as a value of the root DSE.", "correct_text": " A server SHOULD indicate that it supports storing attributes with\n language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4\n as a value of the \"supportedFeatures\" [RFC3674] attribute of the root \n DSE.", "notes": "\n\nIn section 5, it says:\n\n Implementators of this specification should take care that their use\n of language tag options does not impede proper function of\n implementations which do not support language tags.\n\nIt should say:\n\n Implementors of this specification should take care that their use\n of language tag options does not impede proper function of\n implementations which do not support language tags.\n\n\n\n", "submit_date": "2004-08-18", "submitter_name": "Kurt D. Zeilenga", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "221", "doc-id": "RFC3866", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.1", "orig_text": " An entry may contain multiple attributes with same\n attribute type but different combinations of language tag (and other)\n options.", "correct_text": " An entry may contain multiple attributes with the same\n attribute type but different combinations of language tag (and other)\n options.\n", "notes": "", "submit_date": "2004-08-31", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "350", "doc-id": "RFC3028", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.4.1", "orig_text": " mebi-, or 1,048,576 (2^20) times the value of the number; and G\n specifies tebi-, or 1,073,741,824 (2^30) times the value of the\n number [BINARY-SI].", "correct_text": " mebi-, or 1,048,576 (2^20) times the value of the number; and G\n specifies gibi-, or 1,073,741,824 (2^30) times the value of the\n number [BINARY-SI].\n", "notes": "", "submit_date": "2003-09-22", "submitter_name": "Piotr Kucharski", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "351", "doc-id": "RFC3024", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.3.1", "orig_text": " Upon receipt of a Registration Reply that satisfies validity\n checks,", "correct_text": " Upon receipt of a Registration Request that satisfies validity\n checks,\n", "notes": "", "submit_date": "2003-06-02", "submitter_name": "Gabriel Montenegro", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "352", "doc-id": "RFC3023", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.13", "orig_text": " {BOM}\n\n or\n\n {BOM}", "correct_text": " {BOM}\n", "notes": "", "submit_date": "2003-05-09", "submitter_name": "Murata Makoto", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "167", "doc-id": "RFC4207", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1.1", "orig_text": " [...] The format of the TraceMonitor message is as\r\n follows:\r\n\r\n ::= \r\n ", "correct_text": "<< THIS CHANGE IS REJECTED >>\r\n<< See the Notes field for the revised editorial change. >>\r\n\r\n [...] The format of the TraceMonitor message is as\r\n follows:\r\n\r\n ::= \r\n \r\n ...", "notes": "\r\n> RFC 4207 defines the syntax of the TraceMonitor message in Section\r\n> 4.1.1, on page 6.\r\n> Similarly, the TraceMonitorAck and TraceMonitorNack Messages are\r\n> specified in Sections 4.1.2 and 4.1.3, respectively, on page 8.\r\n>\r\n> While the former specifies a single object to appear\r\n> in a TraceMonitor message, the latter specs uses wording like\r\n> \"all of the TRACE Objects in a TraceMonitor message\" or\r\n> \"TRACE object value(s)\".\r\n>\r\n> IMHO, it makes much sense to indeed allow multiple TRACE Objects\r\n> (with different trace types, but all related to a single Interface)\r\n> in a single TraceMonitor Message.\r\n\r\n\r\nCCAMP consensus on this issue is that the BNF is correct. That is, only a single instance of the object is permitted on the or any of the other messages. \r\n\r\nThe text in the various sections is factually correct when it says things like \"all the Trace Objects...\" However, this is misleading and should be changed to be singlular in all cases.", "submit_date": "2005-12-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "170", "doc-id": "RFC4187", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.2.5", "orig_text": " | +------------------------------+\r\n | | Server does not accept |\r\n | | The fast re-authentication |\r\n | | Identity |\r\n | +------------------------------+\r\n | |\r\n : :\r\n : :\r\n\r\n\r\n : :\r\n : :\r\n | EAP-Request/AKA-Identity |\r\n | (AT_FULLAUTH_ID_REQ) |\r\n |<------------------------------------------------------|", "correct_text": " | +------------------------------+\r\n | | Server does not accept |\r\n | | The fast re-authentication |\r\n | | Identity |\r\n | +------------------------------+\r\n | |\r\n | EAP-Request/AKA-Identity |\r\n | (AT_FULLAUTH_ID_REQ) |\r\n |<------------------------------------------------------|", "notes": "In Section 4.2.5, Figure 9 (on page 31) contains six lines that\r\nmight erroneously be misunderstod to indicate the omission of\r\nsome protocol steps (which is not the case).\r\nI suspect that this is an artifact from a draft version where\r\nFigure 9 was split over two pages; after joining the parts,\r\nthese continuation indicators have become ambiguous, and hence\r\nshould be deleted.\r\n\r\nfrom pending", "submit_date": "2006-11-26", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "171", "doc-id": "RFC4186", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.1", "orig_text": " Length\r\n\r\n Indicates the length of this attribute in multiples of four\r\n bytes. The maximum length of an attribute is 1024 bytes. The\r\n length includes the Attribute Type and Length bytes.", "correct_text": " Length\r\n\r\n Indicates the length of this attribute in multiples of four\r\n bytes. The maximum length of an attribute is 1020 bytes. The\r\n length includes the Attribute Type and Length bytes.", "notes": " As there is no offset defined, the maximum encoded Length value\r\n of 255 corresponds to a total of 4*255 = 1020 octets.\r\n\r\nNote:\r\n Other protocols incorporate an offset of -1 in similar cases, e.g.,\r\n when a TLV Length field comprises the length of the 'T' and 'L',\r\n also removing the artificially designed-in error case (Length=0),\r\n that otherwise must be checked for by all implementations!\r\n Some people speak of bad protocol design when encountering\r\n Length fields that do not indicate the true length of an object\r\n value proper, which might be zero.\r\n\r\nfrom pending", "submit_date": "2006-11-26", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Henry Haverinen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "172", "doc-id": "RFC4182", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2", "orig_text": "RFC 3032 states on page 4:", "correct_text": "RFC 3032 states on page 5:\r\n", "notes": "Wrong page number in reference.", "submit_date": "2005-09-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "173", "doc-id": "RFC4181", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.6.1.1", "orig_text": " - For integer-valued enumerations:\n\n - INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST\n NOT be used.", "correct_text": "- For integer-valued enumerations:\n\n - INTEGER is REQUIRED;\n - Integer32, Unsigned32, and Gauge32 MUST NOT be used.\n", "notes": "", "submit_date": "2005-11-01", "submitter_name": "C. M. Heard", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "174", "doc-id": "RFC4173", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "\r\nTwo normative references have been obsoleted:\r\n\r\n RFC 2396 ( Ref. \"[Lee98]\" )\r\nand\r\n RFC 2732 ( Ref. \"[Hinden99]\" )\r\n\r\nhave both been obsoleted by RFC 3986 == STD 66 (published in\r\nJanuary 2005) !\r\n\r\nAffected pieces of RFC 4173:\r\n- Both Ref's appear once (and together) near the bottom of\r\n page 4 (in the 6th-to-last line).\r\n- Normative References section, bottom of page 9 + top of page 10\n --VERIFIER NOTES-- \nIndependent of the publication date, the work on the draft that\r\nbecame this RFC significantly predates publication of RFC 3986.\r\nThe references to those two RFCs are correct, and the obsoleted\r\nstatus of the RFCs can be readily determined from the RFC Editor's\r\ndatabase. ", "submit_date": "2005-10-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "213", "doc-id": "RFC3891", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1", "orig_text": " INVITE sip:bob@bobster.example.org\r\n To: \r\n From: ;tag=8983\r\n Call-ID: 09870@phone2.example.org\r\n CSeq: 1 INVITE\r\n Contact: \r\n Require: replaces\r\n Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472\r\n ", "correct_text": " INVITE sip:bob@bobster.example.org\r\n To: \r\n From: ;tag=8983\r\n Call-ID: 09870@phone2.example.org\r\n CSeq: 1 INVITE\r\n Contact: \r\n Require: replaces\r\n Replaces: 425928@bobster.example.org;to-tag=8983;from-tag=7743\r\n \r\n", "notes": "", "submit_date": "2005-07-26", "submitter_name": "Rb Srikanth", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "214", "doc-id": "RFC3887", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": " All optional text provided with the COMMENT command are ignored.", "correct_text": " All optional text provided with the COMMENT command is ignored.", "notes": "", "submit_date": "2004-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "215", "doc-id": "RFC3887", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "11", "orig_text": " ...Thus, if an MTQP client/server pair decide to use TLS\r\n confidentially,...", "correct_text": " ... Thus, if an MTQP client/server pair decides to use TLS\r\n confidentially, ...\r\n", "notes": "", "submit_date": "2005-11-07", "submitter_name": "Tony Hansen", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "353", "doc-id": "RFC3015", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Section Annex B ", "orig_text": " V4hex = 1*3(DIGIT) ; \"0\"..\"225\"", "correct_text": " V4hex = 1*3(DIGIT) ; \"0\"..\"255\"\n", "notes": "", "submit_date": "2001-09-04", "submitter_name": "Brian Rosen", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "175", "doc-id": "RFC4171", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1.1", "orig_text": " STORAGE NODE iSCSI Name * * *\r\n iSCSI Node Type * *\r\n Alias *\r\n iSCSI SCN Bitmap *\r\n iSCSI Node Index *\r\n WWNN Token\r\n iSCSI AuthMethod\r\n iSCSI Node Certificate\r\n ^^^^^^^^^^^^^^^^^^^^^^", "correct_text": " STORAGE NODE iSCSI Name * * *\r\n iSCSI Node Type * *\r\n Alias *\r\n iSCSI SCN Bitmap *\r\n iSCSI Node Index *\r\n WWNN Token\r\n iSCSI AuthMethod", "notes": "Section 4.1.1 refers to 'iSCSI Node Certificate', which is never defined in the document.\r\n\r\nFrom David Black:\r\nThe comment appears to be correct, and the actual Errata should\r\nbe to remove the following line from Section 4.1.1 of RFC\r\n4171 (iSNS) because it is not supported by the iSNS protocol:\r\n\r\n iSCSI Node Certificate", "submit_date": "2006-06-23", "submitter_name": "Hannes Reinecke", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "176", "doc-id": "RFC4157", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Section 2 should be consistent with the systematic use of the term \"URI instead of \"URL\"\r\n\r\nRationale:\r\nRFC 3986 (== STD 66), in section 1.1.3., at the bottom of page 7,\r\nspecifies:\r\n\r\n... Future specifications and related documentation should\r\nuse the general term \"URI\" rather than the more restrictive terms\r\n\"URL\" and \"URN\" [RFC3305].\r\n\r\nAdmittedly, RFC1630 and RFC 1738 used the term \"URL\" -- but that\r\nwas long before RFC 3986!", "submit_date": "2005-09-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "177", "doc-id": "RFC4156", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Section 2 should be consistent with the systematic use of the term \"URI instead of \"URL\"\r\n\r\nRationale:\r\nRFC 3986 (== STD 66), in section 1.1.3., at the bottom of page 7,\r\nspecifies:\r\n\r\n ... Future specifications and related documentation should\r\n use the general term \"URI\" rather than the more restrictive terms\r\n \"URL\" and \"URN\" [RFC3305].\r\n\r\nAdmittedly, RFC1630 and RFC 1738 used the term \"URL\" -- but that\r\nwas long before RFC 3986!", "submit_date": "2005-09-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "178", "doc-id": "RFC4151", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": "[2] should refer to RFC 5234\r\n[5] should refer to RFC 4122", "correct_text": "", "notes": "RFC 2234 was obsoleted by RFC 5234.", "submit_date": "2005-11-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "179", "doc-id": "RFC4147", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2", "orig_text": " F800::/6 Reserved by IETF RFC3513\n FA00::/7 Reserved by IETF RFC3513\n FC00::/7 Reserved by IETF RFC3513", "correct_text": " F800::/6 Reserved by IETF RFC3513\n FC00::/7 Reserved by IETF RFC3513", "notes": " Section 2 states \"There are no overlapping address blocks in the first\ncolumn\", but the address blocks F800::/6 and FA00::/7\noverlap. Therefore, the address block FA00::/7 should be removed from the table.", "submit_date": "2005-08-29", "submitter_name": "Mark Doll", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "181", "doc-id": "RFC4140", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "9.2", "orig_text": "This kind of dynamic hierarchy (or anchoring) is only recommended for cases where \r\ninter-AR u0movement is not frequent.", "correct_text": "This kind of dynamic hierarchy (or anchoring) is only recommended for cases where \r\ninter-AR movement is not frequent.\r\n", "notes": "", "submit_date": "2006-08-23", "submitter_name": "Teemu Huovila", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "182", "doc-id": "RFC4140", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "Appendix A", "orig_text": "1.) There are a couple of issues with the citations given\r\n in Appendix A, on pp. 24-27 :\r\n\r\n1.1) I suspect that the repeated occurrences of \"[5]\" should\r\n in fact be \"[4]\" (the Fast Handover RFC 4068).\r\n\r\n1.2) The final phrase at the bottom of page 26 should obviously\r\n refer to RFC 4067 (CXTP) instead of a \"work in progress\"\r\n (add appropriate ref to section 14.2.!)\r\n\r\n1.3) The citations \"[6]\" on page 27 apparently make no sense --\r\n SEND does not update RFC 4068. I suspect a reference to\r\n some \"work in progress\" would have been appropriate.\r\n\r\n2.) Minor typos and proposed textual improvements\r\n\r\n2.1) On p.8, in line 5 (i.e. the end of section 4.1.):\r\n instead of \"introduced in future\" the text might perhaps\r\n better say: \"introduced in the future\".\r\n\r\n2.2) On p. 14, in the bottom line (at the end of section 7.1.),\r\n the final \".\" is missing.\r\n\r\n2.3) On p. 16, in the 2nd-to-last paragraph of section 7.2.,\r\n The phrase \"RCoA is then bound to ...\" should perhaps better\r\n say: \"The RCoA is then bound to ...\".\r\n\r\n2.4) On page 19, in the final line of section 9.2., the word\r\n \"movement\" is mis-spelled \"u0movement\".\r\n\r\n2.5) On page 20, in the enumerated list at the end of section 12.,\r\n I propose to remove the \"The\" in all 3 items, aligning with\r\n the titles of the subsequent sections 12.1. - 12.3.", "correct_text": "[see above]", "notes": "from pending\r\n\r\n\r\n\r\n\r\n\n --VERIFIER NOTES-- \nRFC 4140 has been obsoleted by RFC 5380.", "submit_date": "2005-09-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "216", "doc-id": "RFC3886", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": "IANA has registered the SMTP extension defined in section 3.", "correct_text": "IANA has registered the MIME subtype defined in section 3.", "notes": "The text of RFC 3886, Section 5. (on page 8) appears to by copied\r\nunchanged from RFC 3885 and thus does not fit the context of\r\nRFC 3886.", "submit_date": "2004-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "217", "doc-id": "RFC3886", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1", "orig_text": " That body consists of one or more \"fields\" formatted to\r\n ^^\r\n according to...", "correct_text": " That body consists of one or more \"fields\" formatted\r\n according to...", "notes": "Extra \"to\".\r\n", "submit_date": "2004-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "218", "doc-id": "RFC3886", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " A Message Tracking Status Motification (MTSN) is intended to be\r\n returned as the body of a Message Tracking request [RFC-MTRK-MTQP].\r\n ^^^^^^^", "correct_text": " A Message Tracking Status Motification (MTSN) is intended to be\r\n returned as the body of a Message Tracking response [RFC-MTRK-MTQP].\r\n ^^^^^^^^", "notes": "", "submit_date": "2004-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "354", "doc-id": "RFC3010", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "RFC 3010 claims that it obsoletes RFC 1813 and RFC 1094, when in fact it does not.\n", "submit_date": "2002-06-11", "submitter_name": "Matthew Wilcox", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "183", "doc-id": "RFC4133", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.12.1", "orig_text": " For example, the entPhysicalUris object may be used to encode a URI\r\n containing a Common Language Equipment Identifier (CLEI) URN for\r\n the managed physical entity. The URN name space for CLEIs is\r\n defined in [RFCYYYY], and the CLEI format is defined in\r\n [T1.213][T1.213a]. For example, an entPhysicalUris instance may\r\n have the value of\r\n\r\n URN:CLEI:D4CE18B7AA\r\n\r\n [RFC3986] and [RFCYYYY] identify this as a URI in the CLEI URN name\r\n space. The specific CLEI code, D4CE18B7AA, is based on the example\r\n provided in [T1.213a].", "correct_text": " For example, the entPhysicalUris object may be used to encode a URI\r\n containing a Common Language Equipment Identifier (CLEI) URN for\r\n the managed physical entity. The URN name space for CLEIs is\r\n defined in [RFC4152], and the CLEI format is defined in\r\n [T1.213][T1.213a]. For example, an entPhysicalUris instance may\r\n have the value of\r\n\r\n URN:CLEI:D4CE18B7AA\r\n\r\n [RFC3986] and [RFC4152] identify this as a URI in the CLEI URN name\r\n space. The specific CLEI code, D4CE18B7AA, is based on the example\r\n provided in [T1.213a].\r\n", "notes": "", "submit_date": "2005-09-22", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "184", "doc-id": "RFC4122", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.3", "orig_text": "The UUIDs generated from the same name in two different namespaces\r\n should be different with (very high probability).", "correct_text": "The UUIDs generated from the same name in two different namespaces\r\n should be different (with very high probability).", "notes": "The brackets should be set similarly to the other points.", "submit_date": "2006-05-03", "submitter_name": "Tim Wilson-Brown", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "185", "doc-id": "RFC4117", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": " |--------------------(4) INVITE SDP TA------------------->|\n | | |\n |<--------------------(5) 200 OK SDP B--------------------|\n | | |\n |-------------------------(6) ACK------------------------>|\n | | |\n |--------(7) INVITE--------->| |\n | | |\n |<---(8) 200 OK SDP TA+TB --| |\n | | |\n |--------------------(9) INVITE SDP TA------------------->|", "correct_text": " |--------------------(4) INVITE SDP TB------------------->|\n | | |\n |<--------------------(5) 200 OK SDP B--------------------|\n | | |\n |-------------------------(6) ACK------------------------>|\n | | |\n |--------(7) INVITE--------->| |\n | | |\n |<---(8) 200 OK SDP TA+TB --| |\n | | |\n |--------------------(9) INVITE SDP TB------------------->|\n", "notes": "", "submit_date": "2005-08-22", "submitter_name": "Gonzalo Camarillo", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "186", "doc-id": "RFC4114", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1.2", "orig_text": " Example response:\n\n [...]\n S: 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa\n S: EXAMPLE1-REP\n S: \n S: jd1234\n S: sh8013\n S: sh8013\n S: \n S: ns1.example.com\n S: ns2.example.com\n S: \n S: ns1.example.com\n S: ns2.example.com\n S: ClientX\n S: ClientY\n [...]", "correct_text": " Example response:\n\n [...]\n S: 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa\n S: EXAMPLE1-REP\n S: \n S: jd1234\n S: sh8013\n S: sh8013\n S: \n S: ns1.example.com\n S: ns2.example.com\n S: \n S: ClientX\n S: ClientY\n [...]", "notes": "\n There is the that should list the \"fully qualified names \nof the subordinate host objects that exist under this superordinate domain object.\" \nAs the is not \"example.com:, those elements should be \nremoved.\n\n", "submit_date": "2005-06-21", "submitter_name": "Bernie Hoeneisen", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "187", "doc-id": "RFC4113", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nDESCRIPTION clause of 'udpEndpointRemotePort' says:", "orig_text": " The remote port number for this UDP endpoint. If\r\n datagrams from any remote system are to be accepted,\r\n this value is zero.", "correct_text": " The remote port number for this UDP endpoint. If\r\n datagrams from any remote port are to be accepted,\r\n this value is zero.\r\n", "notes": "", "submit_date": "2005-06-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "188", "doc-id": "RFC4060", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.2", "orig_text": " The additional fundamental frequency and voicing class information is\n compressed for each frame pair. The pitch for the first frame of the\n FP is quantized to 7 bits and the second frame is differentially\n quantized to 7 bits. ", "correct_text": " The additional fundamental frequency and voicing class information is\n compressed for each frame pair. The pitch for the first frame of the\n FP is quantized to 7 bits and the second frame is differentially\n quantized to 5 bits. \n", "notes": "", "submit_date": "2005-05-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "189", "doc-id": "RFC4057", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.6", "orig_text": " Network\n management will not need to support both IPv4 and IPv6 and view nodes\n as dual stacks.", "correct_text": " Network\n management will need to support both IPv4 and IPv6 and view nodes\n as dual stacks.\n", "notes": "", "submit_date": "2005-06-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "355", "doc-id": "RFC3003", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": " * NOTE: The audio/MPS mime type is in use in addition to the\n audio/mpeg. ", "correct_text": " * NOTE: The audio/MPA mime type is in use in addition to the\n audio/mpeg. \n", "notes": "", "submit_date": "2000-11-22", "submitter_name": "Colin Perkins", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "356", "doc-id": "RFC2985", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "The Table of Contents says:", "orig_text": "5.6 Attributes defined in S/MIMIE .............................. 18", "correct_text": "5.6 Attributes defined in S/MIME .............................. 18\r\n", "notes": "", "submit_date": "2000-12-13", "submitter_name": "Robert Moskowitz", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "192", "doc-id": "RFC4043", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Appendix A.2. 1993 ASN.1 Module says:\n", "orig_text": "Appendix A.2. 1993 ASN.1 Module\n\nPKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)\n internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)\n id-mod-perm-id-93(29) }\n\n DEFINITIONS EXPLICIT TAGS ::=\n\n BEGIN\n\n -- EXPORTS ALL --\n\n IMPORTS\n\n id-pkix\n FROM PKIX1Explicit88 { iso(1) identified-organization(3)\n dod(6) internet(1) security(5) mechanisms(5) pkix(7)\n id-mod(0) id-pkix1-explicit(18) }\n -- from [RFC3280]\n\n ATTRIBUTE\n FROM InformationFramework {joint-iso-itu-t ds(5) module(1)\n informationFramework(1) 4};\n -- from [X.501]\n\n -- Permanent identifier Object Identifiers\n\n id-on OBJECT IDENTIFIER ::= { id-pkix 8 }\n\n id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }\n\n -- Permanent Identifier\n\n permanentIdentifier ATTRIBUTE ::= {\n WITH SYNTAX PermanentIdentifier\n ID id-on-permanentIdentifier }\n\n PermanentIdentifier ::= SEQUENCE {\n identifierValue UTF8String OPTIONAL,\n -- if absent, use the serialNumber attribute\n -- if there is a single such attribute present\n -- in the subject DN\n assigner OBJECT IDENTIFIER OPTIONAL\n -- if absent, the assigner is\n -- the certificate issuer\n}\n\nEND", "correct_text": "Appendix A.2. 1993 ASN.1 Module\n\n PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)\n internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)\n id-mod-perm-id-93(29) }\n\n DEFINITIONS EXPLICIT TAGS ::=\n\n BEGIN\n\n -- EXPORTS ALL --\n\n IMPORTS\n OTHER-NAME\n FROM CertificateExtensions {joint-iso-itu-t ds(5) module(1)\n certificateExtensions(26) 4} ;\n -- from Module CertificateExtensions (X.509:03/2000)\n\n\n -- Permanent identifier Object Identifiers\n\n id-pkix OBJECT IDENTIFIER ::= { iso(1)\n identified-organization(3) dod(6) internet(1)security(5)\n mechanisms(5) pkix(7) }\n\n id-on OBJECT IDENTIFIER ::= { id-pkix 8 }\n\n id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }\n\n\n -- Permanent Identifier\n\n permanentIdentifier OTHER-NAME ::=\n { PermanentIdentifier IDENTIFIED BY id-on-permanentIdentifier }\n\n PermanentIdentifier ::= SEQUENCE {\n identifierValue UTF8String OPTIONAL,\n -- if absent, use the serialNumber attribute\n -- if there is a single such attribute present\n -- in the subject DN\n assigner OBJECT IDENTIFIER OPTIONAL\n -- if absent, the assigner is\n -- the certificate issuer\n }\n\n END\n", "notes": "\n", "submit_date": "2007-02-07", "submitter_name": "Denis Pinkas", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "193", "doc-id": "RFC4034", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "In Appendix B.1, it says: ", "orig_text": " For a\n DNSKEY RR with algorithm 1, the key tag is defined to be the most\n significant 16 bits of the least significant 24 bits in the public\n key modulus (in other words, the 4th to last and 3rd to last octets\n of the public key modulus).", "correct_text": " For a\n DNSKEY RR with algorithm 1, the key tag is defined to be the most\n significant 16 bits of the least significant 24 bits in the public\n key modulus (in other words, the 3rd to last and 2nd to last octets\n of the public key modulus).\n", "notes": "", "submit_date": "2005-06-21", "submitter_name": "Donald E. Eastlake III", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "194", "doc-id": "RFC4029", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.1", "orig_text": " Offering native service as quickly as possible is important. In the\n meantime, however, a 6to4 relay may be provided in the meantime for\n optimized 6to4 connectivity and may also be combined with a tunnel\n broker for extended functionality. ", "correct_text": " Offering native service as quickly as possible is important. In the\n meantime, however, a 6to4 relay may be provided for optimized 6to4 \n connectivity and may also be combined with a tunnel broker for extended \n functionality. ", "notes": "\nIn Section 12, it says:\n [UNMANEVA] Huitema, C., Austein, R., Satapati, S., van der Pol,\n R., \"Evaluation of Transition Mechanisms for Unmanaged\n Networks\", Work in Progress.\n...\n [DNSGUIDE] Durand, A., Ihren, J., \"DNS IPv6 transport operational\n guidelines\", Work in Progress.\nIt should say:\n [UNMANEVA] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, \n \"Evaluation of IPv6 Transition Mechanisms for Unmanaged \n Networks\", RFC 3904, September 2004.\n...\n [DNSGUIDE] Durand, A. and J. Ihren, \"DNS IPv6 Transport Operational \n Guidelines\", BCP 91, RFC 3901, September 2004.\n\n\n\n", "submit_date": "2005-06-23", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "195", "doc-id": "RFC4026", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "8.10", "orig_text": " VPN Forwarding Instance (VFI) is a logical entity that resides in a\r\n PE that includes the router information base and forwarding\r\n information base for a VPN instance [L3VPN-FRAME].", "correct_text": " VPN Forwarding Instance (VFI) is a logical entity that resides in a\r\n PE that includes the route information base and forwarding\r\n information base for a VPN instance [L3VPN-FRAME].\r\n", "notes": "", "submit_date": "2006-08-17", "submitter_name": "", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "196", "doc-id": "RFC4010", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.1", "orig_text": " P[i] The ith plaintext key data block\r\n C[i] The ith ciphertext data block\r\n A The 64-bit integrity check register\r\n R[i] An array of 64-bit registers where\r\n i = 0, 1, 2, ..., n\r\n A[t], R[i][t] The contents of registers A and R[i] after\r\n encryption step t.", "correct_text": " P[i] The ith (64-bit) plaintext key data block\r\n where i = 1, 2, ..., n\r\n C[i] The ith (64-bit) ciphertext data block\r\n where i = 0, 1, 2, ..., n\r\n A The 64-bit integrity check register\r\n R[i] An array of 64-bit registers where\r\n i = 1, 2, ..., n\r\n A[t], R[t][i] The contents of registers A and R[i] after\r\n encryption step t.", "notes": "", "submit_date": "2005-02-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "197", "doc-id": "RFC4009", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2.5", "orig_text": " seedCDCParameter ::= OCTET STRING -- 128-bit Initialization Vector", "correct_text": "seedCDCParameter ::= OCTET STRING (SIZE(16))\r\n -- 128-bit Initialization Vector\r\n", "notes": "", "submit_date": "2005-03-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "199", "doc-id": "RFC3981", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Appendix A says:", "orig_text": "he whois application protocol label refers to RFC 954 [19].", "correct_text": "he whois application protocol label refers to RFC 3912 [19].", "notes": "", "submit_date": "2005-01-09", "submitter_name": "St\u00e9phane Bortzmeyer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "200", "doc-id": "RFC3978", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": " (B) to prepare or allow the preparation of translations of the RFC\n into languages other than English.", "correct_text": " (B) to prepare or allow the preparation of translations of the RFC\n into languages other than English,", "notes": "In Section 5.3, it says:\n This notice can be used on IETF Contributions that are intended to\n provide background information to educate and to facilitate\n discussions within IETF working groups but are not intended to be\n published as an RFCs.\nIt should say:\n This notice can be used on IETF Contributions that are intended to\n provide background information to educate and to facilitate\n discussions within IETF working groups but are not intended to be\n published as RFCs.\n\n\n", "submit_date": "2005-07-02", "submitter_name": "Frank Ellermann", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2574", "doc-id": "RFC5810", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Appendix D", "orig_text": "Note 1: This emulates adding a new nexthop entry and then\r\n atomically updating the L3 entries pointing to an old NH to\r\n point to a new one.", "correct_text": "Note 1: This emulates adding a new nexthop entry and then\r\n atomically updating the L3 entry that pointed to the\r\n old NH to point to the new one.", "notes": "Example 13 text (not the example) claims you can use a single KEYINFO to \r\nmatch multiple L3 entries.\r\nYou cannot use KEYINFO to match multiple table entries. The model \r\nRFC 5812 section 4.5.3 is clear that you can only match one entry.\r\n", "submit_date": "2010-10-16", "submitter_name": "Jamal Hadi Salim", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "201", "doc-id": "RFC3967", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "Normative references to HMAC in future IETF Standards Track documents should always refer to FIPS-198 instead of RFC 2104.", "orig_text": "reading the fresh RFC 3967 (== BCP 97), I found that this memo uses\r\nexamples which are well known, but not very appropriate, for the\r\ndesired purpose:\r\n\r\n(1)\r\n HMAC [RFC2104]\r\n\r\nThis algorithm - since almost three years - is a US Federal\r\nInformation Processing Standard!\r\n\r\n( FIPS PUB 198, issued '2002 March 6' ;\r\n to download a PDF copy (updated '2002 April 8'), see\r\n )\r\n\r\nThis is an active standard published by a recognized standards body.\r\nTherefore, *Normative References* to HMAC in future IETF Standards\r\nTrack documents should always refer to FIPS-198 instead of RFC 2104 !\r\n\r\n\r\n", "correct_text": "[see above]", "notes": "Remark 1:\n FIPS-198 in turn refers to RFC 2104 as a readily available\n source document for the algorithm, but gives a detailed,\n independent description of the algorithm and its application.\n\nRemark 2:\n Expect alternative MAC algorithms like UMAC, TTMAC, EMAC,\n and RMAC to get formally standardized soon by various Standards\n Bodies. For example, the former three Algorithms are already\n (since Feb. 2003) recommended for new applications to be used in\n the public administration and economy within the European Union.\n This has been the result of the NESSIE project - an open contest\n similar to the AES contest of NIST's), see\n .\n\nfrom pending\n --VERIFIER NOTES-- \n2021-10-06: moved from Held for Document Update to Rejected per request from Murray Kucherawy. This erratum was reviewed while working on a bis document.", "submit_date": "2005-01-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2025-05-06 21:11:31"}, {"errata_id": "202", "doc-id": "RFC3966", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.1.5", "orig_text": " +1-212-555-1 would not be a valid global context, ...", "correct_text": " +1-212-555-01 would not be a valid global context, ...", "notes": " Although tiny typo, it could possibly be distorting the meaning.", "submit_date": "2004-12-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Henning Schulzrinne", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "203", "doc-id": "RFC3966", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": "isdn-subaddress = \";isub=\" 1*uric", "correct_text": "isdn-subaddress = \";isub=\" 1*paramchar\r\n", "notes": "", "submit_date": "2005-03-01", "submitter_name": "Henning Schulzrinne", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "204", "doc-id": "RFC3965", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Normative Reference says:", "orig_text": " [5] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.\n Rafferty, \"File Format for Internet Fax\", RFC 3949, November\n 2004.\n", "correct_text": " [5] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.\n Rafferty, \"File Format for Internet Fax\", RFC 3949, February\n 2005.\n", "notes": " \n [RFC3949] had not yet been published when [RFC3965] was in December, 2004.", "submit_date": "2005-01-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "205", "doc-id": "RFC3965", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Informative References", "orig_text": "[19] Ramsdell, B., \"S/MIME Version 3 Message Specification\", RFC 2633, June 1999.", "correct_text": "[19] Ramsdell, B., \"S/MIME Version 3 Message Specification\", RFC 3851, June 1999.", "notes": "from pending\r\n", "submit_date": "2005-01-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "206", "doc-id": "RFC3965", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": " \r\nThe Normative Reference [3] should be deleted from section 6.1., on page 10.\r\n\r\nRationale: \r\n References [1] and [2] from RFC 2305 have been updated, from\r\n pointers to RFC 821 and RFC 822, to pointers to RFC 2821 and\r\n RFC 2822, respectively. The (normative) updates to RFC 821 and RFC 822 contained in\r\n STD 3, RFC 1123 [3], have been incorporated into RFC 2821\r\n and RFC 2822, respectively, which obsolete their predecessors.\r\n Hence, the reference to RFC 1123 is no more needed in RFC 3965,\r\n and in fact it is not mentioned in the textual body any more.\r\n", "submit_date": "2005-01-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "207", "doc-id": "RFC3961", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "The Unicode character g-clef used throughout the document says:", "orig_text": " \"g-clef U+1011E F0 9D 84 9E\"", "correct_text": " \"g-clef U+1D11E F0 9D 84 9E\"", "notes": "", "submit_date": "2006-04-05", "submitter_name": "Weijun Wang", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "208", "doc-id": "RFC3939", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Informative Reference includes [RFC2806]; however, [RFC2806] has been obsoleted by [RFC3966]. All citations and references should reflect this throughout the document.\n\n", "submit_date": "2005-01-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "209", "doc-id": "RFC3933", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": "\tThe I-D must state an explicit \"sunset\" timeout\r\n\ttypically, not to exceed one year after adoption.", "correct_text": "\tThe I-D must state an explicit \"sunset\" timeout,\r\n\ttypically not to exceed one year after adoption.\r\n", "notes": "", "submit_date": "2006-02-15", "submitter_name": "John C Klensin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "210", "doc-id": "RFC3931", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": "SSHTRESH", "correct_text": "SSTHRESH\r\n", "notes": "Occurs 3 times.\r\n\r\nfrom pending.", "submit_date": "2007-05-09", "submitter_name": "Ming Deng", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "211", "doc-id": "RFC3931", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.4.5", "orig_text": " This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for\n this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The\n Length (before hiding) of this AVP is 32.", "correct_text": " \n This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for\n this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The\n Length (before hiding) of this AVP is 24.\n", "notes": "\n\n", "submit_date": "2005-10-31", "submitter_name": "Carlos Pignataro", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "212", "doc-id": "RFC3920", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "In Appendix C.1, add the following three lines directly after the opening tag:", "orig_text": " \r\n \r\n ", "correct_text": "", "notes": "", "submit_date": "2004-11-05", "submitter_name": "Peter Saint-Andre", "verifier_id": "", "verifier_name": null, "update_date": "2022-01-25 17:42:39"}, {"errata_id": "4703", "doc-id": "RFC7841", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.2", "orig_text": "", "correct_text": "", "notes": "Sections 3.3 through 3.6 should have been subsections of 3.2, as they describe parts of \"status of this memo\". See also RFC 5741 which has this right.", "submit_date": "2016-05-30", "submitter_name": "Julian Reschke", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "357", "doc-id": "RFC2978", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "(1) All references in RFC 2978 to RFC 2184 should be replaced by RFC\n 2231. RFC 2231 obsoleted RFC 2184 before RFC 2978 was published.\n\n(2) The fact that vertical bar and backslash characters are now\n excluded from charset names was a change from RFC 2278 that should\n have been noted in section 7.\n", "submit_date": "2003-02-09", "submitter_name": "Ned Freed", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "358", "doc-id": "RFC2939", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": " DHCP protocol messages are identified by the 'DHCP Message Type'\n option (option code 51).", "correct_text": " DHCP protocol messages are identified by the 'DHCP Message Type'\n option (option code 53).\n", "notes": "", "submit_date": "2001-09-04", "submitter_name": "Tyler Tidman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "222", "doc-id": "RFC3852", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.1", "orig_text": " IF (originatorInfo is present) AND\r\n ((any certificates with a type of other are present) OR\r\n (any crls with a type of other are present))\r\n THEN version is 4\r\n ELSE\r\n IF ((originatorInfo is present) AND\r\n (any version 2 attribute certificates are present)) OR\r\n (any RecipientInfo structures include pwri) OR\r\n (any RecipientInfo structures include ori)\r\n THEN version is 3\r\n ELSE\r\n IF (originatorInfo is absent) OR\r\n (unprotectedAttrs is absent) OR\r\n (all RecipientInfo structures are version 0)\r\n THEN version is 0\r\n ELSE version is 2\r\n", "correct_text": " IF (originatorInfo is present) AND\r\n ((any certificates with a type of other are present) OR\r\n (any crls with a type of other are present))\r\n THEN version is 4\r\n ELSE\r\n IF ((originatorInfo is present) AND\r\n (any version 2 attribute certificates are present)) OR\r\n (any RecipientInfo structures include pwri) OR\r\n (any RecipientInfo structures include ori)\r\n THEN version is 3\r\n ELSE\r\n IF (originatorInfo is absent) AND\r\n (unprotectedAttrs is absent) AND\r\n (all RecipientInfo structures are version 0)\r\n THEN version is 0\r\n ELSE version is 2\r\n", "notes": " ", "submit_date": "2005-01-22", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "223", "doc-id": "RFC3834", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": " A Service Responder MAY deliver the response to the address(es) from\n the >From field, or to another address from the request payload,\n provided this behavior is precisely defined in the specification for\n that service. ", "correct_text": " A Service Responder MAY deliver the response to the address(es) from\n the From field, or to another address from the request payload,\n provided this behavior is precisely defined in the specification for\n that service. ", "notes": "\n\n", "submit_date": "2004-09-01", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "224", "doc-id": "RFC3829", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.1", "orig_text": " [IANALDAP] Hodges, J. and R. Morgan, \"Lightweight Directory Access\n Protocol (v3): Technical Specification\", RFC 3377,\n September 2002.", "correct_text": " [IANALDAP] Zeilenga, K., \"Internet Assigned Authority (IANA)\n Considerations for the Lightweight Directory Access\n Protocol (LDAP)\", RFC 3383, September 2002.\n", "notes": "\n", "submit_date": "2004-09-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "225", "doc-id": "RFC3822", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Lines 274 and 333 say:", "orig_text": "template-version=0.1", "correct_text": "template-version=1.0", "notes": "", "submit_date": "2004-11-22", "submitter_name": "David Peterson", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "236", "doc-id": "RFC3742", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2", "orig_text": " the invariant is maintained so that the congestion window is\n increased during slow-start by at most max_ssthresh/2 MSS per round-\n trip time. ", "correct_text": " the invariant is maintained that the congestion window is\n increased during slow-start by at most max_ssthresh MSS per\n round-trip time (and at least max_ssthresh/2 MSS per round-trip\n time).", "notes": "\nLater in Section 2:\n it\n takes:\n\n log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)\n\n round-trip times to reach a congestion window of cwnd, for a\n congestion window greater than max_ssthresh.\nShould be:\n it\n takes at least:\n\n log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh)\n\n and at most:\n\n log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)\n\n round-trip times to reach a congestion window of cwnd, for a\n congestion window greater than max_ssthresh.\n\nLater in Section 2:\n Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it\n would take 836 round-trip times to reach a congestion window of\n 83,000 packets,\nShould be:\n Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it\n would take at least 836 round-trip times to reach a congestion window of\n 83,000 packets,\n\n", "submit_date": "2005-06-08", "submitter_name": "Sally Floyd", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "237", "doc-id": "RFC3741", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Please see the corresponding W3C document:\n\nhttp://www.w3.org/TR/xml-exc-c14n\n\n\nPlease see the pointer to the W3C errata:\n\nhttp://www.w3.org/2002/07/xml-exc-c14n-errata\n\n\n", "submit_date": "2004-03-26", "submitter_name": "Donald Eastlake III", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "238", "doc-id": "RFC3733", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.2.4", "orig_text": " S: \n S: Command completed successfully", "correct_text": " S: \n S: Command completed successfully; action pending\n", "notes": "", "submit_date": "2004-05-13", "submitter_name": "Scott Hollenbeck", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "239", "doc-id": "RFC3730", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.9.2.3", "orig_text": "S: ", "correct_text": "S: ", "notes": "Author knows the best :-).", "submit_date": "2004-11-22", "submitter_name": "\"Scott Hollenbeck\"", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "240", "doc-id": "RFC3730", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.9.2.3", "orig_text": "A acknowledgement response notes the number of messages remaining in\r\nthe queue and the ID of the next message available for retrieval.", "correct_text": "A acknowledgement response notes the ID of the message that has been\r\nacknowledged and the number of messages remaining in the queue.", "notes": " ", "submit_date": "2004-11-17", "submitter_name": "\"Scott Hollenbeck\"", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "241", "doc-id": "RFC3720", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.2.6.1", "orig_text": "The only exception is if a discovery session (see Section 2.3 iSCSI Session Types) is to be established.\r\n\r\n", "correct_text": "The only exception is if a discovery session (see Section 3.3 iSCSI Session Types) is to be established.", "notes": "Section 2.3 --> Section 3.3", "submit_date": "2004-09-01", "submitter_name": "Julian Satran", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "242", "doc-id": "RFC3715", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.1", "orig_text": " [RFC2663] Srisuresh, P. and M. Holdredge, \"IP Network Address\n Translator (NAT) Terminology and Considerations\", RFC\n 2663, August 1999.", "correct_text": " [RFC2663] Srisuresh, P. and M. Holdrege, \"IP Network Address\n Translator (NAT) Terminology and Considerations\", RFC\n 2663, August 1999.\n", "notes": "", "submit_date": "2004-03-13", "submitter_name": "Matt Holdrege", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "243", "doc-id": "RFC3712", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "[RFC2279] has been obsoleted by [RFC3629]. All citations to [RFC2279] should refer to [RFC3629].\n\n\n [RFC3629] Yergeau, F., \"UTF-8, a Transformation Format of ISO\n 10646\", RFC 3629, STD 63, November 2003.\n\n", "submit_date": "2004-09-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4323", "doc-id": "RFC6214", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8. Security", "orig_text": "", "correct_text": "", "notes": "New Physical and Link layer problem have been discovered and should be addressed in this RFC, and they are:\r\n1. Avian IP carriers are competing for air space with Unmanned Aerial Vehicle (UAV), and as such have a higher probability of packet collision at Layer 1 has increase in retransmissions.\r\n2. On path Avian IP carrier dropouts, caused by draughts, may also lead to a connection loss, and increase in retransmission.", "submit_date": "2015-04-01", "submitter_name": "Joe Klein", "verifier_id": "", "verifier_name": "Nevil Brownlee", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "227", "doc-id": "RFC3815", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "MplsFecEntry is defined as:", "orig_text": " MplsFecEntry ::= SEQUENCE {\r\n mplsFecIndex IndexInteger,\r\n mplsFecType INTEGER,\r\n mplsFecAddrType InetAddressType,\r\n mplsFecAddr InetAddress,\r\n mplsFecAddrPrefixLength InetAddressPrefixLength,\r\n mplsFecStorageType StorageType,\r\n mplsFecRowStatus RowStatus\r\n }", "correct_text": " MplsFecEntry ::= SEQUENCE {\r\n mplsFecIndex IndexInteger,\r\n mplsFecType INTEGER,\r\n mplsFecAddrPrefixLength InetAddressPrefixLength,\r\n mplsFecAddrType InetAddressType,\r\n mplsFecAddr InetAddress,\r\n mplsFecStorageType StorageType,\r\n mplsFecRowStatus RowStatus\r\n }\r\n\r\n", "notes": " \r\n \r\nBecause the OID assignments are:\r\n\r\nmplsFecAddrPrefixLength - mplsFecEntry.3\r\nmplsFecAddrType - mplsFecEntry.4\r\nmplsFecAddr - mplsFecEntry.5\n --VERIFIER NOTES-- \nAfter discussion with an author (Joan Cucchiara), a MIB Doctor (Mike Heard), and an MPLS MIB expert (Tom Nadeau), we conclude that no change is required.\r\n\r\nIn the words of Mike Heard...\r\n\r\n While this may be a poor practice, I don't think it actually\r\n violates RFC 2578. As far as I can see, the only thing it\r\n actually says is this:\r\n\r\n 7.10. Mapping of the OBJECT-TYPE value\r\n ...\r\n (2) If the object corresponds to a conceptual row, then at least one\r\n assignment, one for each column in the conceptual row, is present\r\n beneath that object. The administratively assigned name for each\r\n column is derived by appending a unique, positive sub-identifier to\r\n the administratively assigned name for the conceptual row.\r\n\r\n which does not put any ordering constraints on the sub-identifiers.\r\n\r\n Unless there is something that I have missed, it seems to me that\r\n this is not actually an erratum.\r\n\r\n", "submit_date": "2005-02-13", "submitter_name": "Michael Kirkham", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "228", "doc-id": "RFC3813", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "mplsLsrModuleReadOnlyCompliance", "orig_text": " OBJECT mplsInSegmentNPop\r\n SYNTAX Integer32 (1..1)\r\n MIN-ACCESS read-only\r\n DESCRIPTION \"Write access is not required. This object\r\n SHOULD be set to 1 if it is read-only.", "correct_text": " OBJECT mplsInSegmentNPop\r\n SYNTAX Integer32 (1)\r\n MIN-ACCESS read-only\r\n DESCRIPTION \"Write access is not required. This object\r\n SHOULD be set to 1 if it is read-only.", "notes": "Ref: RFC 2578, section 11.1:\r\n\r\n - when a pair of values is specified, the first value\r\n must be less than the second value.\r\n", "submit_date": "2005-02-13", "submitter_name": "Michael Kirkham", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "229", "doc-id": "RFC3813", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nDescription says:", "orig_text": " \"For creating, modifying, and deleting this row.\r\n When a row in this table has a row in the active(1)\r\n state, no objects in this row except this object\r\n and the mplsXCStorageType can be modified. \"", "correct_text": " \"For creating, modifying, and deleting this row.\r\n When a row in this table has a row in the active(1)\r\n state, no objects in this row except this object, the \r\n mplsXCStorageType and the mplsXCAdminStatus can be modified.\"", "notes": "", "submit_date": "2004-11-17", "submitter_name": "Stefan Winter", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "230", "doc-id": "RFC3783", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2", "orig_text": " and a Target Session Identifying Handler (TSIH) - each identifying\n one end of the same session.", "correct_text": " and a Target Session Identifying Handle (TSIH) - each identifying\n one end of the same session.", "notes": "", "submit_date": "2004-05-28", "submitter_name": "Eddy Quicksall", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "231", "doc-id": "RFC3782", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8", "orig_text": " When not in Fast Recovery, the value of the state variable \"recover\"\n should be pulled along with the value of the state variable for\n acknowledgments (typically, \"snd_una\") so that, when large amounts of\n data have been sent and acked, the sequence space does not wrap and\n falsely indicate that Fast Recovery should not be entered (Section 3,\n step 1, last paragraph).", "correct_text": " When updating the Cumulative Acknowledgement field outside of\n Fast Recovery, the \"recover\" state variable may also need to be\n updated in order to continue to permit possible entry into Fast\n Recovery (Section 3, step 1). This issue arises when an update\n of the Cumulative Acknowledgement field results in a sequence\n wraparound that affects the ordering between the Cumulative\n Acknowledgement field and the \"recover\" state variable. Entry\n into Fast Recovery is only possible when the Cumulative\n Acknowledgment field covers more than the \"recover\" state variable.", "notes": "\n", "submit_date": "2004-06-07", "submitter_name": "Sally Floyd", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "232", "doc-id": "RFC3777", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4", "orig_text": " One possible selection method is described in RFC 2777 [1].", "correct_text": " One possible selection method is described in RFC 3797 [1].", "notes": "\r\nReferences point to RFC 3797, not RFC 2777:\r\n [1] Eastlake, 3rd, D., \"Publicly Verifiable Nominations Committee\r\n (Nomcom) Random Selection\", RFC 3797, June 2004.\r\n\r\nRFC 3797 has obsoleted RFC 2777", "submit_date": "2006-08-31", "submitter_name": "Frank Ellermann", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "233", "doc-id": "RFC3770", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8", "orig_text": " id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 }\n", "correct_text": " id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 }\n", "notes": " ", "submit_date": "2005-01-22", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "234", "doc-id": "RFC3770", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4", "orig_text": " The WLAN SSID attribute certificate attribute is identified by\r\n id-aca-wlanSSID.\r\n\r\n id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)\r\n dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 }\r\n\r\n id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 }\r\n", "correct_text": " The WLAN SSID attribute certificate attribute is identified by\r\n id-aca-wlanSSID.\r\n\r\n id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)\r\n dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 }\r\n\r\n id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 7 }\r\n", "notes": "This same error is repeated in the ASN.1 Module (Section 8).", "submit_date": "2005-01-22", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "235", "doc-id": "RFC3744", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Issues and resolutions regarding this document can be reviewed at:\n\nhttp://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-issues.html\n\n\n\n", "submit_date": "2004-05-26", "submitter_name": "Julian Reschke", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "244", "doc-id": "RFC3712", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2", "orig_text": " Note: This attribute is based on 'printer-uri-supported', 'uri-\r\n authentication-supported', and `'uri-security-supported' (called the\r\n 'Three Musketeers' because they are parallel ordered attributes)\r\n", "correct_text": " Note: This attribute is based on 'printer-uri-supported', 'uri-\r\n authentication-supported', and 'uri-security-supported' (called the\r\n 'Three Musketeers' because they are parallel ordered attributes)\r\n", "notes": " \r\n Extraneous \"`\" in 2nd line.\r\n", "submit_date": "2004-09-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Bob Braden", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "245", "doc-id": "RFC3712", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "References", "orig_text": " \r\n [RFC2717] Petke, R. and I. King, \"Registration Procedures for URL\r\n Scheme Names\", RFC 2717, November 1999.\r\n\r\n [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,\r\n \"Guidelines for new URL Schemes\", BCP 19, RFC 2718,\r\n November 1999.\r\n\r\n [RFC2978] Freed, N. and J.Postel, \"IANA Charset Registration\r\n Procedures\", RFC2978, October 2000.\r\n", "correct_text": " \r\n [RFC2717] Petke, R. and I. King, \"Registration Procedures for URL\r\n Scheme Names\", RFC 2717, BCP 35, November 1999.\r\n\r\n [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,\r\n \"Guidelines for new URL Schemes\", RFC 2718, November\r\n 1999.\r\n\r\n [RFC2978] Freed, N. and J.Postel, \"IANA Charset Registration\r\n Procedures\", RFC2978, BCP 19, October 2000.", "notes": "", "submit_date": "2004-09-06", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Bob Braden", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "246", "doc-id": "RFC3696", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " The exact rule is that any ASCII character, including control\r\n characters, may appear quoted, or in a quoted string. When quoting\r\n is needed, the backslash character is used to quote the following\r\n character. For example\r\n\r\n Abc\\@def@example.com\r\n\r\n is a valid form of an email address. Blank spaces may also appear,\r\n as in\r\n\r\n Fred\\ Bloggs@example.com\r\n\r\n The backslash character may also be used to quote itself, e.g.,\r\n\r\n Joe.\\\\Blow@example.com", "correct_text": " The exact rule is that any ASCII character, including control\r\n characters, may appear quoted, or in a quoted string. When quoting\r\n is needed, the backslash character is used to quote the following\r\n character. For example\r\n\r\n \"Abc\\@def\"@example.com\r\n\r\n is a valid form of an email address. Blank spaces may also appear,\r\n as in\r\n\r\n \"Fred\\ Bloggs\"@example.com\r\n\r\n The backslash character may also be used to quote itself, e.g.,\r\n\r\n \"Joe.\\\\Blow\"@example.com", "notes": "", "submit_date": "2005-07-09", "submitter_name": "John C. Klensin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "247", "doc-id": "RFC3647", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "On page 68, it says:\n", "orig_text": " ------------------------------------------------------\n 4.6.6 Archive Collection System\n (Internal or External) 5.5.6\n ------------------------------------------------------\n 4.6.6 Procedures to Obtain and\n Verify Archive Information 5.5.7\n ------------------------------------------------------", "correct_text": " ------------------------------------------------------\n 4.6.6 Archive Collection System\n (Internal or External) 5.5.6\n ------------------------------------------------------\n 4.6.7 Procedures to Obtain and\n Verify Archive Information 5.5.7\n ------------------------------------------------------\n", "notes": "", "submit_date": "2004-04-21", "submitter_name": "Daniel Montpetit", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "248", "doc-id": "RFC3633", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "9", "orig_text": " If a requesting router receives an IA_PD with T1 greater than T2, and\r\n both T1 and T2 are greater than 0, the client discards the IA_PD\r\n option and processes the remainder of the message as though the\r\n delegating router had not included the IA_PD option.", "correct_text": " If a requesting router receives an IA_PD with T1 greater than T2, and\r\n both T1 and T2 are greater than 0, the requesting router discards the IA_PD\r\n option and processes the remainder of the message as though the\r\n delegating router had not included the IA_PD option.\r\n", "notes": " ", "submit_date": "2006-06-15", "submitter_name": "Hideshi Enokihara", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "249", "doc-id": "RFC3625", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": " VRAT = %x76 %x72 %x61 %x74", "correct_text": "", "notes": "This rule is important because without it, it isn't clear whether the \n\"vrat\" string is capitalized (like \"RIFF\" and \"QLCM\") or not (like \n\"fmt \" and \"data\").", "submit_date": "2005-08-30", "submitter_name": "Richard Walters", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "250", "doc-id": "RFC3588", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8.3.2", "orig_text": " Message Format\n\n ::= < Diameter Header: 258, PXY >\n < Session-Id >\n { Result-Code }\n { Origin-Host }\n { Origin-Realm }\n [ User-Name ]\n [ Origin-State-Id ]\n [ Error-Message ]\n [ Error-Reporting-Host ]\n * [ Failed-AVP ]\n * [ Redirect-Host ]\n [ Redirect-Host-Usage ]\n [ Redirect-Host-Cache-Time ]\n * [ Proxy-Info ]\n * [ AVP ]", "correct_text": " Message Format\n\n ::= < Diameter Header: 258, PXY >\n < Session-Id >\n { Result-Code }\n { Origin-Host }\n { Origin-Realm }\n [ User-Name ]\n [ Origin-State-Id ]\n [ Error-Message ]\n [ Error-Reporting-Host ]\n * [ Failed-AVP ]\n * [ Redirect-Host ]\n [ Redirect-Host-Usage ]\n [ Redirect-Max-Cache-Time ]\n * [ Proxy-Info ]\n * [ AVP ]", "notes": "\n\n", "submit_date": "2004-10-02", "submitter_name": "Alan McNamee", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "251", "doc-id": "RFC3588", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.5.2", "orig_text": " Message Format\n\n ::= < Diameter Header: 280 >\n { Result-Code }\n { Origin-Host }\n { Origin-Realm }\n [ Error-Message ]\n * [ Failed-AVP ]\n [ Original-State-Id ]", "correct_text": " Message Format\n\n ::= < Diameter Header: 280 >\n { Result-Code }\n { Origin-Host }\n { Origin-Realm }\n [ Error-Message ]\n * [ Failed-AVP ]\n [ Origin-State-Id ]", "notes": "\n", "submit_date": "2004-10-02", "submitter_name": "Alan McNamee", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "272", "doc-id": "RFC3445", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Values for the key protocol octet are incorrect. They should be:", "orig_text": " VALUE Protocol\r\n\r\n 0 -reserved\r\n 1 reserved (was TLS)\r\n 2 reserved (was email)\r\n 3 dnssec\r\n 4 reserved (was IPSEC)\r\n 5-255 reserved", "correct_text": "", "notes": "Rationale: Looking at RFC2535, the values are the original assignments. The\r\nnumbers in RFC3445 are incorrect and don't match. I guess since the\r\nregistry was closed, they are all reserved now and no one double checked.\r\n\r\nRFC 2535 has the original correct assignments, and the registry is correct\r\nin stating that they are now all reserved. ", "submit_date": "2005-02-22", "submitter_name": "\"Scott Rose\"", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "273", "doc-id": "RFC3424", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "The center page header:", "orig_text": " IAB Considerations for UNSAP Across NAT", "correct_text": " IAB Considerations for UNSAF Across NAT\n", "notes": "", "submit_date": "2002-11-19", "submitter_name": "Leslie Daigle", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5013", "doc-id": "RFC7250", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7", "orig_text": " IANA has allocated two new TLS extensions, client_certificate_type\r\n and server_certificate_type, from the \"TLS ExtensionType Values\"\r\n subregistry defined in [RFC5246].", "correct_text": " IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for\r\n client_certificate_type and server_certificate_type, respectively,\r\n in the \"TLS ExtensionType Values\" subregistry defined in [RFC5246].", "notes": "", "submit_date": "2017-05-10", "submitter_name": "i", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2025-11-11 18:54:11"}, {"errata_id": "252", "doc-id": "RFC3542", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "In section 10.2 (page 41), the RFC says:\n", "orig_text": " int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,\n uint8_t type, socklen_t len, uint_t align,\n void **databufp);\n", "correct_text": " int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,\n uint8_t type, socklen_t len, uint8_t align,\n void **databufp);\n", "notes": "Similarly, the following part of Section 15 (page 55)\n\n int inet6_opt_append(void *, socklen_t, int,\n uint8_t, socklen_t, uint_t,\n void **);\n\nShould actually be:\n\n int inet6_opt_append(void *, socklen_t, int,\n uint8_t, socklen_t,\n uint8_t, void **);\n\nThat is, \"uint_t\" should be replaced with \"uint8_t\".\n\n", "submit_date": "2004-02-12", "submitter_name": "Tatuya JINMEI", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "253", "doc-id": "RFC3542", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "11.3", "orig_text": " This cmsghdr will be passed to every socket that sets the\n IPV6_RECVPATHMTU socket option, even if the socket is non-connected.\n Note that this also means an application that sets the option may\n receive an IPV6_MTU ancillary data item for each ICMP too big error\n the node receives, including such ICMP errors caused by other\n applications on the node.", "correct_text": " This cmsghdr will be passed to every socket that sets the\n IPV6_RECVPATHMTU socket option, even if the socket is non-connected.\n Note that this also means an application that sets the option may\n receive an IPV6_PATHMTU ancillary data item for each ICMP too big error\n the node receives, including such ICMP errors caused by other\n applications on the node.", "notes": "Change: IPV6_MTU should be IPV6_PATHMTU.", "submit_date": "2005-06-26", "submitter_name": "Hideaki Yoshifuji", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "254", "doc-id": "RFC3537", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.4", "orig_text": " PAD : 38be62", "correct_text": " PAD : be62fe", "notes": "\n", "submit_date": "2004-10-14", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "255", "doc-id": "RFC3530", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8.1.8.", "orig_text": "This sequence establishes the use of an lock_owner and associated \nsequence number.\n\nShould be \"a lock_owner\"", "correct_text": "If server replica or a server immigrating a filesystem agrees to\n\nShould be \"If a server replica\"", "notes": "\nIn Section 9.3.2. Data Caching and File Locking, Last Paragraph:\n\n by flushing to the server more data upon an LOCKU than is covered by \nthe locked range.\n\nShould be \"a LOCKU\"\n\n", "submit_date": "2004-02-03", "submitter_name": "Jon Bauman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "256", "doc-id": "RFC3525", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Errata can be found in the ITU-T Implementor's Guide at:\nhttp://www.itu.int/itudoc/itu-t/com16/implgd/h248.1v1.html\n", "submit_date": "2005-09-13", "submitter_name": "Tom Taylor", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "257", "doc-id": "RFC3525", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nAppendix I says:", "orig_text": " MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {\r\n Context = 5000 {Modify = A4445} }", "correct_text": " MEGACO/1 [125.125.125.111]:55555 Reply = 50006 {\r\n Context = 5000 {Modify = A5555} }\r\n", "notes": "", "submit_date": "2005-04-28", "submitter_name": "Chen Rui", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "258", "doc-id": "RFC3507", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Errata for this document can be found at:\nhttp://www.measurement-factory.com/std/icap/\n\n\n\n", "submit_date": "2005-07-18", "submitter_name": "Alex Rousskov", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "261", "doc-id": "RFC3501", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "Section 2.3.1.1, page 8:\r\n old:\r\n A 32-bit value assigned to each message, which when used with the\r\n unique identifier validity value (see below) forms a 64-bit value\r\n that MUST NOT refer to any other message in the mailbox or any\r\n subsequent mailbox with the same name forever. Unique identifiers\r\n [...]\r\n new:\r\n An unsigned 32-bit value assigned to each message, which when used\r\n with the unique identifier validity value (see below) forms a 64-bit\r\n value that MUST NOT refer to any other message in the mailbox or any\r\n subsequent mailbox with the same name forever. Unique identifiers\r\n [...]\r\n-----\r\n\r\nSection 2.3.1.1, page 9:\r\n old:\r\n Associated with every mailbox are two values which aid in unique\r\n identifier handling: the next unique identifier value and the unique\r\n identifier validity value.\r\n new:\r\n Associated with every mailbox are two 32-bit unsigned values which\r\n aid in unique identifier handling: the next unique identifier value\r\n (UIDNEXT) and the unique identifier validity value (UIDVALIDITY).\r\n-----\r\n\r\nSection 5.1.3, page 19:\r\n old:\r\n All other characters (octet values 0x00-0x1f and 0x7f-0xff) are\r\n represented in modified BASE64, with a further modification from\r\n [UTF-7] that \",\" is used instead of \"/\". Modified BASE64 MUST NOT be\r\n used to represent any printing US-ASCII character which can represent\r\n itself.\r\n new:\r\n All other characters (octet values 0x00-0x1f and 0x7f-0xff) are\r\n represented in modified BASE64, with a further modification from\r\n [UTF-7] that \",\" is used instead of \"/\". Modified BASE64 MUST NOT be\r\n used to represent any printing US-ASCII character which can represent\r\n itself. Only characters inside the modified BASE64 alphabet are \r\n permitted in modified BASE64 text.\r\n-----\r\n\r\nSection 5.4, page 22:\r\n old:\r\n If a server has an inactivity autologout timer, the duration of that\r\n timer MUST be at least 30 minutes. The receipt of ANY command from \r\n the client during that interval SHOULD suffice to reset the\r\n autologout timer.\r\n new:\r\n If a server has an inactivity autologout timer that applies to\r\n sessions after authentication, the duration of that timer MUST be at\r\n least 30 minutes. The receipt of ANY command from the client during\r\n that interval SHOULD suffice to reset the autologout timer.\r\n\r\nSection 5.5, page 22:\r\n old:\r\n Note: UID FETCH, UID STORE, and UID SEARCH are different\r\n commands from FETCH, STORE, and SEARCH. If the client\r\n sends a UID command, it must wait for a completion result \r\n response before sending a command with message sequence\r\n numbers.\r\n new:\r\n Note: EXPUNGE responses are permitted while UID FETCH,\r\n UID STORE, and UID SEARCH are in progress. If the client\r\n sends a UID command, it must wait for a completion result\r\n response before sending a command which uses message\r\n sequence numbers (this may include UID SEARCH). Any\r\n message sequence numbers in an argument to UID SEARCH \r\n are associated with messages prior to the effect of any \r\n untagged EXPUNGE returned by the UID SEARCH.\r\n-----\r\n\r\nSection 6.2.1, page 27:\r\n old:\r\n Once [TLS] has been started, the client MUST discard cached \r\n information about server capabilities and SHOULD re-issue the \r\n CAPABILITY command. This is necessary to protect against man-in-\r\n the-middle attacks which alter the capabilities list prior to\r\n STARTTLS. The server MAY advertise different capabilities after\r\n STARTTLS.\r\n new:\r\n Once [TLS] has been started, the client MUST discard cached\r\n information about server capabilities and SHOULD re-issue the\r\n CAPABILITY command. This is necessary to protect against man-in-\r\n the-middle attacks which alter the capabilities list prior to\r\n STARTTLS. The server MAY advertise different capabilities, and\r\n in particular SHOULD NOT advertise the STARTTLS capability, after\r\n a successful STARTTLS command.\r\n-----\r\n\r\nSection 6.2.2, page 28:\r\n old:\r\n The authentication protocol exchange consists of a series of\r\n server challenges and client responses that are specific to the\r\n authentication mechanism. A server challenge consists of a \r\n command continuation request response with the \"+\" token followed \r\n by a BASE64 encoded string. The client response consists of a \r\n single line consisting of a BASE64 encoded string. If the client\r\n wishes to cancel an authentication exchange, it issues a line\r\n consisting of a single \"*\". If the server receives such a \r\n response, it MUST reject the AUTHENTICATE command by sending a\r\n tagged BAD response.\r\n new:\r\n The authentication protocol exchange consists of a series of \r\n server challenges and client responses that are specific to the\r\n authentication mechanism. A server challenge consists of a\r\n command continuation request response with the \"+\" token followed\r\n by a BASE64 encoded string. The client response consists of a\r\n single line consisting of a BASE64 encoded string. If the client\r\n wishes to cancel an authentication exchange, it issues a line \r\n consisting of a single \"*\". If the server receives such a \r\n response, or if it receives an invalid BASE64 string (e.g.\r\n characters outside the BASE64 alphabet, or non-terminal \"=\"), it\r\n MUST reject the AUTHENTICATE command by sending a tagged BAD\r\n response.\r\n\r\nSection 6.3.4, page 36:\r\n old:\r\n It is permitted to delete a name that has inferior hierarchical\r\n names and does not have the \\Noselect mailbox name attribute. In\r\n this case, all messages in that mailbox are removed, and the name\r\n will acquire the \\Noselect mailbox name attribute.\r\n new:\r\n It is permitted to delete a name that has inferior hierarchical \r\n names and does not have the \\Noselect mailbox name attribute. If\r\n the server implementation does not permit deleting the name while\r\n inferior hierarchical names exists the \\Noselect mailbox name\r\n attribute is set for that name. In any case, all messages in\r\n that mailbox are removed by the DELETE command.\r\n-----\r\n\r\nSection 6.3.10, page 44:\r\n old:\r\n Responses: untagged responses: STATUS\r\n new:\r\n Responses: REQUIRED untagged response: STATUS\r\n-----\r\n\r\nSection 6.4.3, page 49:\r\n old:\r\n The EXPUNGE command permanently removes all messages that have the\r\n \\Deleted flag set from the currently selected mailbox. Before \r\n returning an OK to the client, an untagged EXPUNGE response is\r\n sent for each message that is removed.\r\n new: \r\n The EXPUNGE command permanently removes all messages that have the\r\n \\Deleted flag set from the currently selected mailbox. Before\r\n returning an OK to the client, an untagged EXPUNGE response is\r\n sent for each message that is removed. Note that if any messages\r\n with the \\Recent flag set are expunged, an untagged RECENT response\r\n is sent after the untagged EXPUNGE(s) to update the client's count\r\n of RECENT messages.\r\n-----\r\n\r\nSection 6.4.4, page 50:\r\n old:\r\n [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in\r\n [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing\r\n text in a [CHARSET] other than US-ASCII. US-ASCII MUST be \r\n supported; other [CHARSET]s MAY be supported.\r\n new:\r\n [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in \r\n [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing \r\n text. US-ASCII MUST be supported; other [CHARSET]s MAY be supported.\r\n-----\r\n\r\nSection 6.4.4, page 50: \r\n old:\r\n In all search keys that use strings, a message matches the key if \r\n the string is a substring of the field. The matching is \r\n case-insensitive.\r\n new:\r\n In all search keys that use strings, a message matches the key if\r\n the string is a substring of the associated text. The matching is\r\n case-insensitive. Note that the empty string is a substring; this\r\n is useful when doing a HEADER search.\r\n-----\r\n\r\nSection 6.4.4, page 54:\r\n old: \r\n C: A284 SEARCH CHARSET UTF-8 TEXT {6}\r\n C: XXXXXX\r\n S: * SEARCH 43\r\n S: A284 OK SEARCH completed\r\n new:\r\n C: A284 SEARCH CHARSET UTF-8 TEXT {6}\r\n S: + Ready for literal text\r\n C: XXXXXX\r\n S: * SEARCH 43\r\n S: A284 OK SEARCH completed\r\n-----\r\n\r\nSection 7.2.2, page 70:\r\n old:\r\n If it is not feasible for the server to determine whether or not\r\n the mailbox is \"interesting\", or if the name is a \\Noselect name,\r\n the server SHOULD NOT send either \\Marked or \\Unmarked.\r\n new:\r\n If it is not feasible for the server to determine whether or not\r\n the mailbox is \"interesting\", the server SHOULD NOT send either\r\n \\Marked or \\Unmarked. The server MUST NOT send more than one of\r\n \\Marked, \\Unmarked, and \\Noselect for a single mailbox, and MAY\r\n send none of these.\r\n-----\r\n\r\nSection 7.4.2, page 75:\r\n old:\r\n body location\r\n A string list giving the body content URI as defined in\r\n [LOCATION].\r\n new:\r\n body location\r\n A string giving the body content URI as defined in \r\n [LOCATION].\r\n\r\nSection 7.4.2, page 77:\r\n old:\r\n body location\r\n A string list giving the body content URI as defined in\r\n [LOCATION].\r\n new:\r\n body location\r\n A string giving the body content URI as defined in \r\n [LOCATION].\r\n\r\n\r\nFormal Syntax, Page 84:\r\n old:\r\nCHAR8 = %x01-ff\r\n ; any OCTET except NUL, %x00\r\n new:\r\nCHAR8 = %x01-ff \r\n ; any OCTET except NUL, %x00\r\n\r\ncharset = atom / quoted\r\n-----\r\n\r\nFormal Syntax, Page 89:\r\n old:\r\nresp-text-code = \"ALERT\" /\r\n \"BADCHARSET\" [SP \"(\" astring *(SP astring) \")\" ] /\r\n new:\r\nresp-text-code = \"ALERT\" /\r\n \"BADCHARSET\" [SP \"(\" charset *(SP charset) \")\" ] /\r\n----- \r\n\r\nFormal Syntax, Page 89: \r\n old:\r\nsearch = \"SEARCH\" [SP \"CHARSET\" SP astring] 1*(SP search-key)\r\n new:\r\nsearch = \"SEARCH\" [SP \"CHARSET\" SP charset] 1*(SP search-key)\r\n-----\r\n\r\nFormal Syntax, Page 90: \r\n old:\r\nsequence-set = (seq-number / seq-range) *(\",\" sequence-set)\r\n new:\r\nsequence-set = (seq-number / seq-range) [\",\" sequence-set]\r\n----- \r\n\r\nFormal Syntax, Page 90:\r\n old:\r\nstatus-att-list = status-att SP number *(SP status-att SP number)\r\n new:\r\nstatus-att-val = (\"MESSAGES\" SP number) / (\"RECENT\" SP number) / \r\n (\"UIDNEXT\" SP nz-number) / (\"UIDVALIDITY\" SP nz-number) /\r\n (\"UNSEEN\" SP number)\r\n\r\nstatus-att-list = status-att-val *(SP status-att-val)\r\n-----\r\n\r\nIANA Considerations, Page 94:\r\n new:\r\n GSSAPI/Kerberos/SASL service names are registered by publishing a\r\n standards track or IESG approved experimental RFC. The registry\r\n is currently located at:\r\n\r\n http://www.iana.org/assignments/gssapi-service-names \r\n\r\n As this specification defines the \"imap\" service name previously\r\n defined in RFC 1731, the registry will be updated accordingly.\r\n----- \r\n\r\n\r\nNormative References, Page 95:\r\n old:\r\n [LANGUAGE-TAGS] Alvestrand, H., \"Tags for the Identification of\r\n Languages\", BCP 47, RFC 3066, January 2001. \r\n new:\r\n [LANGUAGE-TAGS] Alvestrand, H., \"Content Language Headers\",\r\n RFC 3282, May 2002.\r\n\r\n\r\nAppendix B, Page 103: \r\n new:\r\n 115) Add support for Content-Location to BODYSTRUCTURE.", "correct_text": "[see above] ", "notes": "from pending", "submit_date": "2007-06-13", "submitter_name": "Mark Crispin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "264", "doc-id": "RFC3494", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the \"Dependent Specifications\" section, it says: \n", "orig_text": "RFC 1781 is a technical specification for \"User Friendly Naming\"\nwhich replies on particular syntaxes described in RFC 1779.", "correct_text": "RFC 1781 is a technical specification for \"User Friendly Naming\"\nwhich relies on particular syntaxes described in RFC 1779.", "notes": "", "submit_date": "2004-10-15", "submitter_name": "Marshall Price", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "265", "doc-id": "RFC3492", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.4", "orig_text": " where maxint is the greatest integer for which maxint + 1 cannot be\n represented.", "correct_text": " where maxint is the maximum value of an integer variable.\n", "notes": "", "submit_date": "2003-04-28", "submitter_name": "Adam Costello", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "266", "doc-id": "RFC3490", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": " The ToUnicode output never contains more code points than its\n input.\n\nThis is not true; I have constructed a counterexample. ", "correct_text": " The Punycode decoder can never output more code points than it\n inputs, but Nameprep can, and therefore ToUnicode can.\n", "notes": "", "submit_date": "2003-04-28", "submitter_name": "Adam Costello", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "267", "doc-id": "RFC3473", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "OLD:", "orig_text": " [RFC2402] Kent, S. and R. Atkinson, \"IP Authentication\n Header\", RFC 2401, November 1998.\n\n [RFC2406] Kent, S. and R. Atkinson, \"IP Encapsulating\n Security Payload (ESP)\", RFC 2401, November 1998.", "correct_text": " [RFC2402] Kent, S. and R. Atkinson, \"IP Authentication\n Header\", RFC 2402, November 1998.\n\n [RFC2406] Kent, S. and R. Atkinson, \"IP Encapsulating\n Security Payload (ESP)\", RFC 2406, November 1998.\n", "notes": "", "submit_date": "2003-02-16", "submitter_name": "Steve Conner", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "268", "doc-id": "RFC3470", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.13", "orig_text": " \"numeric entity reference\" ", "correct_text": " \"numeric character reference\"", "notes": "Section 4.16:\n \"In XML instances all white space is considered significant and\n is by default visible to processing applications.\"\nShould be:\n \"In XML instances, white space is often significant and visible\n to processing applications.\"\n\n", "submit_date": "2003-04-25", "submitter_name": "Larry Masinter", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "269", "doc-id": "RFC3461", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.2", "orig_text": " A reference is made to RFC 1123, section 2.3.3, which does not exist. \n \n The correct section in RFC 1123 is 5.3.3.\n", "correct_text": "", "notes": "", "submit_date": "2003-03-31", "submitter_name": "Mieke Van de Kamp", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "270", "doc-id": "RFC3448", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": "If the sender does not receive a feedback report for two round\r\ntrip times, it cuts its sending rate in half.", "correct_text": "If the sender does not receive a feedback report for four round\r\ntrip times, it cuts its sending rate in half.", "notes": "Nofeedback timeout: Correct an inconsistency in the document.\r\n\r\n(collected by Sally Floyd, 2004-06-11)", "submit_date": "2003-03-04", "submitter_name": "Joerg Widmer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "7019", "doc-id": "RFC3986", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "B", "orig_text": "^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?", "correct_text": "^(([^:/?#]+):#)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?", "notes": "Added the missing '#\" delimiter.\n --VERIFIER NOTES-- \nIn rejecting this Errata report I note that the reported error is not an error, but a deliberate decision of the authors and working group. The change, therefore, if it is to be applied needs to be achieved through a consensus document and definitely not via an errata report.", "submit_date": "2022-07-10", "submitter_name": "Tim McSweeney", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2022-07-12 10:42:42"}, {"errata_id": "278", "doc-id": "RFC3414", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.3.1", "orig_text": " 4) Prepend K2 to the result of the step 4 and calculate MD5 digest\n over it according to [RFC1321]. Take the first 12 octets of the\n final digest - this is Message Authentication Code (MAC).", "correct_text": " 4) Prepend K2 to the result of the step 3 and calculate MD5 digest\n over it according to [RFC1321]. Take the first 12 octets of the\n final digest - this is Message Authentication Code (MAC).", "notes": "In Section 7.3.1:\n 4) Prepend K2 to the result of the step 4 and calculate SHA digest\n over it according to [SHA-NIST]. Take the first 12 octets of\n the final digest - this is Message Authentication Code (MAC).\nShould be:\n 4) Prepend K2 to the result of the step 3 and calculate SHA digest\n over it according to [SHA-NIST]. Take the first 12 octets of\n the final digest - this is Message Authentication Code (MAC).\n\n", "submit_date": "2003-10-28", "submitter_name": "Piotr Bandur", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "279", "doc-id": "RFC3413", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.5.1.1", "orig_text": " (2) If appropriate outgoing management target information cannot be\n found, the proxy forwarder increments the snmpProxyDrops\n counter [RFC1907], and then calls the Dispatcher using the\n returnResponsePdu abstract service interface.", "correct_text": " (2) If appropriate outgoing management target information cannot be\n found, the proxy forwarder increments the snmpProxyDrops\n counter [RFC3418], and then calls the Dispatcher using the\n returnResponsePdu abstract service interface. ", "notes": "In Sections 3.2 and 4.1.2: \n by [RFC1905]\nShould be:\n by [RFC3416]\n\n", "submit_date": "2002-12-27", "submitter_name": "Guan Hai Bing", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "280", "doc-id": "RFC3413", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Section 4.2.1, page 50, in DESCRIPTION clause of snmpNotifyFilterTable: ", "orig_text": " A more complete discussion of notification filtering \n can be found in section 6. of [SNMP-APPL].\" ", "correct_text": " A more complete discussion of notification filtering \n can be found in section 6. of RFC3413.\" ", "notes": "\nAdditionally, page 52, in DESCRIPTION clause of snmpNotifyFilterType: \n\n filter. A more detailed discussion of the use of this \n object can be found in section 6. of [SNMP-APPL].\" \n\nIt should be: \n\n filter. A more detailed discussion of the use of this \n object can be found in section 6. of RFC3413.\" \n\n\n", "submit_date": "2004-02-20", "submitter_name": "Eduardo Cardona", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "281", "doc-id": "RFC3410", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "10.2", "orig_text": " [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,\n \"Coexistence between Version 1 and Version 2 of the Internet-\n Standard Network Management Framework\", RFC 2576, January 1996.", "correct_text": " [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,\n \"Coexistence between Version 1 and Version 2 of the Internet-\n Standard Network Management Framework\", RFC 1908, January 1996.\n", "notes": "", "submit_date": "2003-01-29", "submitter_name": "C. M. Heard", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "282", "doc-id": "RFC3404", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.5", "orig_text": " See the\r\n Additional Information Processing section of RFC 3404 for more\r\n information on NAPTR records and the Additional Information section\r\n of a DNS response packet.", "correct_text": " See the\r\n Additional Information Processing section of RFC 3403 for more\r\n information on NAPTR records and the Additional Information section\r\n of a DNS response packet.", "notes": "wrong reference to RFC 3404 (must be RFC 3403)", "submit_date": "2006-10-05", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "283", "doc-id": "RFC3401", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": "Part Three: The Domain Name System (DNS) Database\" (RFC 3402) [1]", "correct_text": "Part Three: The Domain Name System (DNS) Database\" (RFC 3403) [2]\r\n", "notes": "", "submit_date": "2005-12-29", "submitter_name": "Olaf M. Kolkman", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "284", "doc-id": "RFC3394", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2.1", "orig_text": " P[i] The ith plaintext key data block\r\n C[i] The ith ciphertext data block\r\n A The 64-bit integrity check register\r\n R[i] An array of 64-bit registers where\r\n i = 0, 1, 2, ..., n\r\n A[t], R[i][t] The contents of registers A and R[i] after encryption\r\n step t.", "correct_text": " P[i] The ith (64-bit) plaintext key data block\r\n where i = 1, 2, ..., n\r\n C[i] The ith (64-bit) ciphertext data block\r\n where i = 0, 1, 2, ..., n\r\n A The 64-bit integrity check register\r\n R[i] An array of 64-bit registers where\r\n i = 1, 2, ..., n\r\n A[t], R[t][i] The contents of registers A and R[i] after encryption\r\n step t.", "notes": "", "submit_date": "2005-02-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "285", "doc-id": "RFC3389", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "In section 5.1, it says:\n\n m=audio 49230 RTP/AVP 101 102\n a=rtpmap:101 G7221/16000\n a=fmtp:121 bitrate=24000\n a=rtpmap:102 CN/16000", "correct_text": " m=audio 49230 RTP/AVP 101 102\n a=rtpmap:101 G7221/16000\n a=fmtp:101 bitrate=24000\n ^^^\n a=rtpmap:102 CN/16000\n", "notes": "", "submit_date": "2004-01-22", "submitter_name": "Magnus Westerlund", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2337", "doc-id": "RFC5777", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.2.10", "orig_text": "The Absolute-End-Fractional-Seconds AVP (AVP Code 569) is of type\r\nUnsigned32. The value specifies the fractional seconds that are\r\nadded to Absolute-End-Time value in order to determine when the time\r\nwindow ends. If this AVP is absent from the Time-Of-Day-Condition\r\nAVP, then the fractional seconds are assumed to be zero.", "correct_text": "The Absolute-Start-Fractional-Seconds AVP (AVP Code 569) is of type\r\nUnsigned32. The value specifies the fractional seconds that are\r\nadded to Absolute-End-Time value in order to determine when the time\r\nwindow ends. The Absolute-End-Fractional-Seconds represent \r\na 32-bit fraction field giving a precision of about 232 picoseconds \r\n( 1/((2^32)-1)) seconds ). If this AVP is absent from the Time-Of-Day-\r\nCondition AVP, then the fractional seconds are assumed to be zero.\r\nSee the Network Time Protocol [RFC 1305] for more precision.", "notes": "The AVP description lacked a explanation about what a fractional second is.", "submit_date": "2010-07-19", "submitter_name": "Francois Bard", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "306", "doc-id": "RFC3280", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": " [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1\n encoding rules: Specification of Basic Encoding Rules\n (BER), Canonical Encoding Rules (CER) and Distinguished\n Encoding Rules (DER), 1997.\n\n [X.690] ITU-T Recommendation X.690 Information Technology - Open\n Systems Interconnection - Procedures for the operation of\n OSI Registration Authorities: General procedures, 1992.", "correct_text": " [X.660] ITU-T Recommendation X.660 Information Technology - Open\n Systems Interconnection - Procedures for the operation of\n OSI Registration Authorities: General procedures, 1992.\n\n [X.690] ITU-T Recommendation X.690 Information Technology - ASN.1\n encoding rules: Specification of Basic Encoding Rules\n (BER), Canonical Encoding Rules (CER) and Distinguished\n Encoding Rules (DER), 1997.", "notes": "", "submit_date": "2005-08-01", "submitter_name": "Olivier Dierick", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "286", "doc-id": "RFC3385", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.1", "orig_text": " ///////////////////////////////////////////////////////////////////////\n // File: CRC32_D1.v\n // Date: Mon Nov 18 18:51:31 2002\n //\n // Copyright (C) 1999 Easics NV.\n // This source file may be used and distributed without restriction\n // provided that this copyright statement is not removed from the file\n // and that any derivative work contains the original copyright notice\n // and the associated disclaimer.\n //\n // THIS SOURCE FILE IS PROVIDED \"AS IS\" AND WITHOUT ANY EXPRESS\n // OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED\n // WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.\n //\n // Purpose: Verilog module containing a synthesizable CRC function\n // * polynomial: p(0 to 32) := \"100000101111011000111011011110001\"\n // * data width: 1\n //\n // Info: jand@easics.be (Jan Decaluwe)\n // http://www.easics.com\n ///////////////////////////////////////////////////////////////////////\n\n\n module CRC32_D1;\n \n // polynomial: p(0 to 32) := \"100000101111011000111011011110001\"\n // data width: 1\n function [31:0] nextCRC32_D1;\n\n input Data;\n input [31:0] CRC;\n \n reg [0:0] D;\n reg [31:0] C;\n reg [31:0] NewCRC;\n\n begin\n\n D[0] = Data;\n C = CRC;\n\n NewCRC[0] = D[0] ^ C[31];\n NewCRC[1] = C[0];\n NewCRC[2] = C[1];\n NewCRC[3] = C[2];\n NewCRC[4] = C[3];\n NewCRC[5] = C[4];\n NewCRC[6] = D[0] ^ C[5] ^ C[31];\n NewCRC[7] = C[6];\n NewCRC[8] = D[0] ^ C[7] ^ C[31];\n NewCRC[9] = D[0] ^ C[8] ^ C[31];\n NewCRC[10] = D[0] ^ C[9] ^ C[31];\n NewCRC[11] = D[0] ^ C[10] ^ C[31];\n NewCRC[12] = C[11];\n NewCRC[13] = D[0] ^ C[12] ^ C[31];\n NewCRC[14] = D[0] ^ C[13] ^ C[31];\n NewCRC[15] = C[14];\n NewCRC[16] = C[15];\n NewCRC[17] = C[16];\n NewCRC[18] = D[0] ^ C[17] ^ C[31];\n NewCRC[19] = D[0] ^ C[18] ^ C[31];\n NewCRC[20] = D[0] ^ C[19] ^ C[31];\n NewCRC[21] = C[20];\n NewCRC[22] = D[0] ^ C[21] ^ C[31];\n NewCRC[23] = D[0] ^ C[22] ^ C[31];\n NewCRC[24] = C[23];\n NewCRC[25] = D[0] ^ C[24] ^ C[31];\n NewCRC[26] = D[0] ^ C[25] ^ C[31];\n NewCRC[27] = D[0] ^ C[26] ^ C[31];\n NewCRC[28] = D[0] ^ C[27] ^ C[31];\n NewCRC[29] = C[28];\n NewCRC[30] = C[29];\n NewCRC[31] = C[30];\n\n nextCRC32_D1 = NewCRC;\n\n end\n\n endfunction\n\n endmodule\n", "correct_text": "", "notes": "", "submit_date": "2002-11-18", "submitter_name": "Vicente Cavanna", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "287", "doc-id": "RFC3377", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "This document updates RFCs 2251-2256, 2829 and 2830.\n", "submit_date": "2002-09-26", "submitter_name": "Jeff Hodges", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "288", "doc-id": "RFC3372", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "References to Figures 3, 5, and 7 should refer to Figures 2, 3, and 4, respectively.\n", "submit_date": "2002-09-22", "submitter_name": "Feng Zhang", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "289", "doc-id": "RFC3370", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": " [CMS] Housley, R., \"Cryptographic Message Syntax\", RFC 3269,\n August 2002.", "correct_text": " [CMS] Housley, R., \"Cryptographic Message Syntax\", RFC 3369,\n August 2002.\n", "notes": "", "submit_date": "2003-05-13", "submitter_name": "Henning Schulzrinne", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "290", "doc-id": "RFC3369", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "12.2", "orig_text": " AttributeCertificateVersion1\n { iso(1) member-body(2) us(840) rsadsi(113549)\n pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }\n\n DEFINITIONS EXPLICIT TAGS ::=\n BEGIN", "correct_text": "", "notes": "The tagging should be EXPLICIT instead of IMPLICIT.\n\n\n", "submit_date": "2004-03-12", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "291", "doc-id": "RFC3369", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Several object identifiers (OIDs) have been omitted from the ASN.1 module in section 12.1; however, these OIDs are fully discussed in the body of the document. On page 46 of RFC 3369, the following object identifiers need to be inserted before the end o", "orig_text": " -- Content Type Object Identifiers\n \n id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)\n us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }\n \n id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)\n us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }\n \n id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)\n us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }\n \n id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)\n us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }\n \n id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)\n us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }\n \n id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)\n us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }\n \n id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)\n us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) \n ct(1) 2 }\n", "correct_text": "", "notes": "", "submit_date": "2003-03-03", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "292", "doc-id": "RFC3369", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "13", "orig_text": " [CMSALG] Housley, R., \"Cryptographic Message Syntax (CMS)\n Algorithms\", RFC 3269, August 2002.", "correct_text": " [CMSALG] Housley, R., \"Cryptographic Message Syntax (CMS)\n Algorithms\", RFC 3370, August 2002.\n", "notes": "", "submit_date": "2003-01-23", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "293", "doc-id": "RFC3339", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.1", "orig_text": " The presence of optional punctuation would violate this characteristic.", "correct_text": " If the format allows optional punctuation or white space then this \n characteristic can be violated.", "notes": "In Appendix A, it says:\n Time:\n\n time-hour = 2DIGIT ; 00-24\n time-minute = 2DIGIT ; 00-59\n time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on\n ; leap-second rules\n time-fraction = (\",\" / \".\") 1*DIGIT\n time-numoffset = (\"+\" / \"-\") time-hour [[\":\"] time-minute]\n time-zone = \"Z\" / time-numoffset\n\n timeopt-hour = \"-\" / (time-hour [\":\"])\n timeopt-minute = \"-\" / (time-minute [\":\"])\n\n timespec-hour = time-hour [[\":\"] time-minute [[\":\"] time-second]]\n timespec-minute = timeopt-hour time-minute [[\":\"] time-second]\n timespec-second = \"-\" timeopt-minute time-second\n timespec-base = timespec-hour / timespec-minute / timespec-second\n\n time = timespec-base [time-fraction] [time-zone]\n\n iso-date-time = date \"T\" time\nIt should say:\n Time:\n\n time-hour = 2DIGIT ; 00-23\n time-minute = 2DIGIT ; 00-59\n time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on\n ; leap-second rules\n time-fraction = (\",\" / \".\") 1*DIGIT\n time-numoffset = (\"+\" / \"-\") time-hour [[\":\"] time-minute]\n time-zone = \"Z\" / time-numoffset\n\n timeopt-hour = \"-\" / (time-hour [\":\"])\n timeopt-minute = \"-\" / (time-minute [\":\"])\n\n timespec-hour = time-hour [[\":\"] time-minute [[\":\"] time-second]]\n timespec-minute = timeopt-hour time-minute [[\":\"] time-second]\n timespec-second = \"-\" timeopt-minute time-second\n timespec-base = timespec-hour / timespec-minute / timespec-second\n / timespec-midnight\n timespec-midnight = \"24\" [[\":\"] \"00\" [[\":\"] \"00\"]]\n\n time = timespec-base [time-fraction] [time-zone]\n\n iso-date-time = date \"T\" time\n\nIn the third paragraph of Appendix A, it states \"ISO 8601 is not clear on \nwhether an hour of 24 is permissible only if minutes and seconds are 0. \nThis assumes that an hour of 24 is permissible in any context.\"\n\nThis is clarified in the 2000 edition which says:\n 5.3 Time of the day\n\n The representation of the hour by [24] is only allowed to indicate\n midnight, see 5.3.2.\nThat would result in the following ABNF change:\n time-hour = 2DIGIT ; 00-23\nand additions:\n timespec-midnight = \"24\" [[\":\"] \"00\" [[\":\"] \"00\"]]\n timespec-base =/ timespec-midnight\n", "submit_date": "2005-05-26", "submitter_name": "Tony Finch", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "294", "doc-id": "RFC3315", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "20.1.2", "orig_text": " The relay agent copies the source address from the IP datagram in\r\n which the message was received from the client into the peer-address\r\n field in the Relay-forward message and sets the hop-count field to\r\n the value of the hop-count field in the received message incremented\r\n by 1.", "correct_text": " The relay agent copies the source address from the IP datagram in\r\n which the message was received from the relay agent into the peer-address\r\n field in the Relay-forward message and sets the hop-count field to\r\n the value of the hop-count field in the received message incremented\r\n by 1.\r\n", "notes": " ", "submit_date": "2006-06-29", "submitter_name": "Hideshi Enokihara", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "359", "doc-id": "RFC2927", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " Content-Type: text/directory; profile=\"schema-ldap-0\";charset=\"utf-8\"\n Content-Transfer-Encoding: Quoted-Printable\n ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) =\n ATTRIBUTES ( objectClass $ name ) SYNTAXES ( =\n 1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) )", "correct_text": " Content-Type: text/directory; profile=\"schema-ldap-0\";charset=\"utf-8\"\n Content-Transfer-Encoding: Quoted-Printable\n \n ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) =\n ATTRIBUTES ( objectClass $ name ) SYNTAXES ( =\n 1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) )\n", "notes": "", "submit_date": "2002-01-04", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "360", "doc-id": "RFC2925", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.1", "orig_text": " \"Generated at the completion of a ping test when the\n corresponding pingCtlTrapGeneration object is set to\n testCompletion(4).\"", "correct_text": " \"Generated at the completion of a ping test when the\n corresponding pingCtlTrapGeneration object is set to\n testCompletion(2).\"\n", "notes": "", "submit_date": "2002-03-26", "submitter_name": "Randy Presuhn", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "1059", "doc-id": "RFC1810", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "In the References, it says:", "orig_text": " [7] Touch, J., Optimized MD5 software, .\r\n", "correct_text": " [7] Touch, J., Optimized MD5 software, .\r\n", "notes": "I noticed a broken link. \r\n(the final \".Z\" is missing)", "submit_date": "2007-08-28", "submitter_name": "Denis Duault", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "295", "doc-id": "RFC3315", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "18.2.7", "orig_text": " After all the addresses have been processed, the server generates a\r\n Reply message and includes a Status Code option with the value\r\n Success, a Server Identifier option with the server's DUID, and a\r\n Client Identifier option with the client's DUID. For each IA in the\r\n Decline message for which the server has no binding information, the\r\n server adds an IA option using the IAID from the Release message and\r\n includes a Status Code option with the value NoBinding in the IA\r\n option. No other options are included in the IA option.", "correct_text": " After all the addresses have been processed, the server generates a\r\n Reply message and includes a Status Code option with the value\r\n Success, a Server Identifier option with the server's DUID, and a\r\n Client Identifier option with the client's DUID. For each IA in the\r\n Decline message for which the server has no binding information, the\r\n server adds an IA option using the IAID from the Decline message and\r\n includes a Status Code option with the value NoBinding in the IA\r\n option. No other options are included in the IA option.\r\n", "notes": "", "submit_date": "2006-06-29", "submitter_name": "Hideshi Enokihara", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "296", "doc-id": "RFC3314", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "1", "orig_text": " At that meeting, a decision was made to\r\n form a design team to write a document offering advice\r\n from the IPv6 WG to the 3GPP community, regarding\r\n their use of IPv6.", "correct_text": " At that meeting, a decision was made\r\n form a design team to write a document offering advice\r\n from the IPv6 WG to the 3GPP community, regarding\r\n their use of IPv6.\r\n", "notes": "\n --VERIFIER NOTES-- \nThe original text is grammatically correct.", "submit_date": "2005-03-28", "submitter_name": "Shiang-Ming Huang", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "297", "doc-id": "RFC3305", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.2.1", "orig_text": "* 'issn' defined by \"Using The ISSN as URN within an ISSN-URN\r\n Namespace\" (RFC 3043) [4]", "correct_text": "* 'issn' defined by \"Using The ISSN as URN within an ISSN-URN\r\n Namespace\" (RFC 3044) [4]\r\n", "notes": "", "submit_date": "2005-10-10", "submitter_name": "Tom Petch", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "298", "doc-id": "RFC3300", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2", "orig_text": " -------- Internet Official Protocol Standards 3003 1*", "correct_text": " -------- Internet Official Protocol Standards 3300 1*", "notes": "", "submit_date": "2002-11-15", "submitter_name": "Siegfried Schmitt", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "299", "doc-id": "RFC3297", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.1", "orig_text": " Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400", "correct_text": " Date: Wed,20 Sep 1995 00:18:00 -0400 (EDT)", "notes": "\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)\n\n\nIn section 8.2:\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)\n\n\nIn section 8.3:\n\nOLD:\n\n Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400\n\nNEW:\n\n Date: Wed, 20 Sep 1995 00:18:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)\n\n\nIn section 8.4:\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:18:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:19:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:21:00 -0400 (EDT)\n\n\nOLD:\n\n Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400\n\nNEW:\n\n Date: Wed,20 Sep 1995 00:22:00 -0400 (EDT)\n\n", "submit_date": "2004-05-06", "submitter_name": "Graham Klyne", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "307", "doc-id": "RFC3279", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": " This document specifies algorithm identifiers and ASN.1 [X.660]\n encoding formats for digital signatures and subject public keys used\n in the Internet X.509 Public Key Infrastructure (PKI).", "correct_text": " This document specifies algorithm identifiers and ASN.1 [X.690]\n encoding formats for digital signatures and subject public keys used\n in the Internet X.509 Public Key Infrastructure (PKI).", "notes": "\nIn Section 4, it says:\n [X.660] ITU-T Recommendation X.660 Information Technology -\n ASN.1 encoding rules: Specification of Basic Encoding\n Rules (BER), Canonical Encoding Rules (CER) and\n Distinguished Encoding Rules (DER), 1997.\nIt should say:\n [X.690] ITU-T Recommendation X.660 Information Technology -\n ASN.1 encoding rules: Specification of Basic Encoding\n Rules (BER), Canonical Encoding Rules (CER) and\n Distinguished Encoding Rules (DER), 1997.\n\n\n\n", "submit_date": "2005-08-01", "submitter_name": "Olivier Dierick", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "308", "doc-id": "RFC3275", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "A list of errata can be found at: http://www.w3.org/2001/10/xmldsig-errata\n", "submit_date": "2002-04-18", "submitter_name": "Joseph Reagle", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "309", "doc-id": "RFC3272", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.2", "orig_text": " The Internet evolved from the APARNET and adopted dynamic routing\n algorithms with distributed control to determine the paths that\n packets should take en-route to their destinations.", "correct_text": " The Internet evolved from the ARPANET and adopted dynamic routing\n algorithms with distributed control to determine the paths that\n packets should take en-route to their destinations.\n", "notes": "", "submit_date": "2002-06-18", "submitter_name": "Jean-Michel Grimaldi", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "310", "doc-id": "RFC3271", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": " Internet is for everyone - but it won't be if it cannot keep up\n with the explosive demand for its services, so we must dedicate\n ourselves to continuing its technological evolution and development\n of the technical standards the lie at the heart of the Internet\n revolution.", "correct_text": " Internet is for everyone - but it won't be if it cannot keep up\n with the explosive demand for its services, so we must dedicate\n ourselves to continuing its technological evolution and development\n of the technical standards that lie at the heart of the Internet\n revolution.\n", "notes": "", "submit_date": "2002-07-31", "submitter_name": "Robert deMallac", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5005", "doc-id": "RFC2100", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "References", "orig_text": " [4] Stearns, TS, _Old Possum's Book of Practical Cats_.", "correct_text": " [4] Eliot, TS, _Old Possum's Book of Practical Cats_.", "notes": "\"Stearns\" was T. S. Eliot's middle name. Old Possum's Book of Practical Cats was published under the name \"T. S. Eliot\".\r\n", "submit_date": "2017-04-28", "submitter_name": "Ben Harris", "verifier_id": "", "verifier_name": "Warren Kumari (Ops AD)", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "300", "doc-id": "RFC3289", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "In the process of implementing the RFC 3289 DiffServ MIB, the following\nerrors and discrepancies were noted.\n\n1. In the diffServClfrTable description (second paragraph),\ndiffServClfrStatus should be diffServClfrStorage. This is an\nunderstandability issue.\n\n2. The diffServClfrElementStatus description indicates that this entry\ncannot be deleted if there is a RowPointer pointing to it. A RowPointer\nis not used to select a classifier element, but rather the\ndiffServClfrId and diffServClfrElementId index values. Consequently,\nthe diffServClfrElementTable does not require a UsageCounter or a\nDestroyFlag. This is an understandability issue.\n\n3. In the diffServActionSpecific description (third paragraph)\nerroneously references a meter. This is an understandability issue.\n\n4. The diffServMinRateAbsolute description indicates that zero is a\nvalid value. The SYNTAX range indicates (1..4294967295), but should be\n(0..4294967295). This is an understandability issue and a MIB\nimplementation issue.\n\n5. The diffServMinRateRelative description indicates that zero is a\nvalid value and that the values are in units of 1/1000 of 1. The SYNTAX\nrange indicates (1..4294967295), but should be (0..1000). This is an\nunderstandability issue and a MIB implementation issue.\n\n6. The diffServMaxRateAbsolute description indicates that zero is a\nvalid value. The SYNTAX range indicates (1..4294967295), but should be\n(0..4294967295). This is an understandability issue and a MIB\nimplementation issue.\n\n7. The diffServMaxRateRelative description indicates that zero is a\nvalid value and that the values are in units of 1/1000 of 1. The SYNTAX\nrange indicates (1..4294967295), but should be (0..1000). This is an\nunderstandability issue and a MIB implementation issue.\n", "submit_date": "2002-08-08", "submitter_name": "Tom Irwin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "301", "doc-id": "RFC3289", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "1. During implementation, there has been some confusion on the \"reuse\nof structural elements\" in section 2.2. It is clear from the comments\nand the MIB that counters cannot be effectively reused. What appears\nconfusing is the case when an entire (or partial) DiffServ tree used for\na specific interface ifIndex and direction is reused. Is the DiffServ\ntree in this case just a template such that all of the data path\nelements are replicated (counters will not work properly) for another\ninterface? This seems reasonable since other data path elements such as\nqueues and schedulers are clearly interface dependent. It is important\nto remove this ambiguity since the RowPointer usage does not prohibit\nthis \"not generally recommended\" application. What is the intent?\n\n2. Minor update in section 3.2.2:\n ' Differentiated Services Code Point ' to\n ' Differentiated Services Code Point, including \"any\" '\n\n3. Figure 9b in section 3.7.2.1 is somewhat difficult at first to follow\ndue to how the multiplexing is shown in the Yellow \"Count Action\" (an\naction only has a single input).\n", "submit_date": "2002-08-27", "submitter_name": "Tom Irwin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "302", "doc-id": "RFC3281", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.4.6", "orig_text": " Clearance ::= SEQUENCE {\n policyId [0] OBJECT IDENTIFIER,\n classList [1] ClassList DEFAULT {unclassified},\n securityCategories [2] SET OF SecurityCategory OPTIONAL\n }", "correct_text": " Clearance ::= SEQUENCE {\n policyId OBJECT IDENTIFIER,\n classList ClassList DEFAULT {unclassified},\n securityCategories SET OF SecurityCategory OPTIONAL\n }", "notes": "The differences in tagging arose due to an unnoticed technical corrigendum (TC-2) being applied to the X.501 document during preparation of RFC 3281. The X.501 format is the correct form and will be included in a future update of RFC 3281. Implementers SHOULD modify their decoding functions to accept either format and, even if claiming RFC 3281 conformance, SHOULD output the (correct) X.501 format pending the issuing of a corrected RFC at which point the incorrect RFC 3281 format will no longer be specified.", "submit_date": "2003-03-07", "submitter_name": "Stephen Farrell", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "303", "doc-id": "RFC3281", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " AttributeCertificateInfo ::= SEQUENCE {\n version AttCertVersion -- version is v2,", "correct_text": " AttributeCertificateInfo ::= SEQUENCE {\n version AttCertVersion, -- version is v2,\n", "notes": "", "submit_date": "2004-08-26", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "304", "doc-id": "RFC3281", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.1", "orig_text": " The AC then contains the ciphertext inside its signed data. The\n EnvelopedData (id-envelopedData) ContentType is used, and the\n content field will contain the EnvelopedData type.", "correct_text": " Within EnvelopedData, the encapuslatedContentInfo identifies the\n content type carried withing the ciphertext. In this case, the \n contentType field of encapsulatedContentInfo MUST contain\n id-ct-attrCertEncAttrs, which has the following value:\n\n attrCertEncAttrs OBJECT IDENTIFIER ::=\n { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)\n\t pkcs9(9)\n id-smime(16) id-ct(1) 14 }\n", "notes": "\n", "submit_date": "2002-07-30", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "305", "doc-id": "RFC3280", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.3.3", "orig_text": " For each distribution point (DP) in the certificate CRL distribution\r\n points extension, for each corresponding CRL in the local CRL cache,\r\n while ((reasons_mask is not all-reasons) and (cert_status is\r\n UNREVOKED)) perform the following:\r\n\r\n (a) Update the local CRL cache by obtaining a complete CRL, a\r\n delta CRL, or both, as required:", "correct_text": " For each distribution point (DP) in the certificate CRL distribution\r\n points extension, for each corresponding CRL in the local CRL cache,\r\n while ((reasons_mask is not all-reasons) and (cert_status is\r\n UNREVOKED)) perform the following:\r\n\r\n (l) Set the reasons_mask state variable to the union of\r\n its previous value and the value of the interim_reasons_mask\r\n state variable.\r\n\r\n (a) Update the local CRL cache by obtaining a complete CRL, a\r\n delta CRL, or both, as required:\r\n", "notes": "", "submit_date": "2002-11-11", "submitter_name": "Takashi Ito", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2338", "doc-id": "RFC5245", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "15.1", "orig_text": "extension-att-name = byte-string ;from RFC 4566\r\n", "correct_text": "extension-att-name = token ;from RFC 4566\r\n", "notes": "\"extension-att-name\" may contain the SP (0x20) as defined for \"byte-string\" in RFC 4566.\r\nThe 'SP' character cannot be allowed within \"extension-att-name\" as it is also used as delimiter between \"extension-att-name\" and \"extension-att-value\".", "submit_date": "2010-07-20", "submitter_name": "Reif, Frank", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2625", "doc-id": "RFC4234", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "Appendix B.2", "orig_text": " Externally, data are represented as \"network virtual ASCII\" (namely,\r\n 7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to\r\n zero.", "correct_text": " Externally, data are represented as \"network virtual ASCII\" (namely,\r\n 7-bit US-ASCII in an 8-bit field, with the high (8th) bit set to\r\n zero).", "notes": "This change should make it clear (as in RFC 2234) that the phrase,\r\n\"with the high (8th) bit set to zero\" is an intrinsic part of the\r\nfull definition of \"network virtual ASCII\", and not the specification\r\nof an exception -- or an additional manipulation for the purpose of\r\nABNF -- to \"network virtual ASCII\".", "submit_date": "2005-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pete Resnick", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "320", "doc-id": "RFC3220", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "\r\nIn Section 3.6.1.2 (after current page 41), insert the following text:", "orig_text": " The Lifetime field is chosen as follows:\r\n\r\n - If the mobile node is registering with a foreign agent, the\r\n Lifetime SHOULD NOT exceed the value in the Registration Lifetime\r\n field of the Agent Advertisement message received from the\r\n foreign agent. When the method by which the care-of address is\r\n learned does not include a Lifetime, the default ICMP Router\r\n Advertisement Lifetime (1800 seconds) MAY be used.\r\n\r\n - The mobile node MAY ask a home agent to delete a particular\r\n mobility binding, by sending a Registration Request with the\r\n care-of address for this binding, with the Lifetime field set to\r\n zero (Section 3.8.2).\r\n\r\n - Similarly, a Lifetime of zero is used when the mobile node\r\n deregisters all care-of addresses, such as upon returning home.\r\n\r\n The Home Address field MUST be set to the mobile node's home address,\r\n if this information is known. Otherwise, the Home Address MUST be\r\n set to zeroes.\r\n\r\n The Home Agent field MUST be set to the address of the mobile node's\r\n home agent, if the mobile node knows this address. Otherwise, the\r\n mobile node MAY use dynamic home agent address resolution to learn\r\n the address of its home agent. In this case, the mobile node MUST\r\n set the Home Agent field to the subnet-directed broadcast address\r\n of the mobile node's home network. Each home agent receiving such\r\n a Registration Request with a broadcast destination address MUST\r\n reject the mobile node's registration and SHOULD return a rejection\r\n Registration Reply indicating its unicast IP address for use by the\r\n mobile node in a future registration attempt.\r\n\r\n The Care-of Address field MUST be set to the value of the particular\r\n care-of address that the mobile node wishes to (de)register. In the\r\n special case in which a mobile node wishes to deregister all care-of\r\n addresses, it MUST set this field to its home address.\r\n\r\n The mobile node chooses the Identification field in accordance with\r\n the style of replay protection it uses with its home agent. This is\r\n part of the mobility security association the mobile node shares with\r\n its home agent. See Section 5.7 for the method by which the mobile\r\n node computes the Identification field.\r\n\r\n\r\n3.6.1.3. Extensions\r\n\r\n This section describes the ordering of any mandatory and any optional\r\n Extensions that a mobile node appends to a Registration Request.\r\n This following ordering MUST be followed:", "correct_text": "", "notes": "\n --VERIFIER NOTES-- \nRFC 3220 has been obsoleted by RFC 3344. ", "submit_date": "2002-04-23", "submitter_name": "\"Charles E. Perkins\"", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "321", "doc-id": "RFC3220", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "5.7", "orig_text": " Whatever method is used, the low-order 32 bits of the Identification\r\n MUST be copied unchanged from the Registration Request to the Reply.\r\n The foreign agent uses those bits (and the mobile node's home\r\n address) to match Registration Requests with corresponding replies.\r\n of any Registration Reply are identical to the bits it sent in the\r\n Registration Request.", "correct_text": " Whatever method is used, the low-order 32 bits of the Identification\r\n MUST be copied unchanged from the Registration Request to the Reply.\r\n The foreign agent uses those bits (and the mobile node's home\r\n address) to match Registration Requests with corresponding replies.\r\n The mobile node MUST verify that the low-order 32 bits of any Registration \r\n Reply are identical to the bits it sent in the Registration Request.", "notes": "\n --VERIFIER NOTES-- \nRFC 3220 has been obsoleted by RFC 3344. ", "submit_date": "2002-04-23", "submitter_name": "\"Charles E. Perkins\"", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "322", "doc-id": "RFC3219", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "10.3.1.1", "orig_text": " - If the LS is configured to use the MultiExitDisc attribute to\n break ties, and the candidate routes differ in the value of the\n MultiExitDisc attribute, then select the route that has the\n lowest value of MultiExitDisc, else\n - Select the route that was advertised by the external LS that\n has the lowest TRIP Identifier.", "correct_text": " - If the LS is configured to use the MultiExitDisc attribute to\n break ties, and the candidate routes differ in the value of the\n MultiExitDisc attribute, then select the route that has the\n highest value of MultiExitDisc, else\n - Select the route that was advertised by the external LS that\n has the lowest ITAD number.\n", "notes": "", "submit_date": "2002-09-06", "submitter_name": "Jonathan Rosenberg", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "376", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1.4", "orig_text": " MAIL (or SEND, SOML, or SAML) MUST NOT be\r\n sent if a mail transaction is already open, i.e., it should be sent\r\n only if no mail transaction had been started in the session, or it\r\n the previous one successfully concluded with a successful DATA ^^ \r\n command, or if the previous one was aborted with a RSET.", "correct_text": " MAIL (or SEND, SOML, or SAML) MUST NOT be\r\n sent if a mail transaction is already open, i.e., it should be sent\r\n only if no mail transaction had been started in the session, or if\r\n the previous one successfully concluded with a successful DATA\r\n command, or if the previous one was aborted with a RSET.", "notes": "", "submit_date": "2004-03-23", "submitter_name": "Joel Woods", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "377", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": " Two types of information is used to rank the host addresses: multiple\r\n MX records, and multihomed hosts.", "correct_text": " Two types of information are used to rank the host addresses: multiple\r\n MX records, and multihomed hosts.", "notes": "The verb in that sentence should be \"are\" not \"is\".\r\n", "submit_date": "2002-10-17", "submitter_name": "Richard O. Hammer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "378", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.7", "orig_text": " In general, the availability of Mail eXchanger records in the domain\n name system [22, 27] makes the use of explicit source routes in the\n Internet mail system unnecessary. Many historical problems with\n their interpretation have made their use undesirable.", "correct_text": " In general, the availability of Mail eXchanger records in the domain\n name system [22, 27] makes the use of explicit source routes in the\n Internet mail system unnecessary. Many historical problems with the \n interpretation of explicit source routes have made their use undesirable.", "notes": "", "submit_date": "2002-10-03", "submitter_name": "Richard O. Hammer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "379", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.5.5", "orig_text": " All other types of messages (i.e., any message which is not required\r\n by a standards-track RFC to have a null reverse-path) SHOULD be sent\r\n with with a valid, non-null reverse-path.", "correct_text": " All other types of messages (i.e., any message which is not required\r\n by a standards-track RFC to have a null reverse-path) SHOULD be sent\r\n with a valid, non-null reverse-path.", "notes": "", "submit_date": "2004-03-31", "submitter_name": "Joel Woods", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "380", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "For a more complete collection of revisions, please see \r\ndraft-klensin-rfc2821bis-00.txt and the mailing list discussions.\r\n\r\nThe mailing list information is:\r\n\r\nList-Archive: \r\nList-ID: \r\nList-Subscribe: \r\n", "correct_text": "", "notes": "", "submit_date": "2005-09-10", "submitter_name": "John C Klensin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "381", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.7", "orig_text": "and subsequent distribution. SMTP, as specified here, is not ideally\r\nsuited for this role, and work is underway on standardized mail\r\nsubmission protocols that might eventually supercede the current practices. \r\n ^^^^^^^^^", "correct_text": "and subsequent distribution. SMTP, as specified here, is not ideally\r\nsuited for this role, and work is underway on standardized mail\r\nsubmission protocols that might eventually supersede the current practices. ", "notes": "", "submit_date": "2004-01-12", "submitter_name": "Vincent Lefevre", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "8099", "doc-id": "RFC7692", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "7.2.3.3", "orig_text": "The first 2 octets (0xc1 0x0b)\r\nare the WebSocket frame header (FIN=1, RSV1=1, RSV2=0, RSV3=0,\r\nopcode=text, MASK=0, Payload length=7).", "correct_text": "The first 2 octets (0xc1 0x0b)\r\nare the WebSocket frame header (FIN=1, RSV1=1, RSV2=0, RSV3=0,\r\nopcode=text, MASK=0, Payload length=11).", "notes": "The example frame has a payload length of 11, not 7.", "submit_date": "2024-09-11", "submitter_name": "Amichai Rothman", "verifier_id": "", "verifier_name": null, "update_date": null}, {"errata_id": "323", "doc-id": "RFC3208", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": " Options:\n\n This field encodes binary indications of the presence and\n significance of any options. It also directly encodes some\n options.\n\n bit 0 set => One or more Option Extensions are present\n\n bit 1 set => One or more Options are network-significant\n\n Note that this bit is clear when OPT_FRAGMENT and/or\n OPT_JOIN are the only options present.\n\n bit 6 set => Packet is a parity packet for a transmission\n\t group\n of variable sized packets (OPT_VAR_PKTLEN). Only present\n\t when\n OPT_PARITY is also present.\n\n bit 7 set => Packet is a parity packet (OPT_PARITY)\n\n Bits are numbered here from left (0 = MSB) to right (7 =\n\t LSB).\n\n All the other options (option extensions) are encoded in\n extensions to the PGM header.", "correct_text": " Options:\n\n This field encodes binary indications of the presence and\n significance of any options. It also directly encodes some\n options.\n\n bit 7 set => One or more Option Extensions are present\n\n bit 6 set => One or more Options are network-significant\n\n Note that this bit is clear when OPT_FRAGMENT and/or\n OPT_JOIN are the only options present.\n\n bit 1 set => Packet is a parity packet for a transmission\n\t group\n of variable sized packets (OPT_VAR_PKTLEN). Only present\n\t when\n OPT_PARITY is also present.\n\n bit 0 set => Packet is a parity packet (OPT_PARITY)\n\n Bits are numbered here from left (0 = MSB) to right (7 =\n\t LSB).\n\n All the other options (option extensions) are encoded in\n extensions to the PGM header.\n", "notes": "", "submit_date": "2002-09-17", "submitter_name": "Lorenzo Vicisano", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "324", "doc-id": "RFC3207", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "The document is missing a reference: [MIME-SEC] Galvin, J., Murphy, S., Crocker, S., and Freed, N.,\n \"Security Multiparts for MIME: Multipart/Signed and\n Multipart/Encrypted\", RFC 1847, October 1995.\n\n", "submit_date": "2002-02-13", "submitter_name": "Simon Josefsson", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "325", "doc-id": "RFC3204", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the Authors Address Section: ", "orig_text": " Francois Audet\n Nortel Networks\n 4301 Great America Parkway\n Santa Clara, CA 95054, USA\n EMail: mzonoun@nortelnetworks.com\n\n Mo Zonoun\n Nortel Networks\n 4301 Great America Parkway\n Santa Clara, CA 95054, USA\n EMail: audet@nortelnetworks.com", "correct_text": " Francois Audet\n Nortel Networks\n 4301 Great America Parkway\n Santa Clara, CA 95054, USA\n EMail: audet@nortelnetworks.com\n\n Mo Zonoun\n Nortel Networks\n 4301 Great America Parkway\n Santa Clara, CA 95054, USA\n EMail: mzonoun@nortelnetworks.com\n", "notes": "", "submit_date": "2001-12-13", "submitter_name": "Francois Audet", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "326", "doc-id": "RFC3189", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1", "orig_text": " a=fmtp:113 encode=SD-VCR/525-60\r\n a=fmtp:113 audio=none", "correct_text": " a=fmtp:113 encode=SD-VCR/525-60 audio=none", "notes": "", "submit_date": "2005-03-10", "submitter_name": "Stephen Casner", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "327", "doc-id": "RFC3180", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " The IANA has allocated 223/8 as per RFC 2770 [RFC2770].", "correct_text": " The IANA has allocated 233/8 as per RFC 2770 [RFC2770].\n", "notes": "", "submit_date": "2001-10-22", "submitter_name": "Steve Mattson", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "328", "doc-id": "RFC3174", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the Reference Section, it says:\n", "orig_text": " [FIPS 180-1] \"Secure Hash Standard\", United States of American,\n National Institute of Science and Technology, Federal\n Information Processing Standard (FIPS) 180-1, April\n 1993.", "correct_text": " [FIPS 180-1] \"Secure Hash Standard\", United States of America,\n National Institute of Science and Technology, Federal\n Information Processing Standard (FIPS) 180-1, April\n 1993.", "notes": "\n\"United States of American\" changed to \"United States of America\"", "submit_date": "2004-03-20", "submitter_name": "Christian Staudenmayer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2628", "doc-id": "RFC4757", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": "nonce (edata.Confounder, 8);\r\nmemcpy (edata.Data, data);\r\nedata.Checksum = HMAC (K2, edata);", "correct_text": "nonce (edata.Confounder, 8);\r\nmemcpy (edata.Data, data);\r\nedata.Checksum = HMAC (K2, concat(edata.Confounder, edata.Data));", "notes": "", "submit_date": "2010-11-12", "submitter_name": "Matthias Schertler", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "361", "doc-id": "RFC2919", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "3", "orig_text": "The syntax of the List-Id header follows:\r\n\r\n list-id-header = \"List-ID:\" [phrase] \"<\" list-id \">\" CRLF", "correct_text": "The syntax of the List-Id header follows:\r\n\r\n list-id-header = \"List-Id:\" [phrase] \"<\" list-id \">\" CRLF", "notes": " In order to bring it in line with the examples, and with common usage (by\r\nthe RFC, the List-ID is correct) most mail readers use the example and\r\ndo not consider the LHS case insensitive, since the RFC says:\r\n\r\nThe list header fields are subject to the encoding and character restrictions for mail headers as described in [RFC822].\r\n\r\nRFC822, while it says that most headers are character insensitive, does\r\nnot mandate that, and RFC 2919 only mandates that the List-Id: header is\r\nsubject to *encoding* and *character restrictions*, and does not say it\r\nneeds to adhere to case insensitivity.\r\n\r\nTherefore, the proposed change above will bring things more in line with common\r\nusage.\n --VERIFIER NOTES-- \nHeader field names are case insensitive per use of string literals from RFC 2234.", "submit_date": "2002-08-08", "submitter_name": "Trish Lynch", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "362", "doc-id": "RFC2916", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "* IN NAPTR 100 10 \"u\" \"ldap+E2U\" \"!^+46(.*)$!ldap://ldap.se/cn=01!\" .", "correct_text": "* IN NAPTR 100 10 \"u\" \"ldap+E2U\" \"!^+46(.*)$!ldap://ldap.se/cn=0\\1!\" .\r\n", "notes": "", "submit_date": "2000-09-27", "submitter_name": "Dr. Carsten Bormann", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "363", "doc-id": "RFC2916", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Erratum reported says that it should be:", "orig_text": "* IN NAPTR 100 10 \"u\" \"ldap+E2U\" \"!^+46(.*)$!ldap://ldap.se/cn=0\\1!\" .", "correct_text": "* IN NAPTR 100 10 \"u\" \"ldap+E2U\" \"!^+46(.*)$!ldap://ldap.se/cn=0\\\\1!\" .", "notes": "A double backslash is needed as single backslash is the escape\r\nchararacter in the presentation format of a TXT element.\r\nThe on wire format requires a single backslash which results\r\nin a double backslash in the presentation format.\r\n", "submit_date": "2006-04-12", "submitter_name": "Mark Andrews", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "364", "doc-id": "RFC2911", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "13", "orig_text": "\"redirection\" - 0x0200 to 0x02FF", "correct_text": "\"redirection\" - 0x0300 to 0x03FF", "notes": "", "submit_date": "2002-07-17", "submitter_name": "Tom Hastings", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "382", "doc-id": "RFC2820", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "The abstract says:", "orig_text": " This document describes the fundamental requirements of an access\r\n control list (ACL) model for the Lightweight Directory Application\r\n Protocol (LDAP) directory service. \r\n", "correct_text": " This document describes the fundamental requirements of an access\r\n control list (ACL) model for the Lightweight Directory Access\r\n Protocol (LDAP) directory service. \r\n", "notes": " ", "submit_date": "2005-01-06", "submitter_name": "Hallvard B Furuseth", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "329", "doc-id": "RFC3174", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.2", "orig_text": " /*\r\n * Initialize the first 16 words in the array W\r\n */\r\n for(t = 0; t < 16; t++)\r\n {\r\n W[t] = context->Message_Block[t * 4] << 24;\r\n W[t] |= context->Message_Block[t * 4 + 1] << 16;\r\n W[t] |= context->Message_Block[t * 4 + 2] << 8;\r\n W[t] |= context->Message_Block[t * 4 + 3];\r\n }", "correct_text": " /*\r\n * Initialize the first 16 words in the array W\r\n */\r\n for(t = 0; t < 16; t++)\r\n {\r\n W[t] = (uint32_t)(context->Message_Block[t * 4]) << 24;\r\n W[t] |= (uint32_t)(context->Message_Block[t * 4 + 1]) << 16;\r\n W[t] |= context->Message_Block[t * 4 + 2] << 8;\r\n W[t] |= context->Message_Block[t * 4 + 3];\r\n }", "notes": "Note that Message_Block is an array of \"integers of >= 16 bits\" as described in \"sha1.h\" but W[] is an array of unsigned 32-bit integers.\r\n\r\nWhile this works fine in many compilers, some compilers (e.g. Dynamic C v9.25) processing the line:\r\n\r\n W[t] = context->Message_Block[t * 4] << 24;\r\n\r\nwill take the 16 bit integer \"context->Message_Block[t * 4]\" and shift it left 24 bits, and then assign the resulting (still) 16 bit integer to the 32 bit integer W[t].\r\n\r\nThis will lead to a different (and undesired) result than the intended behavior of first promoting the 16 bit integer \"context->Message_Block[t * 4]\" to a 32 bit integer, and *then* shifting that 32 bit integer left 24 times, and storing the result in W[t].\r\n\r\nThe solution is to use an explicit cast. The last two lines of code in the for loop can remain as they are, as they will not suffer from the above problem and do not need the explicit cast.\r\n ", "submit_date": "2006-06-01", "submitter_name": "Ben Davis", "verifier_id": "", "verifier_name": "Nevil Brownlee", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "330", "doc-id": "RFC3165", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6", "orig_text": " SYNTAX Integer32 (1..2147483647)", "correct_text": " SYNTAX Integer32 (0..2147483647)\n", "notes": "", "submit_date": "2001-09-03", "submitter_name": "Juergen Schoenwaelder", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "331", "doc-id": "RFC3119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": " the encoding name SHALL be \"mp3\" (the same as the MIME subtype).", "correct_text": " the encoding name SHALL be \"mpa-robust\" (the same as the MIME\n subtype). ", "notes": "Appendix A:\n \"backpointer\": the size (in bytes) of the backpointer for this\n frame \nShould be:\n \"backpointer\": the value (expressed in bytes) of the backpointer for\n this frame\nAppendix A2:\n In the function \"insertDummyADUsIfNecessary()\":\n curADU\nShould be:\n prevADU\nAppendix B2:\n The two occurrences of \"32\" should be \"256\"\n\n", "submit_date": "2001-11-03", "submitter_name": "Ross Finlayson", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "332", "doc-id": "RFC3108", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.6", "orig_text": " The base specification for SDP, RFC 2327 [1], allows the definition f\n new attributes. In keeping with this spirit, some of the attributes\n defined in this document can also be used in SDP descriptions of IP\n nd other non-ATM sessions. For example, the 'vsel', 'dsel' and\n 'fsel' attributes defined below refer generically to codec-s. These\n can be bed for service-specific codec negotiation and assignment in\n non-ATM s well as ATM applications.", "correct_text": " The base specification for SDP, RFC 2327 [1], allows the definition of\n new attributes. In keeping with this spirit, some of the attributes\n defined in this document can also be used in SDP descriptions of IP\n and other non-ATM sessions. For example, the 'vsel', 'dsel' and\n 'fsel' attributes defined below refer generically to codecs. These\n can be used for service-specific codec negotiation and assignment in\n non-ATM as well as ATM applications.", "notes": "In Section 5.6.3: (First, Second and Third Bulleted items in List)\n * The 'silenceSupp' attribute, used to indicate the use of of\n voice activity detection for silence suppression, and to\n optionally parameterize the silence suppression function.\n\n * The 'ecan' attribute, used to indicate the use of of echo\n cancellation, and to parameterize the this function.\n\n * The 'gc' attribute, used to indicate the use of of gain\n control, and to parameterize the this function.\nShould be:\n * The 'silenceSupp' attribute, used to indicate the use of\n voice activity detection for silence suppression, and to\n optionally parameterize the silence suppression function.\n\n * The 'ecan' attribute, used to indicate the use of echo\n cancellation, and to parameterize the this function.\n\n * The 'gc' attribute, used to indicate the use of gain\n control, and to parameterize the this function.\nIn Section 5.6.3.3:\n When present, the 'ecan' attribute s is used to indicate the use or\n non-use of echo cancellation. There can be several 'ecan' lines in\n an SDP description.\nShould be:\n When present, the 'ecan' attribute is used to indicate the use or\n non-use of echo cancellation. There can be several 'ecan' lines in\n an SDP description.\nIn Section 5.6.6: (First numbered item)\n (1) The originating media gateway controller (OMGC) initiates\n service-level call establishment by sending the appropriate\n controlsmessage to the originating media gateway (OMG).\nShould be:\n (1) The originating media gateway controller (OMGC) initiates\n service-level call establishment by sending the appropriate\n control message to the originating media gateway (OMG).\nIn Section 6: (Sixth definition from top)\n Virtual Circui t Decimal or hex equivalent\n Identifier of 16 bits\nShould be:\n Virtual Circuit Decimal or hex equivalent\n Identifier of 16 bits\n\n", "submit_date": "2002-05-22", "submitter_name": "Rajesh Kumar", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "333", "doc-id": "RFC3104", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the References section, \"Holdrege\" is spelled incorrectly. It says:\n", "orig_text": " [NAT-TERMS] Srisuresh, P. and M. Holdredge, \"IP Network Address\n Translator (NAT) Terminology and Considerations\", RFC\n 2663, August 1999.", "correct_text": " [NAT-TERMS] Srisuresh, P. and M. Holdrege, \"IP Network Address\n Translator (NAT) Terminology and Considerations\", RFC\n 2663, August 1999.", "notes": "\n\n\n", "submit_date": "2004-03-13", "submitter_name": "Matt Holdrege", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "334", "doc-id": "RFC3083", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": " docsBpiCmAuthState OBJECT-TYPE\r\n SYNTAX INTEGER {\r\n \r\n authWait(2),\r\n authorized(3),\r\n reauthWait(4),\r\n authRejectWait(5)", "correct_text": " docsBpiCmAuthState OBJECT-TYPE\r\n SYNTAX INTEGER {\r\n\r\n start(1),\r\n authWait(2),\r\n authorized(3),\r\n reauthWait(4),\r\n authRejectWait(5)\r\n", "notes": "2014-07-14: comma added. Thanks to Mark Ellison for the correction.", "submit_date": "2001-04-10", "submitter_name": "Rich Woundy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "335", "doc-id": "RFC3069", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "customer C and resides in it's own virtual LAN, VLAN C.", "correct_text": "customer C and resides in its own virtual LAN, VLAN C.", "notes": "Notes/ Ooops. Ouch!", "submit_date": "2007-06-06", "submitter_name": "Bob Braden", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "336", "doc-id": "RFC3066", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.3", "orig_text": " This will ensure that, for example, a user who implements \"hwi\"\n (Hawaiian), which currently has no 2-letter code, will not find his\n or her data invalidated by eventual addition of a 2-letter code for\n that language.", "correct_text": " This will ensure that, for example, a user who implements \"haw\"\n (Hawaiian), which currently has no 2-letter code, will not find his\n or her data invalidated by eventual addition of a 2-letter code for\n that language.\n", "notes": "", "submit_date": "2002-07-30", "submitter_name": "David Hopwood", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "337", "doc-id": "RFC3066", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.2", "orig_text": " URL: http://www.loc.gov/standards/iso639", "correct_text": " http://www.loc.gov/standards/iso639-2/\n", "notes": "", "submit_date": "2001-02-01", "submitter_name": "Dr. Carsten Bormann", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "375", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.5", "orig_text": " When an SMTP server returns a permanent error status (5yz) code after\r\n the DATA command is completed with ., it MUST NOT make\r\n any subsequent attempt to deliver that message. ", "correct_text": " When an SMTP server returns a transient failure status (4yz) code after\r\n the DATA command is completed with ., it MUST NOT make\r\n any subsequent attempt to deliver that message. ", "notes": " Fixed in RFC 5321.", "submit_date": "2004-11-23", "submitter_name": "Jochen Topf", "verifier_id": "", "verifier_name": "Pete Resnick", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "338", "doc-id": "RFC3065", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "\r\nAppendix A says:", "orig_text": " The most notable change from [1] is that of reversing the values\r\n AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in\r\n section \"AS_CONFED Segment Type Extension\". The reasoning for this\r\n is that in the initial implementation, which was already widely\r\n deployed, they were implemented backwards from [4], and as such,\r\n subsequent implementations implemented them backwards as well. In\r\n order to foster interoperability and compliance with deployed\r\n implementations, they've therefore been changed here as well. ", "correct_text": " The most notable change from [5] is that of reversing the values\r\n AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in\r\n section \"AS_CONFED Segment Type Extension\". The reasoning foridely\r\n deployed, they were implemented backwards from [4], and as such,\r\n subsequent implementations implemented them backwards as well. In\r\n order to foster interoperability and compliance with deployed\r\n implementations, they've therefore been changed here as well.", "notes": "\r\nThere is an error in line 1 of Appendix A (RFC 3065). reference \r\nto document [1] is wrong and must be changed to [5].\r\n\n --VERIFIER NOTES-- \n Nikolai Malykh made an error in the submission of this erratum which was corrected in erratum 339.", "submit_date": "2006-01-25", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "339", "doc-id": "RFC3065", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nAppendix A says:", "orig_text": " The most notable change from [1] is that of reversing the values\r\n AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in\r\n section \"AS_CONFED Segment Type Extension\". The reasoning for this\r\n is that in the initial implementation, which was already widely\r\n deployed, they were implemented backwards from [4], and as such,\r\n subsequent implementations implemented them backwards as well. In\r\n order to foster interoperability and compliance with deployed\r\n implementations, they've therefore been changed here as well. ", "correct_text": " The most notable change from [4] is that of reversing the values\r\n AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in\r\n section \"AS_CONFED Segment Type Extension\". The reasoning foridely\r\n deployed, they were implemented backwards from [4], and as such,\r\n subsequent implementations implemented them backwards as well. In\r\n order to foster interoperability and compliance with deployed\r\n implementations, they've therefore been changed here as well.", "notes": "\r\nSorry for mistype error in my previous message.\r\nThere is a mistype error in line 1 of Appendix A (RFC 3065). reference \r\nto document [1] is wrong and must be changed to [4].", "submit_date": "2006-01-25", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "340", "doc-id": "RFC3062", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": " Traditionally, LDAP users where identified by the Distinguished Name\n [RFC2253] of a directory entry and this entry contained a userPassword\n [RFC2256] attribute containing one or more passwords.", "correct_text": " Traditionally, LDAP users were identified by the Distinguished\n Name [RFC2253] of a directory entry and this entry contained a\n userPassword [RFC2256] attribute containing one or more passwords.\n", "notes": "", "submit_date": "2001-03-07", "submitter_name": "Kurt Zeilenga", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "341", "doc-id": "RFC3056", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.3", "orig_text": "then\r\napply any security checks (see Section 8);", "correct_text": "then\r\napply any security checks (see Section 9);", "notes": "", "submit_date": "2002-11-20", "submitter_name": "Brian Carpenter", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "342", "doc-id": "RFC3052", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "In Section 7, Sid Nag has reverted back to his original EMail address: \n\n thinker@monmouth.com\n", "submit_date": "2002-11-20", "submitter_name": "Sid Nag", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "343", "doc-id": "RFC3047", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": " Encoding considerations:\n This type is only defined for transfer via RTP as specified\n\t in a Work in Progress.", "correct_text": " Encoding considerations:\n This type is only defined for transfer via RTP as specified\n\t in RFC 3047.\n", "notes": "", "submit_date": "2002-06-04", "submitter_name": "Colin Perkins", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "344", "doc-id": "RFC3037", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": " LDP is also useful in situations that require efficient hop-by-hop\n routed tunnels, such as MPLS-based VPN architectures [RFC2574] and\n tunneling between BGP border routers. ", "correct_text": " LDP is also useful in situations that require efficient hop-by-hop\n routed tunnels, such as MPLS-based VPN architectures [RFC2547] and\n tunneling between BGP border routers.\n", "notes": "", "submit_date": "2001-01-29", "submitter_name": "Elena Taguer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "345", "doc-id": "RFC3036", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "\r\nA reference for [Dobb] is missing.\r\n\r\nRationale:\r\nIn section 2.9.1, there is a mention of a problem\r\nwith MD5. The text refers to [Dobb] but the\r\nreference section contains no citation.\r\n\n --VERIFIER NOTES-- \nRFC3036 has been obsoleted by RFC5036.\r\nThe text that gives rise to this issue is a direct quote from RFC 2385. That reference should be explored to determine the full implications of the text.", "submit_date": "2006-04-13", "submitter_name": "Barbara Denny", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "346", "doc-id": "RFC3036", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.5.1.2.2", "orig_text": " If the TLV type is >= 0x8000 (high order bit 1) the TLV is\n silently dropped. Section \"Unknown TLV in Known Message Type\"\n elaborates on this behavior.", "correct_text": "", "notes": "There is no section with this title. The sentence in question should\nhave been deleted. It refers to a section that was deleted in a\nversion of the I-D that led to the RFC.\n", "submit_date": "2001-02-01", "submitter_name": "Elena Taguer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "347", "doc-id": "RFC3032", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.4.4", "orig_text": "C. If possible, transmit the ICMP Destination Unreachable \r\n Message to the source of the of the discarded datagram. ", "correct_text": "C. If possible, transmit the ICMP Destination Unreachable \r\n Message to the source of the discarded datagram. ", "notes": "As you can see, the text \"of the\" on the second line is \r\nrepeated twice. \r\n", "submit_date": "2006-01-25", "submitter_name": "Mario Zoppetti", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "348", "doc-id": "RFC3031", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.3", "orig_text": " LDP Label Distribution Protocol\r\n L2 Layer 2 L3 Layer 3\r\n LSP Label Switched Path", "correct_text": " LDP Label Distribution Protocol\r\n L2 Layer 2 \r\n L3 Layer 3\r\n LSP Label Switched Path", "notes": "there is a missing CR/LF", "submit_date": "2005-03-01", "submitter_name": "John Kristoff", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5006", "doc-id": "RFC8086", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8", "orig_text": " Section 3.1.9 of [RFC8085] discusses the congestion considerations\r\n for design and use of UDP tunnels;", "correct_text": " Section 3.1.11 of [RFC8085] discusses the congestion considerations\r\n for design and use of UDP tunnels;", "notes": "There appears to be an incorrect reference to 3.1.9 that should refer to 3.1.11.", "submit_date": "2017-04-28", "submitter_name": "Donald Eastlake", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "365", "doc-id": "RFC2883", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2.3", "orig_text": " Transmitted Received ACK Sent\n Segment Segment (Including SACK Blocks)\n\n 500-999 500-999 1000\n 1000-1499 (data packet dropped)\n 1500-1999 (delayed)\n 2000-2499 (data packet dropped)\n 2500-2999 (delayed)\n 3000-3499 (data packet dropped)\n 3500-3999 3500-3999 1000, SACK=3500-4000\n 1000-1499 (data packet dropped)\n 1500-2999 1500-1999 1000, SACK=1500-2000, 3500-4000\n 2000-2499 1000, SACK=2000-2500, 1500-2000,\n 3500-4000\n 1500-2999 1000, SACK=1500-2000, 1500-3000,\n ---------\n 3500-4000", "correct_text": " Transmitted Received ACK Sent\n Segment Segment (Including SACK Blocks)\n\n 500-999 500-999 1000\n 1000-1499 (data packet dropped)\n 1500-1999 (delayed)\n 2000-2499 (data packet dropped)\n 2500-2999 (delayed)\n 3000-3499 (data packet dropped)\n 3500-3999 3500-3999 1000, SACK=3500-4000\n 1000-1499 (data packet dropped)\n 1500-2999 1500-1999 1000, SACK=1500-2000, 3500-4000\n 2500-2999 1000, SACK=2500-3000, 1500-2000,\n 3500-4000\n 1500-2999 1000, SACK=1500-2000, 1500-3000,\n ---------\n 3500-4000", "notes": "", "submit_date": "2004-06-21", "submitter_name": "Noritoshi Demizu", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "366", "doc-id": "RFC2873", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the References Section: ", "orig_text": " [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,\n \"Assured Forwarding PHB Group\", RFC 2587, June 1999.", "correct_text": " [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,\n \"Assured Forwarding PHB Group\", RFC 2597, June 1999.\n", "notes": "", "submit_date": "2001-11-06", "submitter_name": "Kurt D. Zeilenga", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "367", "doc-id": "RFC2867", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.5", "orig_text": " Acct-Multi-Session-Id (51)", "correct_text": " Acct-Multi-Session-Id (50)\n", "notes": " ", "submit_date": "2005-05-31", "submitter_name": "Unai Pildain", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "368", "doc-id": "RFC2865", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.18", "orig_text": " Multiple Reply-Message's MAY be included and if any are displayed,\n they MUST be displayed in the same order as they appear in the\n packet.", "correct_text": " Multiple Reply-Messages MAY be included and if any are displayed,\n they MUST be displayed in the same order as they appear in the\n packet.\n", "notes": "", "submit_date": "2002-09-12", "submitter_name": "Aaron Webb", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "369", "doc-id": "RFC2858", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "8", "orig_text": " As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI\r\n attributes contain the Subsequence Address Family Identifier (SAFI)\r\n field. The SAFI name space is defined in Section 9. ...", "correct_text": "", "notes": "\r\nThere isn't SAFI name space definition in RFC 2858. This name name space \r\ndefinition presents in obsoleted RFC 2283 but completely removed from \r\nRFC 2858.", "submit_date": "2006-01-19", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "370", "doc-id": "RFC2858", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nIANA Considerations say:", "orig_text": "\"... The SAFI name space is defined in Section 9....\"", "correct_text": "\"... The SAFI name space is defined in Section 5....\"\r\n", "notes": "", "submit_date": "2005-02-04", "submitter_name": "Tom Petch", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "371", "doc-id": "RFC2846", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8", "orig_text": " global-phone = \"+\" 1*( DIGIT , written-sep )", "correct_text": " global-phone = \"+\" 1*( DIGIT / written-sep )", "notes": "", "submit_date": "2004-05-28", "submitter_name": "RFC Editor", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "372", "doc-id": "RFC2827", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "9", "orig_text": " [9] Thanks to: Craig Huegen; See:\r\n http://www.quadrunner.com/~chuegen/smurf.txt.", "correct_text": " [9] Thanks to: Craig Huegen; See:\r\n http://www.pentics.net/denial-of-service/white-papers/smurf.html.", "notes": " Tried to preserve the old URL, but could not. \n --VERIFIER NOTES-- \nAccording to the RFC editor: \r\n\r\nThe URL was correct at the time of publication, so we don't consider\r\nthis an erratum. That is, we don't believe errata should be used\r\nto update things that were true at the time of publication. I think\r\nusing the errata in this way muddies the system. \r\n\r\nAdditionally, using Google search\r\non \"Craig Huegen\" returns a link to \"Index of Craig Huegen's\r\nDenial-of-Service papers and presentations\", which seems sufficient.\r\n\r\n", "submit_date": "2002-11-20", "submitter_name": "Craig A. Huegen", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "373", "doc-id": "RFC2822", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2.6", "orig_text": " unstructured = *([FWS] utext) [FWS]", "correct_text": " unstructured = *([FWS] utext) (*WSP / obs-FWS)", "notes": "A prominent example is the defined in section 3.6.5:\r\n\r\n subject = \"Subject:\" unstructured CRLF\r\n\r\nExpanding the [FWS] at the end (ignoring ) results in:\r\n\r\n subject = \"Subject:\" *([FWS] utext) [[*WSP CRLF] 1*WSP] CRLF\r\n\r\n\r\nAlexey: note that this was fixed in RFC 5322 (which obsoleted RFC 2821) in a slightly different way.\r\n", "submit_date": "2006-01-10", "submitter_name": "Frank Ellermann", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2810", "doc-id": "RFC3226", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1", "orig_text": "DNSSEC OK[OK] specifies how ...", "correct_text": "DNSSEC OK[RFC3225] specifies how ...", "notes": "Reference \"link\" is broken.", "submit_date": "2011-05-18", "submitter_name": "Edward Lewis", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2811", "doc-id": "RFC3110", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": "Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.", "correct_text": "Leading zero bytes MUST be added to the RSA/SHA1 algorithm signature \r\nso that the signature size in bytes is equal to the size of n in bytes.", "notes": "The Original Text implies that zero-padding of RSA signaturs is optional, however the underlying standard requires zero padding, http://tools.ietf.org/html/rfc2437#section-8.1.1\r\n\r\n\"4. Convert the signature representative s to a signature S of length k octets: S = I2OSP (s, k)\"\r\n\r\nwhere k is the length of the modulus in bytes. If the extra bytes are not added, standard RSA libraries will fail to verify the signature about 1% of the time when the padding occurs.", "submit_date": "2011-05-21", "submitter_name": "George Barwood", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2629", "doc-id": "RFC4616", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1", "orig_text": " Specifications for IETF protocols that indicate that this\r\n mechanism is an applicable authentication mechanism MUST mandate that\r\n implementations support an strong data security service, such as TLS.", "correct_text": " Specifications for IETF protocols that indicate that this\r\n mechanism is an applicable authentication mechanism MUST mandate that\r\n implementations support a strong data security service, such as TLS.", "notes": "Just a typo in \"a strong data security service\".", "submit_date": "2010-11-12", "submitter_name": "Julien \u00c9lie", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "387", "doc-id": "RFC2810", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.2.1", "orig_text": " In IRC the channel has a role equivalent to that of the multicast\n group; their existence is dynamic and the actual conversation carried\n out on a channel MUST only be sent to servers which are supporting\n users on a given channel. Moreover, the message SHALL only be sent\n once to every local link as each server is responsible to fan the\n original message to ensure that it will reach all the recipients.\n\n The following examples all refer to Figure 2.", "correct_text": " In IRC the channel has a role equivalent to that of the multicast\n group; their existence is dynamic and the actual conversation carried\n out on a channel MUST only be sent to servers which are supporting\n users on a given channel. Moreover, the message SHALL only be sent\n once to every local link as each server is responsible to fan the\n original message to ensure that it will reach all the recipients.\n\n The following examples all refer to Figure 1.", "notes": "\nThere is no \"Figure 2\".", "submit_date": "2004-02-25", "submitter_name": "Christophe Kalt", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "388", "doc-id": "RFC2786", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "The title was mis-spelled: ", "orig_text": " Diffie-Helman USM Key Management Information Base and Textual\n Convention ", "correct_text": " Diffie-Hellman USM Key Management Information Base and Textual\n Convention\n", "notes": "", "submit_date": "2001-08-17", "submitter_name": "David Harrington", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "389", "doc-id": "RFC2764", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "There is a case of sections being numbered wrong: ", "orig_text": " 5.3.3.1 Stub Link Connectivity Scenarios ........................ 30\n 5.3.3.1 Routing Protocol Instance ............................... 31\n", "correct_text": "", "notes": "", "submit_date": "2001-02-01", "submitter_name": "Elena Taguer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "390", "doc-id": "RFC2763", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": " A router may also optionally insert this TLV in it's pseudo node LSP\n for the association of a symbolic name to a local LAN.", "correct_text": " A router may also optionally insert this TLV in its pseudo node LSP\n for the association of a symbolic name to a local LAN.\n", "notes": "", "submit_date": "2002-06-28", "submitter_name": "Brian Vine", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "391", "doc-id": "RFC2759", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.3", "orig_text": " 0-to-256-unicode-char Password:\n 4D 79 50 77\n\n 16-octet PasswordHash:\n FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC", "correct_text": " 0-to-256-char Password:\n 4D 79 50 77\n\n 0-to-256-unicode-char NtPassword:\n 4D 00 79 00 50 00 77 00\n\n 16-octet NtPasswordHash:\n FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC\n", "notes": "", "submit_date": "2002-08-26", "submitter_name": "Andrew Roughan", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "392", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.3.2", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 1 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Rtr Pri | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | HelloInterval | RouterDeadInterval |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Designated Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Backup Designated Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 1 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Rtr Pri | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | HelloInterval | RouterDeadInterval |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Designated Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Backup Designated Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "393", "doc-id": "RFC2740", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2.5", "orig_text": " Link-local unicast addresses are assigned from the IPv6 address\r\n range FF80/10.", "correct_text": " Link-local unicast addresses are assigned from the IPv6 address\r\n range FE80::/10.\r\n", "notes": " \r\n The IPv6 link-local address range is incorrect.", "submit_date": "2003-02-22", "submitter_name": "Acee Lindem", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "394", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.1.2", "orig_text": "The Interface ID appears in Hello packets sent out the interface,\r\nthe link-local-LSA originated by router for the attached link, and\r\nthe router-LSA originated by the router-LSA for the associated area.", "correct_text": "The Interface ID appears in Hello packets sent out the interface,\r\nthe link-local-LSA originated by router for the attached link, and\r\nthe router-LSA originated by the router for the associated area.\r\n", "notes": "", "submit_date": "2001-08-21", "submitter_name": "Wu Qian", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "395", "doc-id": "RFC2737", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the header:", "orig_text": " Network Working Group K. McCloghrie\n Request for Comments: 2737 Cisco Systems, Inc.\n Obsoletes: 2037 A. Bierman\n Cisco Systems, Inc.\n December 1999", "correct_text": " Network Working Group K. McCloghrie\n Request for Comments: 2737 Cisco Systems, Inc.\n Obsoletes: 2037 A. Bierman\n Category: Standards Track Cisco Systems, Inc.\n December 1999\n", "notes": "", "submit_date": "2001-09-21", "submitter_name": "RFC Editor", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "396", "doc-id": "RFC2731", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "11", "orig_text": " [HARVEST] Harvest Web Indexing.\n http://www.tardis.ed.ac.uk/harvest/", "correct_text": " [HARVEST] Harvest: A distributed Search System.\n http://harvest.sourceforge.net/\n", "notes": "", "submit_date": "2002-09-04", "submitter_name": "Kang-Jin Lee", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "397", "doc-id": "RFC2681", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1", "orig_text": "Then the 50th percentile would be 110 msec, since 90 msec and 100\r\nmsec are smaller and 110 msec and 'undefined' are larger.", "correct_text": "Then the 50th percentile would be 110 msec, since 90 msec and 100 msec\r\nare smaller and 500 msec and 'undefined' are larger. See Section 11.3\r\nof [1] for computing percentiles.", "notes": " Corrected text suggested by Matt Zekauskas (matt@internet2.edu).", "submit_date": "2002-11-18", "submitter_name": "Andrew Main", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "398", "doc-id": "RFC2679", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5.1", "orig_text": " Then the 50th percentile would be 110 msec, since 90 msec and 100\r\n msec are smaller and 110 msec and 'undefined' are larger.", "correct_text": " Then the 50th percentile would be 110 msec, since 90 msec and 100\r\n msec are smaller and 500 msec and 'undefined' are larger. See\r\n Section 11.3 of [1] for computing percentiles.", "notes": " See the list of samples immediately preceding that paragraph.", "submit_date": "2002-11-18", "submitter_name": "Andrew Main", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "399", "doc-id": "RFC2676", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2.1", "orig_text": " 0 8 16\n | | |\n -----------------\n |EXP| MANT |\n -----------------", "correct_text": " 0 8 15\n | | |\n -----------------\n |EXP| MANT |\n -----------------\n", "notes": "", "submit_date": "2002-07-09", "submitter_name": "Jussi Savolainen", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "8962", "doc-id": "RFC1436", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "4", "orig_text": "C: Opens Connection.\r\nC: Sends Selector String, Tab, Search String.\r\nS: Sends Menu Entity.", "correct_text": "C: Opens Connection.\r\nS: Accepts Connection\r\nC: Sends Selector String, Tab, Search String.\r\nS: Sends Menu Entity.", "notes": "The \"Full-Text Search Transaction\" section lacks the \"S: Accepts Connection\" step of the transaction.\r\n\r\n(tangentially, the \"Accepts Connection\" vs \"Accepts connection\" is inconsistent throughout the document, so it wouldn't hurt to choose one capitalization and stick to it)", "submit_date": "2026-06-04", "submitter_name": "Tim Chase", "verifier_id": "", "verifier_name": null, "update_date": "2026-06-05 19:01:52"}, {"errata_id": "404", "doc-id": "RFC2645", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.2.1", "orig_text": " If the authentication used by the customer does not provide access to\r\n all of the domains specified in ATRN, the provider MUST NOT send mail\r\n for any domains to the customer; the provider MUST reject the ATRN\r\n command with a 450 code.", "correct_text": " If the authentication used by the customer does not provide access to\r\n all of the domains specified in ATRN, the provider MUST NOT send mail\r\n for any domains to the customer; the provider MUST reject the ATRN\r\n command with a 550 code.", "notes": "This seems to be contrary to SMTP's theory of reply codes:\r\n\r\nA rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated\r\nwithout any change in command form or in properties of the sender\r\nor receiver (that is, the command is repeated identically and the\r\nreceiver does not put up a new implementation.)\r\n\r\nIf the ODMR client repeats the ATRN request in this situation, it will be rejected again. So a 550 response would be more appropriate.\r\n\r\n", "submit_date": "2005-08-30", "submitter_name": "Tony Finch", "verifier_id": "", "verifier_name": "Barry Leiba", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "405", "doc-id": "RFC2633", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.5", "orig_text": " This may be useful in an environment were automatic signature\n verification is desired, as no private key material is required to\n verify a signature.", "correct_text": " This may be useful in an environment where automatic signature\n verification is desired, as no private key material is required to\n verify a signature.\n", "notes": "", "submit_date": "2003-03-12", "submitter_name": "Joni Yrjana", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "406", "doc-id": "RFC2630", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "12.2.2", "orig_text": "The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC\r\n2347 specifies the use of the RSA signature algorithm with the SHA-1\r\nand MD5 message digest algorithms.", "correct_text": "The RSA signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC\r\n2437 specifies the use of the RSA signature algorithm with the SHA-1\r\nand MD5 message digest algorithms.", "notes": "", "submit_date": "2000-12-26", "submitter_name": "Joseph Baran", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "407", "doc-id": "RFC2625", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.1", "orig_text": "1. This table applies only to FC-4 related data, such as IP and\r\n ARP packets. This table does not apply to link services and\r\n other non-FC-4 sequences (PLOGI, for example) that must occur\r\n for normal operation.", "correct_text": "1. This table does not apply to FARP-REQ and FARP-REPLY.", "notes": "", "submit_date": "2003-07-21", "submitter_name": "Elizabeth G. Rodriguez", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "408", "doc-id": "RFC2616", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.6", "orig_text": " The Internet Assigned Numbers Authority (IANA) acts as a registry for\n transfer-coding value tokens. Initially, the registry contains the\n following tokens: \"chunked\" (section 3.6.1), \"identity\" (section\n 3.6.2), \"gzip\" (section 3.5), \"compress\" (section 3.5), and\n \"deflate\" (section 3.5).", "correct_text": "", "notes": "There is no section 3.6.2; there is no such thing as Transfer-Coding:\nidentity in the RFC 2616 specification (note that there would not be\nquotes around \"identity\" in the actual header!).", "submit_date": "2001-10-08", "submitter_name": "Greg Robson", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "410", "doc-id": "RFC2617", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "All known errata for this HTTP RFC will be found at: \r\nhttp://purl.org/NET/http-errata and \r\nhttp://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/\r\n\r\n", "submit_date": "2001-01-05", "submitter_name": "Scott Lawrence", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "411", "doc-id": "RFC2616", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "14.3", "orig_text": "The Accept-Encoding request-header field is similar to Accept, but\r\nrestricts the content-codings (section 3.5) that are acceptable in\r\nthe response.\r\n\r\n Accept-Encoding = \"Accept-Encoding\" \":\"\r\n\r\n 1#( codings [ \";\" \"q\" \"=\" qvalue ] )\r\n codings = ( content-coding | \"*\" )\r\n\r\n Examples of its use are:\r\n\r\n Accept-Encoding: compress, gzip\r\n Accept-Encoding:\r\n Accept-Encoding: *\r\n Accept-Encoding: compress;q=0.5, gzip;q=1.0\r\n Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0", "correct_text": "The Accept-Encoding request-header field is similar to Accept, but\r\nrestricts the content-codings (section 3.5) that are acceptable in\r\nthe response.\r\n\r\n Accept-Encoding = \"Accept-Encoding\" \":\"\r\n\r\n 1#( codings [ \";\" \"q\" \"=\" qvalue ] )\r\n codings = ( content-coding | \"*\" )\r\n\r\n Examples of its use are:\r\n\r\n Accept-Encoding: compress, gzip\r\n Accept-Encoding: *\r\n Accept-Encoding: compress;q=0.5, gzip;q=1.0\r\n Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0", "notes": "As you can see, Accept-Encoding has to consist of 1 or more ( codings [ \";\"\r\n\"q\" \"=\" qvalue ] ). So you can't just leave the value of \"Accept-Encoding:\"\r\nempty. The second example is, therefore, incorrect.\r\n\r\n------------------------------------------------\r\nAlexey: This issue was fixed in HTTPBIS WG, see ", "submit_date": "2006-10-31", "submitter_name": "WooJin Chung", "verifier_id": "", "verifier_name": "Barry Leiba", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "412", "doc-id": "RFC2616", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "From Scott Lawrence:\r\nAll known errata for this HTTP RFC will be found at: \r\nhttp://purl.org/NET/http-errata and \r\nhttp://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/\r\n\r\n\r\n", "submit_date": "2001-01-05", "submitter_name": "Justin Erenkrantz", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "424", "doc-id": "RFC2544", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": "The authors understand that it will take a considerable period of time \nto perform all of the recommended tests nder all of the recommended \nconditions. We believe that the results are worth the effort. Appendix \nA lists some of the tests and conditions that we believe should be \nincluded for specific cases.", "correct_text": "The authors understand that it will take a considerable period of time \nto perform all of the recommended tests under all of the recommended \nconditions. We believe that the results are worth the effort. Appendix \nA lists some of the tests and conditions that we believe should be \nincluded for specific cases.", "notes": "\n", "submit_date": "2004-09-08", "submitter_name": "Shiang-Ming Huang", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "425", "doc-id": "RFC2527", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the NOTES Section: ", "orig_text": " 1 The ABA Digital Signature Guidelines can be purchased from the ABA.\n See http://www.abanet.com for ordering details.", "correct_text": " 1 The ABA Digital Signature Guidelines can be purchased from the ABA.\n See http://www.abanet.org for ordering details.\n", "notes": "", "submit_date": "2002-08-05", "submitter_name": "Sid Sidner", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "426", "doc-id": "RFC2518", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "Errata for this document can be found at: http://www.webdav.org/wg/rfcdev/issues.htm\n", "submit_date": "2002-05-11", "submitter_name": "Julian Reschke", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "427", "doc-id": "RFC2516", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "9", "orig_text": "Host MAC address using a key known only to the Access > Concentrator.", "correct_text": "Host MAC address using a key known only to the Access Concentrator.", "notes": "There is an unnecessary \">\" symbol.", "submit_date": "2006-10-06", "submitter_name": "Saravanan Kesavan", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "413", "doc-id": "RFC2597", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1", "orig_text": "For example, if traffic conditioning actions at the ingress of the\r\nprovider DS domain make sure that an AF class in the DS nodes is only\r\nmoderately loaded by packets with the lowest drop precedence value\r\nand is not overloaded by packets with the two lowest drop precedence\r\nvalues, then the AF class can offer a high level of forwarding\r\nassurance for packets that are within the subscribed profile (i.e.,\r\nmarked with the lowest drop precedence value) and offer up to two\r\nlower levels of forwarding assurance for the excess traffic.", "correct_text": "For example, if traffic conditioning actions at the ingress of the\r\nprovider DS domain make sure that an AF class in the DS nodes is only\r\nmoderately loaded by packets with the lowest drop precedence value\r\nand is not overloaded by packets with the two higher drop precedence\r\nvalues, then the AF class can offer a high level of forwarding\r\nassurance for packets that are within the subscribed profile (i.e.,\r\nmarked with the lowest drop precedence value) and offer up to two\r\nlower levels of forwarding assurance for the excess traffic.\r\n", "notes": "", "submit_date": "2005-05-24", "submitter_name": "Bud", "verifier_id": "", "verifier_name": "Wes Eddy", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "414", "doc-id": "RFC2581", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.3", "orig_text": " The algorithms outlined in [Hoe96,FF96,MM96a,MM6b] follow the\n principles of the basic four congestion control algorithms outlined\n in this document.", "correct_text": " The algorithms outlined in [Hoe96,FF96,MM96a,MM96b] follow the\n principles of the basic four congestion control algorithms outlined\n in this document.", "notes": "\n", "submit_date": "2004-06-10", "submitter_name": "Noritoshi Demizu", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "415", "doc-id": "RFC2579", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.1.1", "orig_text": " \"The RowStatus textual convention is used to manage the\n creation and deletion of conceptual rows, and is used as the\n value of the SYNTAX clause for the status column of a\n conceptual row (as described in Section 7.7.1 of [2].)", "correct_text": " \"The RowStatus textual convention is used to manage the\n creation and deletion of conceptual rows, and is used as the\n value of the SYNTAX clause for the status column of a\n conceptual row (as described in Section 7.1.12 of [2].)\n", "notes": "", "submit_date": "2001-12-07", "submitter_name": "Juergen Schoenwaelder", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "416", "doc-id": "RFC2579", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "The DateAndTime textual convention did not originally define a special\nvalue which can be used in situations where a DateAndTime value is\nunknown or for some other reason not available. Several MIB modules on\nthe IETF standards-track use the value '0000", "orig_text": " 2 3 month 1..12\n 3 4 day 1..31", "correct_text": " 2 3 month 0 | 1..12\n 3 4 day 0 | 1..31\n", "notes": "\n", "submit_date": "2004-07-27", "submitter_name": "Juergen Schoenwaelder", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "417", "doc-id": "RFC2579", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": "RFC 2579 lists an invalid range for the year in the DateAndTime TC:\n\n field octets contents range\n ----- ------ -------- -----\n 1 1-2 year* 0..65536", "correct_text": " field octets contents range\n ----- ------ -------- -----\n 1 1-2 year* 0..65535\n", "notes": "", "submit_date": "2001-07-31", "submitter_name": "Juergen Schoenwaelder", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "418", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the reference: ", "orig_text": " [REL] Levinson, E., \"The MIME Multipart/Related Content-\n Type\", RFC 2389, August 1998.", "correct_text": "", "notes": "The RFC number cited is incorrect; it should be RFC 2387. ", "submit_date": "2001-01-07", "submitter_name": "Les Kramer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "419", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": "resolution of relative URIs). However, URI-s in Content-Location\r\nheaders (if absolute, or resolvable to absolute URIs) SHOULD still\r\nbe", "correct_text": "resolution of relative URIs). However, URIs in Content-Location\r\nheaders (if absolute, or resolvable to absolute URIs) SHOULD still be", "notes": "", "submit_date": "2002-01-21", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "420", "doc-id": "RFC2548", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.7.9", "orig_text": " Description\r\n\r\n The MS-Secondary-NBNS-Server Attribute is used to indicate the\r\n address of the secondary DNS server to be used by the PPP peer.\r\n It MAY be included in both Access-Accept and Accounting-Request\r\n packets.", "correct_text": " Description\r\n\r\n The MS-Secondary-NBNS-Server Attribute is used to indicate the\r\n address of the secondary NetBIOS Name Server (NBNS) [18] server to\r\n be used by the PPP peer. It MAY be included in both Access-Accept\r\n and Accounting-Request packets.\r\n\r\n", "notes": "", "submit_date": "2005-02-04", "submitter_name": "Hans-Ake Lund", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "421", "doc-id": "RFC2544", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6", "orig_text": " Since the tester both sends the test traffic and receives\n it back, after the traffic has been forwarded but the DUT, the tester\n can easily determine if all of the transmitted packets were received\n and verify that the correct packets were received.", "correct_text": " Since the tester both sends the test traffic and receives\n it back, after the traffic has been forwarded by the DUT, the tester\n can easily determine if all of the transmitted packets were received\n and verify that the correct packets were received.\n", "notes": "", "submit_date": "2002-08-07", "submitter_name": "Lu Jian Xiong", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "422", "doc-id": "RFC2544", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Section 26.1 says:", "orig_text": " Procedure: Send a specific number of frames at a specific rate\r\n through the DUT and then count the frames that are transmitted by the\r\n DUT. If the count of offered frames is equal to the count of received\r\n frames, the fewer frames are received than were transmitted, the rate\r\n of the offered stream is reduced and the test is rerun.", "correct_text": " Procedure:\r\n Send a specific number of frames at a specific rate through the\r\n DUT and then count the frames that are transmitted by the DUT. If\r\n the count of offered frames is equal to the count of received\r\n frames, the rate of the offered stream is raised and the test\r\n rerun. If fewer frames are received than were transmitted, the\r\n rate of the offered stream is reduced and the test is rerun.\r\n", "notes": "", "submit_date": "2006-11-05", "submitter_name": "Al Morton", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "423", "doc-id": "RFC2544", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Section C.2.2: ", "orig_text": " The network addresses 192.18.0.0 through 198.19.255.255 are have been\n assigned to the BMWG by the IANA for this purpose.", "correct_text": " The network addresses 198.18.0.0 through 198.19.255.255 have been\n assigned to the BMWG by the IANA for this purpose.\n", "notes": "", "submit_date": "2001-09-20", "submitter_name": "Scott Campbell", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "428", "doc-id": "RFC2486", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " x = %x00-7F\n ; all 127 ASCII characters, no exception", "correct_text": " special = \"<\" / \">\" / \"(\" / \")\" / \"[\" / \"]\" / \"\\\" / \".\"\n / \",\" / \";\" / \":\" / \"@\" / %x22 / Ctl\n ; %x22 is '\"'\n", "notes": "", "submit_date": "2000-08-31", "submitter_name": "Dale Worley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "433", "doc-id": "RFC2445", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Examples in various sections (2.4, 2.4.18, etc.)", "orig_text": " DESCRIPTION;ALTREP=\"http://www.wiz.org\":The Fall'98 Wild Wizards\r\n Conference - - Las Vegas, NV, USA\r\n[...]\r\n\r\n DESCRIPTION;ALTREP=\"CID:\":Project\r\n XYZ Review Meeting will include the following agenda items: (a)\r\n Market Overview, (b) Finances, (c) Project Management\r\n[...]\r\n ORGANIZER;SENT-BY:\"MAILTO:sray@host.com\":MAILTO:jsmith@host.com\r\n[...]\r\n LOCATION:Conference Room - F123, Bldg. 002\r\n\r\n LOCATION;ALTREP=\"http://xyzcorp.com/conf-rooms/f123.vcf\":\r\n Conference Room - F123, Bldg. 002\r\n[...]\r\n\r\n Atlanta, Georgia END:VEVENT END:VCALENDAR\r\n[...]\r\n CATEGORY:Project Report, XYZ, Weekly Meeting\r\n\r\n[...]\r\n Participants: John Smith, Jane Doe, Jim Dandy\\n-It was", "correct_text": " DESCRIPTION;ALTREP=\"http://www.wiz.org\":The Fall'98 Wild Wizards\r\n Conference - - Las Vegas\\, NV\\, USA\r\n[...]\r\n\r\n DESCRIPTION;ALTREP=\"CID:\":Project\r\n XYZ Review Meeting will include the following agenda items: (a)\r\n Market Overview\\, (b) Finances\\, (c) Project Management\r\n[...]\r\n ORGANIZER;SENT-BY=\"mailto:sray@host.com\":mailto:jsmith@host.com\r\n[...]\r\n LOCATION:Conference Room - F123\\, Bldg. 002\r\n\r\n LOCATION;ALTREP=\"http://xyzcorp.com/conf-rooms/f123.vcf\":\r\n Conference Room - F123\\, Bldg. 002\r\n[...]\r\n\r\n Atlanta\\, Georgia END:VEVENT END:VCALENDAR\r\n[...]\r\n CATEGORIES:Project Report,XYZ,Weekly Meeting\r\n\r\n[...]\r\n Participants: John Smith\\, Jane Doe\\, Jim Dandy\\n-It was", "notes": "This report comes from the following diff.\r\n\r\nThe following diff on RFC 2445 as archived also incorporates the\r\nchange to Section 4.2.18 reported by Tilghman Lesher on 2003-01-12.\r\n\r\n960c960\r\n< Conference - - Las Vegas, NV, USA\r\n- ---\r\n> Conference - - Las Vegas\\, NV\\, USA\r\n1027c1027\r\n< Market Overview, (b) Finances, (c) Project Management\r\n- ---\r\n> Market Overview\\, (b) Finances\\, (c) Project Management\r\n1664c1664\r\n< ORGANIZER;SENT-BY:\"mailto:sray@host.com\":mailto:jsmith@host.com\r\n- ---\r\n> ORGANIZER;SENT-BY=\"mailto:sray@host.com\":mailto:jsmith@host.com\r\n4699c4699\r\n< LOCATION:Conference Room - F123, Bldg. 002\r\n- ---\r\n> LOCATION:Conference Room - F123\\, Bldg. 002\r\n4702c4702\r\n< Conference Room - F123, Bldg. 002\r\n- ---\r\n> Conference Room - F123\\, Bldg. 002\r\n7626c7626\r\n< Atlanta, Georgia END:VEVENT END:VCALENDAR\r\n- ---\r\n> Atlanta\\, Georgia END:VEVENT END:VCALENDAR\r\n7760c7760\r\n< CATEGORY:Project Report, XYZ, Weekly Meeting\r\n- ---\r\n> CATEGORIES:Project Report,XYZ,Weekly Meeting\r\n7763c7763\r\n< Definition\r\n- ---\r\n> Definition\r\n7765c7765\r\n< Participants: John Smith, Jane Doe, Jim Dandy\\n-It was\r\n- ---\r\n> Participants: John Smith\\, Jane Doe\\, Jim Dandy\\n-It was\r\n", "submit_date": "2004-01-07", "submitter_name": "Dave Flater", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "434", "doc-id": "RFC2445", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2.7", "orig_text": " Example:\r\n\r\n ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC\r\n CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA\r\n qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw\r\n <...remainder of \"BASE64\" encoded binary data...>", "correct_text": " Example:\r\n\r\n ATTACH;FMTTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC\r\n ^\r\n CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA\r\n qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw\r\n <...remainder of \"BASE64\" encoded binary data...>", "notes": "Typo in FMTTYPE.\r\n", "submit_date": "2005-10-10", "submitter_name": "Ryan King", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "435", "doc-id": "RFC2445", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.18", "orig_text": " ORGANIZER;SENT-BY:\"MAILTO:sray@host.com\":MAILTO:jsmith@host.com", "correct_text": " ORGANIZER;SENT-BY=\"MAILTO:sray@host.com\":MAILTO:jsmith@host.com\n", "notes": "", "submit_date": "2003-01-11", "submitter_name": "Tilghman Lesher", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "436", "doc-id": "RFC2426", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nPage 33 says:", "orig_text": " ;For name=\"CATEGORIES\"\r\n param = text-param\r\n ; Only text parameters allowed\r\n\r\n value = text-list", "correct_text": " ;For name=\"CATEGORIES\"\r\n param = text-param\r\n ; Only text parameters allowed\r\n\r\n value = text-value-list\r\n", "notes": "", "submit_date": "2002-08-01", "submitter_name": "Vincent Ricard", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "437", "doc-id": "RFC2426", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4", "orig_text": " ;For name=\"NICKNAME\"\r\n param = text-param\r\n ; Text parameters allowed\r\n value = text-list", "correct_text": " ;For name=\"NICKNAME\"\r\n param = text-param\r\n ; Text parameters allowed\r\n value = text-value-list\r\n", "notes": "", "submit_date": "2002-08-01", "submitter_name": "Vincent Ricard", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "438", "doc-id": "RFC2426", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nSection 4 (p. 33) says:", "orig_text": " ;For name=\"CATEGORIES\"\r\n param = text-param\r\n ; Only text parameters allowed\r\n\r\n value = text-list", "correct_text": "", "notes": "It should say:\r\n ;For name=\"CATEGORIES\"\r\n param = text-param\r\n ; Only text parameters allowed\r\n\r\n value = text-value-list\r\n", "submit_date": "2002-08-01", "submitter_name": "Vincent Ricard", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "439", "doc-id": "RFC2426", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4", "orig_text": " ;For name=\"NICKNAME\"\r\n param = text-param\r\n ; Text parameters allowed\r\n value = text-list", "correct_text": " ;For name=\"NICKNAME\"\r\n param = text-param\r\n ; Text parameters allowed\r\n value = text-value-list\r\n", "notes": "", "submit_date": "2002-08-01", "submitter_name": "Vincent Ricard", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "450", "doc-id": "RFC2396", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.4", "orig_text": " The query component is a string of information to be interpreted by\r\n the resource.\r\n\r\n query = *uric\r\n\r\n Within a query component, the characters \";\", \"/\", \"?\", \":\", \"@\",\r\n \"&\", \"=\", \"+\", \",\", and \"$\" are reserved.", "correct_text": "", "notes": " Section 3.4, \"Query Component\", of RFC 2396 (URI syntax) refers to the \r\n \"/\" character as being reserved.\r\n\r\n Reserving this character creates an inconsistency for some of today's \r\n web servers, which confuse part of the Query Component as being part of \r\n the Path Component when the \"/\" character is present in the Query\r\n Component.\r\n\r\n The \"/\" character should only be permitted in the Path Component of a \r\n URI, and elsewhere in the URI it should be escaped by using it's hex\r\n value.\r\n", "submit_date": "2001-04-26", "submitter_name": "Carl Douglas", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "451", "doc-id": "RFC2396", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1.2", "orig_text": " A URN differs from a URL in that it's primary purpose is persistent\n labeling of a resource with an identifier.", "correct_text": " A URN differs from a URL in that its primary purpose is persistent\n labeling of a resource with an identifier.\n", "notes": "", "submit_date": "2002-09-18", "submitter_name": "Marc Warne", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "496", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6", "orig_text": " In particular, they MUST only be used where it is actually required\n for interoperation or to limit behavior which has potential for\n causing harm (e.g., limiting retransmisssions) For example, they\n must not be used to try to impose a particular method on\n implementors where the method is not required for interoperability. ", "correct_text": " In particular, they MUST only be used where it is actually required\n for interoperation or to limit behavior which has potential for\n causing harm (e.g., limiting retransmissions). For example, they\n must not be used to try to impose a particular method on\n implementors where the method is not required for interoperability.\n", "notes": "", "submit_date": "2001-01-31", "submitter_name": "Kurt Zeilenga", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "577", "doc-id": "RFC792", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "On p. 16 and 18, it says:", "orig_text": " IP Fields:\r\n\r\n Type", "correct_text": " ICMP Fields:\r\n\r\n Type", "notes": "On page 16, the section 'Timestamp and Timestamp Reply Messages' has\r\nthe header 'IP Fields:' - first mentioned after the graph and then\r\nagain after 'Addresses'. The second one should actually be 'ICMP\r\nFields:'. This error also occurs in the discussion of the\r\n'Information Request and Information Reply Message' on page 18. \r\n\r\nThe second 'IP Fields:' section of these two sets of message\r\ndescriptions are really talking about fields in the ICMP header not\r\nthe IP header.\r\n\r\n[This report was updated 2009-03-11 to specify the original and corrected text, as indicated by Nikolai Malykh.]", "submit_date": "2002-09-09", "submitter_name": "Beren Sanders", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "440", "doc-id": "RFC2421", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix B", "orig_text": " Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)\r\n MIME-Version: 1.0 (Voice 2.0)\r\n Content-type: Multipart/Voice-Message; Version=2.0;\r\n Boundary=\"MessageBoundary\"\r\n Content-Transfer-Encoding: 7bit\r\n Message-ID: ABCD-123456789@VM2.mycompany.com\r\n\r\n --MessageBoundary\r\n Content-type: Audio/32KADPCM\r\n Content-Transfer-Encoding: Base64\r\n Content-Disposition: inline; voice=Originator-Spoken-Name\r\n Content-Language: en-US\r\n Content-ID: part3@VM2-4321", "correct_text": " Date: Thu, 26 Aug 1993 10:20:20 -0700 (CDT)\r\n MIME-Version: 1.0 (Voice 2.0)\r\n Content-type: Multipart/Voice-Message; Version=2.0;\r\n Boundary=\"MessageBoundary\"\r\n Content-Transfer-Encoding: 7bit\r\n Message-ID: \r\n\r\n --MessageBoundary\r\n Content-type: Audio/32KADPCM\r\n Content-Transfer-Encoding: Base64\r\n Content-Disposition: inline; voice=Originator-Spoken-Name\r\n Content-Language: en-US\r\n Content-ID: ", "notes": "Date inconsistency. 4-digit year. Message-ID, Content-ID\r\nsyntax (missing <>) and semantics.", "submit_date": "2002-01-06", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "441", "doc-id": "RFC2421", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "\r\nAppendix B says:", "orig_text": " SOUND;TYPE=32KADPCM;ENCODING=URI: CID:\r\n REV:19951031T222710Z\r\n VERSION: 3.0\r\n END:VCARD\r\n\r\n --MessageBoundary_\r\n", "correct_text": " SOUND;TYPE=32KADPCM;ENCODING=URI: CID:\r\n REV:19951031T222710Z\r\n VERSION: 3.0\r\n END:VCARD\r\n\r\n --MessageBoundary--", "notes": " RFC 2046 multipart message close delimiter syntax.", "submit_date": "2002-01-07", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "442", "doc-id": "RFC2421", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix B", "orig_text": "Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)\r\n MIME-Version: 1.0 (Voice 2.0)\r\n Content-type: Multipart/Voice-Message; Version=2.0;\r\n Boundary=\"MessageBoundary\"\r\n Content-Transfer-Encoding: 7bit\r\n Message-ID: 123456789@VM2.mycompany.com\r\n Sensitivity: Private\r\n Importance: High\r\n\r\n --MessageBoundary\r\n Content-type: Audio/32KADPCM\r\n Content-Transfer-Encoding: Base64\r\n Content-Disposition: inline; voice=Originator-Spoken-Name\r\n Content-Language: en-US\r\n Content-ID: part1@VM2-4321", "correct_text": "Date: Thu, 26 Aug 1993 10:20:20 -0700 (CDT)\r\n MIME-Version: 1.0 (Voice 2.0)\r\n Content-type: Multipart/Voice-Message; Version=2.0;\r\n Boundary=\"MessageBoundary\"\r\n Content-Transfer-Encoding: 7bit\r\n Message-ID: <123456789@VM2.mycompany.com>\r\n Sensitivity: Private\r\n Importance: High\r\n\r\n --MessageBoundary\r\n Content-type: Audio/32KADPCM\r\n Content-Transfer-Encoding: Base64\r\n Content-Disposition: inline; voice=Originator-Spoken-Name\r\n Content-Language: en-US\r\n Content-ID: ", "notes": "Date inconsistency. 4-digit year number.\r\nMessage-ID syntax error (angle brackets required); likewise\r\nfor Content-ID. In addition, Content-ID requires a fully-qualified\r\ndomain name as it must be world-unique, like a Message-ID.\r\nRFC 1911 section 12 has a similar example with similar errors\r\nin the date and message-id fields.", "submit_date": "2002-01-06", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "443", "doc-id": "RFC2421", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2.4", "orig_text": "Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)", "correct_text": "Date: Sun, 28 Jul 1996 10:08:49 -0800 (PST)", "notes": "RFC 822, section 5.2 prohibits date inconsistency\r\nbetween day-of-week and date (see also RFC 2822, sect. 3.3).\r\nRFC 1123 section 5.2.14 strongly encourages use of 4-digit\r\nyear numbers; RFC 2822 mandates them. These errors also appear\r\nin RFC 1911 section 4.2.", "submit_date": "2002-01-06", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "444", "doc-id": "RFC2421", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix B", "orig_text": "| Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)\r\n Content-type: Multipart/Voice-Message; Version=2.0;\r\n Boundary=\"MessageBoundary2\"\r\n Content-Transfer-Encoding: 7bit\r\n MIME-Version: 1.0 (Voice 2.0)\r\n\r\n --MessageBoundary2\r\n Content-type: Audio/32KADPCM\r\n Content-Transfer-Encoding: Base64\r\n Content-Disposition: inline; voice=Originator-Spoken-Name\r\n Content-Language: en-US\r\n| Content-ID: part6@VM2-4321\r\n", "correct_text": "| Date: Thu, 26 Aug 1993 8:23:10 -0500 (EST)\r\n Content-type: Multipart/Voice-Message; Version=2.0;\r\n Boundary=\"MessageBoundary2\"\r\n Content-Transfer-Encoding: 7bit\r\n MIME-Version: 1.0 (Voice 2.0)\r\n\r\n --MessageBoundary2\r\n Content-type: Audio/32KADPCM\r\n Content-Transfer-Encoding: Base64\r\n Content-Disposition: inline; voice=Originator-Spoken-Name\r\n Content-Language: en-US\r\n| Content-ID: ", "notes": "Date inconsistency. 4-digit year. Content-ID syntax (missing <>) and\r\nsemantics (need to use fully qualified domain name).\r\n\r\n", "submit_date": "2002-01-06", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "445", "doc-id": "RFC2421", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "15", "orig_text": " Content-type: message/disposition-notification\r\n\r\n Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)\r\n\r\n Original-Recipient: rfc822;22722@vm.company.com", "correct_text": " Content-type: message/disposition-notification\r\n\r\n Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)\r\n Original-Recipient: rfc822;22722@vm.company.com", "notes": " RFC 2298 does not permit extra CRLFs between fields\r\nin a MDN. See the BNF in RFC 2298 section 3 (note that the CRLFs\r\nthere are the ones that terminate each header field).", "submit_date": "2002-01-31", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "446", "doc-id": "RFC2421", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Appendix B: ", "orig_text": " SOUND;TYPE=32KADPCM;ENCODING=URI: CID:\n REV:19951031T222710Z\n VERSION: 3.0\n END:VCARD\n\n --MessageBoundary_", "correct_text": " SOUND;TYPE=32KADPCM;ENCODING=URI: CID:\n REV:19951031T222710Z\n VERSION: 3.0\n END:VCARD\n\n --MessageBoundary--\n", "notes": "", "submit_date": "2002-01-07", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "447", "doc-id": "RFC2421", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "15", "orig_text": " Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)", "correct_text": " Date: Mon, 26 Aug 93 08:23:10 -0500 (EST)\n", "notes": "", "submit_date": "2003-10-04", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "448", "doc-id": "RFC2417", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " IMPORTS\n MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP\n FROM SNMPv2-CONF\n snmpModules, MODULE-IDENTITY, NOTIFICATION-TYPE, Counter32,\n Integer32, Unsigned32, OBJECT-TYPE, IpAddress\n FROM SNMPv2-SMI", "correct_text": " IMPORTS\n MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP\n FROM SNMPv2-CONF\n mib-2, MODULE-IDENTITY, NOTIFICATION-TYPE, Counter32,\n Integer32, Unsigned32, OBJECT-TYPE, IpAddress\n FROM SNMPv2-SMI\n", "notes": "", "submit_date": "2003-08-11", "submitter_name": "C. M. Heard", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "452", "doc-id": "RFC2396", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix C ", "orig_text": "C.1. Normal Examples\r\n ...\r\n ?y = http://a/b/c/?y\r\n ...\r\n", "correct_text": "", "notes": "Appendix C shows an example of a relative URI Reference of \"?y\" with \r\nrespect to the base URI \"http://a/b/c/d;p?q\". However, according to the \r\ncollected syntax that appears in Appendix A, \"?y\" doesn't appear to be a \r\nvalid relative URI reference. The syntactic category URI-reference must \r\nbegin with an absoluteURI, a relativeURI or a pound sign. An absoluteURI \r\nbegins with a scheme, which cannot begin with a question mark; a \r\nrelativeURI begins with a net_path or abs_path, both of which begin with a \r\nslash, or with a rel_path. A rel_path begins with a non-empty \r\nrel_segment, which again cannot begin with a question mark.\r\n\r\n\r\nAlexey: this was fixed in RFC 3986 (the example is correct).\r\n\r\n", "submit_date": "2001-11-12", "submitter_name": "Henry Zongaro", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "453", "doc-id": "RFC2395", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7", "orig_text": "-", "correct_text": " [Deutsch96] Deutsch, P., \"DEFLATE Compressed Data Format\r\n Specification version 1.3\", RFC 1951, May 1996.", "notes": "the above reference (cited in Section 5) should appear.", "submit_date": "2000-08-30", "submitter_name": "John Border", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "454", "doc-id": "RFC2392", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": " example, \"cid:foo4%25foo1@bar.net\" corresponds to\n\n Content-ID: ", "correct_text": " example, \"cid:foo4%25foo1@bar.net\" corresponds to\n\n Content-ID: \n", "notes": "", "submit_date": "2002-03-07", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "455", "doc-id": "RFC2373", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the reference: ", "orig_text": " [TRAN] Gilligan, R., and E. Nordmark, \"Transition Mechanisms for\n IPv6 Hosts and Routers\", RFC 1993, April 1996.", "correct_text": "", "notes": "the RFC number cited is incorrect; it should be RFC 1933. \n", "submit_date": "2000-10-31", "submitter_name": "Tim Hutchinson", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "456", "doc-id": "RFC2373", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": " It appears that the ABNF grammar for textual representations of IPv6 addresses as detailed in Appendix B of RFC 2373 is not correct in its treatment of IPv6 addresses with a trailing IPv4 address. Specifically, section 2.2.3 of the RFC states that:", "orig_text": " \"::13.1.83.3\" \r\n", "correct_text": " IPv6address = dcolon | hexpart\r\n\r\n IPv4address = 1*3DIGIT \".\" 1*3DIGIT \".\" 1*3DIGIT \".\" 1*3DIGIT\r\n IPv6prefix = hexpart \"/\" 1*2DIGIT\r\n\r\n dcolon = \"::\" | \"::\" hexseq [ \":\" IPv4address ] | \"::\" [ IPv4address ]\r\n hexpart = hexseq | hexseq \":\" IPv4address | hexseq dcolon\r\n hexseq = hex4 *( \":\" hex4)\r\n hex4 = 1*4HEXDIG", "notes": "According to the grammar in Appendix B, this is not a valid IPv6\r\naddress; there is no provision for a double colon followed by an IPv4\r\naddress. However, the grammar does allow for a double colon, followed by\r\na colon, followed by an IPv4 address. In other words, \":::13.1.83.3\" is a\r\nvalid address according to the grammar and \"::13.1.83.3\" is not.\r\n\r\nI blame the discrepancy on the grammar simply because I feel that the\r\nintent of the RFC was clearly to prefer two colons over three colons\r\nbefore a trailing IPv4 address. This seems to match the behavior of\r\nexisting applications.\n --VERIFIER NOTES-- \nThis RFC has been replaced by RFC 3513 ", "submit_date": "2001-07-26", "submitter_name": "Mark Meiss", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "457", "doc-id": "RFC2362", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Throughout the document: ", "orig_text": " [Figures are present only in the postscript version]", "correct_text": "", "notes": "There is no postscript version available. ", "submit_date": "2001-01-03", "submitter_name": "RFC Editor", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "471", "doc-id": "RFC2236", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.2", "orig_text": " Varying this setting allows IGMPv2 routers to tune the \"leave\r\n latency\" (the time between the moment the last host leaves a group\r\n and when the routing protocol is notified that there are no more\r\n members), as discussed in section 7.8. It also allows tuning of the\r\n burstiness of IGMP traffic on a subnet, as discussed in section 7.3", "correct_text": " Varying this setting allows IGMPv2 routers to tune the \"leave\r\n latency\" (the time between the moment the last host leaves a group\r\n and when the routing protocol is notified that there are no more\r\n members), as discussed in section 8.8. It also allows tuning of the\r\n burstiness of IGMP traffic on a subnet, as discussed in section 8.3", "notes": "Section 2.2 2nd para refers to section 7.8 and 7.3 neither of which\r\nexist. It should refer to 8.8 and 8.3.", "submit_date": "2006-11-28", "submitter_name": "Stephen Nadas (RL/TNT)", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "472", "doc-id": "RFC2234", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.9", "orig_text": "3.9 ; Comment\n\n A semi-colon starts a comment that continues to the end of line.\n This is a simple way of including useful notes in parallel with the\n specifications.\n\n comment = \";\" *(WSP / VCHAR) CRLF", "correct_text": " char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE\n ; quoted string of SP and VCHAR\n without DQUOTE\n\n prose-val = \"<\" *(%x20-3D / %x3F-7E) \">\"\n ; bracketed string of SP and VCHAR\n without angles\n ; prose description, to be used as\n last resort\n\n CHAR = %x01-7F\n ; any 7-bit US-ASCII character,\n excluding NUL", "notes": "Should be:\n char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE\n ; quoted string of SP and VCHAR\n ; without DQUOTE\n\n prose-val = \"<\" *(%x20-3D / %x3F-7E / c-wsp) \">\"\n ; bracketed, possibly multiline string\n ; of SP and VCHAR without angles\n ; prose description, to be used as\n ; last resort\n\n CHAR = %x01-7F\n ; any 7-bit US-ASCII character,\n ; excluding NUL\n\n", "submit_date": "2001-11-19", "submitter_name": "Tanaka Akira", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "473", "doc-id": "RFC2234", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "", "correct_text": "", "notes": "Note: The following list of known errors in RFC 2234 is for\n historical reference only. All known errors in RFC 2234 are\n believed to have been resolved in RFC 4234, which obsoletes RFC\n 2234.\n\n", "submit_date": "2006-12-13", "submitter_name": "RFC Editor", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4741", "doc-id": "RFC6120", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "1. The 'id' attribute is REQUIRED for IQ stanzas.\r\n\r\n\u2026\r\n\r\n3. An entity that receives a stanza of type \"get\" or \"set\" MUST\r\n reply with an IQ respones of type \"result\" or \"error\". The\r\n response MUST preserve the 'id' attribute of the request (or be\r\n empty if the generated stanza did not include an 'id' attribute).", "correct_text": "1. The 'id' attribute is REQUIRED for IQ stanzas.\r\n\r\n\u2026\r\n\r\n3. An entity that receives a stanza of type \"get\" or \"set\" MUST\r\n reply with an IQ respones of type \"result\" or \"error\". The\r\n response MUST preserve the 'id' attribute of the request, or\r\n send an appropriate error if the generated stanza did not\r\n include an 'id' attribute.", "notes": "If the received IQ had an empty ID then it was not valid per point 1 and clients and servers cannot key on the ID (eg. for key mapped lists of IQs pending receipt or dispatch of a reply). An appropriate error or other behavior should be defined if the 'id' is meant to be REQUIRED, otherwise, if point 3 is correct, then 'id' should not be REQUIRED.", "submit_date": "2016-07-13", "submitter_name": "Sam Whited", "verifier_id": "", "verifier_name": "Ben Campbell", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "458", "doc-id": "RFC2327", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6", "orig_text": " An example of a static payload type is u-law PCM coded single\r\n channel audio sampled at 8KHz. This is completely defined in the\r\n RTP Audio/Video profile as payload type 0, so the media field for\r\n such a stream sent to UDP port 49232 is:\r\n\r\n m=video 49232 RTP/AVP 0\r\n\r\n An example of a dynamic payload type is 16 bit linear encoded\r\n stereo audio sampled at 16KHz. If we wish to use dynamic RTP/AVP\r\n payload type 98 for such a stream, additional information is\r\n required to decode it:\r\n\r\n m=video 49232 RTP/AVP 98", "correct_text": " An example of a static payload type is u-law PCM coded single\r\n channel audio sampled at 8KHz. This is completely defined in the\r\n RTP Audio/Video profile as payload type 0, so the media field for\r\n such a stream sent to UDP port 49232 is:\r\n\r\n m=audio 49232 RTP/AVP 0\r\n\r\n An example of a dynamic payload type is 16 bit linear encoded\r\n stereo audio sampled at 16KHz. If we wish to use dynamic RTP/AVP\r\n payload type 98 for such a stream, additional information is\r\n required to decode it:\r\n\r\n m=audio 49232 RTP/AVP 98", "notes": "The examples refer to audio but show the media type as \"video\". I believe \r\nthe author intended to put \"m=audio\" but \"m=video\" was put in by mistake.", "submit_date": "2005-08-01", "submitter_name": "Richard Walters", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "459", "doc-id": "RFC2327", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the document, the following characters should be replaced with corrected text. ", "orig_text": " '|' should be '/'\n '\"\"\"' and '\"' should be 'DQUOTE'\n '0x01..0x09' should be '%x01-09'\n", "correct_text": "", "notes": "The date reported was not recorded. The estimate is during 2000.", "submit_date": "2000-12-31", "submitter_name": "Not recorded", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3504", "doc-id": "RFC4948", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "2.4", "orig_text": "As a result, not only is there no limit to what a host may do, but\r\nalso there is no trace after the event of what a host may have done.", "correct_text": "As a result, not only there is no limit to what a host may do, but \r\nalso there is no trace of what a host may have done.", "notes": "1. 'is' in the first part of the sentence is not at the correct place.\r\n\r\n2. 'after the event' is making the sentence improper.", "submit_date": "2013-03-01", "submitter_name": "Bharat Joshi", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "474", "doc-id": "RFC2234", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": " prose-val = \"<\" *(%x20-3D / %x3F-7E / c-wsp) \">\"\r\n ; bracketed, possibly multiline string\r\n ; of SP and VCHAR without angles\r\n ; prose description, to be used as\r\n ; last resort", "correct_text": " prose-val = \"<\" *(%x20-3D / %x3F-7E) \">\"\r\n ; bracketed string of SP and VCHAR\r\n ; without angles\r\n ; prose description, to be used as\r\n ; last resort\r\n", "notes": "Alexey: As per RFC 5234.\r\n", "submit_date": "2005-04-11", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "475", "doc-id": "RFC2234", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.7", "orig_text": " That is, exactly occurences of .", "correct_text": " That is, exactly occurences of .\n", "notes": "", "submit_date": "2002-12-13", "submitter_name": "El defeKto 2000", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "476", "doc-id": "RFC2231", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": " A single quote is used to separate the character set, language, and\n actual value information in the parameter value string, and an\n percent sign is used to flag octets encoded in hexadecimal.", "correct_text": " A single quote is used to separate the character set, language, and\n actual value information in the parameter value string, and a\n percent sign is used to flag octets encoded in hexadecimal.\n", "notes": "", "submit_date": "2003-02-09", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "477", "doc-id": "RFC2231", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": " extended-parameter := (extended-initial-name \"=\"\r\n extended-value) /\r\n (extended-other-names \"=\"\r\n extended-other-values)", "correct_text": " extended-parameter := (extended-initial-name \"=\"\r\n extended-initial-value) /\r\n (extended-other-names \"=\"\r\n extended-other-values)\r\n\r\n", "notes": "", "submit_date": "2001-04-17", "submitter_name": "Shuhei KOBAYASHI", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "478", "doc-id": "RFC2231", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": " encoded-word := \"=?\" charset [\"*\" language] \"?\" encoded-text \"?=\"", "correct_text": " encoded-word := \"=?\" charset [\"*\" language] \"?\" encoding \"?\"\n encoded-text \"?=\"\n", "notes": "", "submit_date": "2001-11-24", "submitter_name": "Jeffrey Stedfast", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "479", "doc-id": "RFC2213", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3", "orig_text": " TimeInterval, TEXTUAL-CONVENTION, RowStatus,\r\n TruthValue FROM SNMPv2-TC", "correct_text": " TimeInterval, TEXTUAL-CONVENTION, RowStatus,\r\n TruthValue, TestAndIncr FROM SNMPv2-TC\r\n", "notes": "", "submit_date": "2005-09-12", "submitter_name": "Orly Nicklass", "verifier_id": "", "verifier_name": "Wesley Eddy", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "480", "doc-id": "RFC2202", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the Appendix, it says:\n", "orig_text": " /**** Outter Digest ****/\n\n SHAInit(&octx) ;\n\n /* Pad the key for outter digest */", "correct_text": " /**** Outer Digest ****/\n\n SHAInit(&octx) ;\n\n /* Pad the key for outer digest */", "notes": "\n", "submit_date": "2004-05-05", "submitter_name": "Deron Meranda", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "539", "doc-id": "RFC1771", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.3", "orig_text": "Total Path Attribute Length:\n\n This 2-octet unsigned integer indicates the total length of\n\t the Path Attributes field in octets. Its value must allow\n\t the length of the Network Layer Reachability field to be\n\t determined as specified below. \n\n A value of 0 indicates that no Network Layer Reachability\n Information field is present in this UPDATE message.", "correct_text": " A value of 0 indicates that the Path Attributes field is\n\t not present in this UPDATE message.\n", "notes": "", "submit_date": "2003-10-01", "submitter_name": "Pete Young", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "540", "doc-id": "RFC1724", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9", "orig_text": " rip2IfConfAuthKey\n OCTET STRING (SIZE(0..16)),", "correct_text": " rip2IfConfAuthKey\n OCTET STRING,\n", "notes": "", "submit_date": "2004-05-27", "submitter_name": "Orly Nicklass", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "578", "doc-id": "RFC791", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.2", "orig_text": "Note that this is consistent with the the datagram total length field (of \r\ncourse, the header is counted in the total length and not in the \r\nfragments).", "correct_text": "Note that this is consistent with the datagram total length field (of \r\ncourse, the header is counted in the total length and not in the \r\nfragments).\r\n", "notes": "", "submit_date": "2006-02-18", "submitter_name": "Yin Shuming", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "461", "doc-id": "RFC2308", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7.2", "orig_text": "7.2 Dead / Unreachable Server (OPTIONAL)\r\n\r\n Dead / Unreachable servers are servers that fail to respond in any\r\n way to a query or where the transport layer has provided an\r\n indication that the server does not exist or is unreachable. A\r\n server may be deemed to be dead or unreachable if it has not\r\n responded to an outstanding query within 120 seconds.\r\n\r\n Examples of transport layer indications are:\r\n\r\n ICMP error messages indicating host, net or port unreachable.\r\n TCP resets\r\n IP stack error messages providing similar indications to those above.\r\n\r\n A server MAY cache a dead server indication. If it does so it MUST\r\n NOT be deemed dead for longer than five (5) minutes. The indication\r\n MUST be stored against query tuple unless there was a transport layer indication that the\r\n server does not exist, in which case it applies to all queries to\r\n that specific IP address.", "correct_text": "7.2 Dead / Unreachable Server (OPTIONAL)\r\n\r\n Dead / Unreachable servers are servers that fail to respond in any\r\n way to a query or where the transport layer has provided an\r\n indication that the server does not exist or is unreachable. A\r\n server may be deemed to be dead or unreachable if it has not\r\n responded to an outstanding query within 120 seconds.\r\n\r\n Examples of transport layer indications are:\r\n\r\n ICMP error messages indicating host, net or port unreachable.\r\n TCP resets\r\n IP stack error messages providing similar indications to those above.\r\n\r\n A resolver MAY cache a dead server indication. If it does so it MUST\r\n NOT be deemed dead for longer than five (5) minutes. The indication\r\n MUST be stored against query tuple unless there was a transport layer indication that the\r\n server does not exist, in which case it applies to all queries to\r\n that specific IP address.", "notes": "Last sentence says, \"A server MAY cache a dead server indication.\".\r\nBut, this \"server\" is typo, I think.\r\nThis \"server\" should be \"resolver\" because section 7.1's last sentence uses \"resolver\".", "submit_date": "2006-02-01", "submitter_name": "Hideshi Enokihara", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "462", "doc-id": "RFC2307", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4", "orig_text": " ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL\r\n DESC 'Abstraction of an IP protocol. Maps a protocol number\r\n to one or more names. The distinguished value of the cn\r\n attribute denotes the protocol's canonical name'\r\n MUST ( cn $ ipProtocolNumber $ description )\r\n MAY description )", "correct_text": " ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL\r\n DESC 'Abstraction of an IP protocol. Maps a protocol number\r\n to one or more names. The distinguished value of the cn\r\n attribute denotes the protocol's canonical name'\r\n MUST ( cn $ ipProtocolNumber )\r\n MAY description )\r\n", "notes": "", "submit_date": "2004-11-25", "submitter_name": "Pierre Beyssac", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "463", "doc-id": "RFC2286", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the Appendix: ", "orig_text": "/* The HMAC_SHA1 transform looks like:", "correct_text": "/* The HMAC_RMD160 transform looks like:\r\n\r\n ", "notes": "", "submit_date": "2002-09-17", "submitter_name": "Kevin Springle", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "464", "doc-id": "RFC2281", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "Section 2, \"Conditions of Use\" was mistakenly included in the\ndocument and is incorrect.\n\nCurrent information on ownership claims for protocols documented\nin RFCs is available from http://www.ietf.org/ietf/IPR.\n", "submit_date": "2003-05-22", "submitter_name": "Bob Braden", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "465", "doc-id": "RFC2268", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6", "orig_text": " RC2Version ::= INTEGER -- 1-1024\n\n RC2 in CBC mode has two parameters: an 8-byte initialization vector\n (IV) and a version number in the range 1-1024 which specifies in a\n roundabout manner the number of effective key bits to be used for\n the RC2 encryption/decryption.", "correct_text": " RC2Version ::= INTEGER -- 0-1024\n\n RC2 in CBC mode has two parameters: an 8-byte initialization vector\n (IV) and a version number in the range 0-1024 which specifies in a\n roundabout manner the number of effective key bits to be used for\n the RC2 encryption/decryption.\n", "notes": "", "submit_date": "2001-10-17", "submitter_name": "Simon Josefsson", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "466", "doc-id": "RFC2254", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": " greater = \">=\"", "correct_text": " greater than or equal = \">=\"\n", "notes": "", "submit_date": "2002-10-30", "submitter_name": "Charles Bates", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "467", "doc-id": "RFC2252", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.33", "orig_text": " ruleidentifiers = ruleidentifier |", "correct_text": " ruleidentifiers = ruleidentifier /", "notes": "\r\n", "submit_date": "2003-10-15", "submitter_name": "Mark Wahl", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "468", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": "return-metadata = nil / string / value-list / acl", "correct_text": "return-metadata = nil / string / number / value-list / acl\r\n ;; number is only used for \"size\" metadata items\r\n ;; acl is only used for \"acl\" metadata items\r\n", "notes": "Bug/clarification in formal syntax (where it doesn't match examples).\r\n \r\n\r\n", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "469", "doc-id": "RFC2421", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "15", "orig_text": " Content-type: message/disposition-notification\n\n Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)\n\n Original-Recipient: rfc822;22722@vm.company.com", "correct_text": " Content-type: message/disposition-notification\n\n Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)\n Original-Recipient: rfc822;22722@vm.company.com\n", "notes": "", "submit_date": "2002-01-31", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "470", "doc-id": "RFC2236", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1", "orig_text": " These two messages are differentiated by the Group Address, as\r\n described in section 1.4 . Membership Query messages are\r\n referred to simply as \"Query\" messages.\r\n", "correct_text": " These two messages are differentiated by the Group Address, as\r\n described in section 2.4 . Membership Query messages are\r\n referred to simply as \"Query\" messages.\r\n", "notes": " ", "submit_date": "2004-12-17", "submitter_name": "Jesse Norell", "verifier_id": "", "verifier_name": "Ross Callon", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "492", "doc-id": "RFC2126", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "All errata for these documents can be found at: http://purl.org/net/http-errata\r\n\r\n----------------------\r\nThis report was mistakenly posted based on a typo (2126 vs. 2616) \r\nin a message from 2002, and thus has been rejected. ", "submit_date": "2002-03-21", "submitter_name": "Larry Masinter", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "493", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "2. MUST NOT This phrase, or the phrase \"SHALL NOT\", mean that the\r\n definition is an absolute prohibition of the specification.", "correct_text": "2. MUST NOT This phrase, or the phrase \"SHALL NOT\", means that the\r\n definition is an absolute prohibition of the specification.\r\n", "notes": "", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "494", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6", "orig_text": "(e.g., limiting retransmisssions)", "correct_text": "(e.g., limiting retransmissions)", "notes": "", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "481", "doc-id": "RFC2202", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " test_case = 7\n key = 0xaa repeated 80 times\n key_len = 80\n data = \"Test Using Larger Than Block-Size Key and Larger\n Than One Block-Size Data\"\n data_len = 73\n digest = 0xe8e99d0f45237d786d6bbaa7965c7808bbff1a91\n data_len = 20\n digest = 0x4c1a03424b55e07fe7f27be1d58bb9324a9a5a04\n digest-96 = 0x4c1a03424b55e07fe7f27be1\n\n test_case = 6\n key = 0xaa repeated 80 times\n key_len = 80\n data = \"Test Using Larger Than Block-Size Key - Hash Key\n First\"\n data_len = 54\n digest = 0xaa4ae5e15272d00e95705637ce8a3b55ed402112\n \n test_case = 7\n key = 0xaa repeated 80 times\n key_len = 80\n data = \"Test Using Larger Than Block-Size Key and Larger\n Than One Block-Size Data\"\n data_len = 73\n digest = 0xe8e99d0f45237d786d6bbaa7965c7808bbff1a91", "correct_text": " test_case = 7\n key = 0xaa repeated 80 times\n key_len = 80\n data = \"Test Using Larger Than Block-Size Key and Larger\n Than One Block-Size Data\"\n data_len = 73\n digest = 0xe8e99d0f45237d786d6bbaa7965c7808bbff1a91\n", "notes": "", "submit_date": "2002-09-17", "submitter_name": "Kevin Springle", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "482", "doc-id": "RFC2196", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "On page 21, it says:", "orig_text": "A firewall is any one of several mechanisms used to control and watch\r\naccess to and from a network for the purpose of protecting it. A\r\nfirewall acts as a gateway through which all traffic to and from the\r\nprotected network and/or systems passes. Firewalls help to place\r\nlimitations on the amount and type of communication that takes place\r\nbetween the protected network and the another network (e.g., the\r\nInternet, or another piece of the site's network).", "correct_text": "A firewall is any one of several mechanisms used to control and watch\r\naccess to and from a network for the purpose of protecting it. A\r\nfirewall acts as a gateway through which all traffic to and from the\r\nprotected network and/or systems passes. Firewalls help to place\r\nlimitations on the amount and type of communication that takes place\r\nbetween the protected network and another network (e.g., the\r\nInternet, or another piece of the site's network).", "notes": "removed extraneous \"the\".", "submit_date": "2004-10-13", "submitter_name": "IETF Secretariat", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "483", "doc-id": "RFC2192", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "12", "orig_text": " imessagelist = enc_mailbox [ \"?\" enc_search ] [uidvalidity]", "correct_text": " imessagelist = enc_mailbox [uidvalidity] [ \"?\" enc_search ]", "notes": "Wrong order of fields", "submit_date": "2005-02-09", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "484", "doc-id": "RFC2184", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7", "orig_text": " This specification changes this ABNF to:\r\n\r\n encoded-word := \"=?\" charset [\"*\" language] \"?\" encoded-text \"?=\"", "correct_text": " This specification changes this ABNF to:\r\n\r\n encoded-word := \"=?\" charset [\"*\" language] \"?\" encoding \"?\"\r\n encoded-text \"?=\"\r\n", "notes": "", "submit_date": "2001-04-14", "submitter_name": "Terje Braten", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "485", "doc-id": "RFC2183", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": " NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)", "correct_text": " NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)\n", "notes": "", "submit_date": "2002-01-05", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "486", "doc-id": "RFC2132", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.6", "orig_text": " Code Len Type\n +-----+-----+-----+\n | 53 | 1 | 1-9 |\n +-----+-----+-----+", "correct_text": " Code Len Type\n +-----+-----+-----+\n | 53 | 1 | 1-8 |\n +-----+-----+-----+\n", "notes": "", "submit_date": "2001-12-12", "submitter_name": "George V. Neville-Neil", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "487", "doc-id": "RFC2132", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "3.18", "orig_text": "3.18. Swap Server\r\n\r\n This specifies the IP address of the client's swap server.\r\n\r\n The code for this option is 16 and its length is 4.\r\n\r\n Code Len Swap Server Address\r\n +-----+-----+-----+-----+-----+-----+\r\n | 16 | n | a1 | a2 | a3 | a4 |\r\n +-----+-----+-----+-----+-----+-----+", "correct_text": "3.18. Swap Server\r\n\r\n This specifies the IP address of the client's swap server.\r\n\r\n The code for this option is 16 and its length is 4.\r\n\r\n Code Len Swap Server Address\r\n +-----+-----+-----+-----+-----+-----+\r\n | 16 | 4 | a1 | a2 | a3 | a4 |\r\n +-----+-----+-----+-----+-----+-----+\r\n", "notes": "", "submit_date": "2002-09-24", "submitter_name": "\"Tyler Tidman\"", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "488", "doc-id": "RFC2131", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1.2", "orig_text": "In other related work, the path minimum transmission unit (MTU) discovery\r\nalgorithm can determine the MTU of an arbitrary internet path [14].", "correct_text": "In other related work, the path maximum transmission unit (MTU) discovery\r\nalgorithm can determine the MTU of an arbitrary internet path [14].\r\n", "notes": "", "submit_date": "2006-03-23", "submitter_name": "Robert Floyd Jr", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "489", "doc-id": "RFC2131", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1 number 5", "orig_text": " The client times out and retransmits the DHCPREQUEST message if the\r\n client receives neither a DHCPACK or a DHCPNAK message. \r\n ...\r\n If the client\r\n receives neither a DHCPACK or a DHCPNAK message after employing the\r\n retransmission algorithm, the client reverts to INIT state and\r\n restarts the initialization process. ", "correct_text": " The client times out and retransmits the DHCPREQUEST message if the\r\n client receives neither a DHCPACK nor a DHCPNAK message. \r\n ...\r\n If the client\r\n receives neither a DHCPACK nor a DHCPNAK message after employing the\r\n retransmission algorithm, the client reverts to INIT state and\r\n restarts the initialization process. ", "notes": "\r\n\r\n", "submit_date": "2004-04-29", "submitter_name": "Soohong Daniel Park", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "490", "doc-id": "RFC2131", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1", "orig_text": "Normally, DHCP servers and BOOTP relay agents attempt to deliver\r\nDHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using\r\nuicast delivery.", "correct_text": "Normally, DHCP servers and BOOTP relay agents attempt to deliver\r\nDHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using\r\nunicast delivery.", "notes": "typo (uicast -> unicast). Updated 2013-06-05. Thanks to Carlos Prendes for the correction.", "submit_date": "2004-01-13", "submitter_name": "Sreeni R. Nair", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "491", "doc-id": "RFC2127", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "All errata for these documents can be found at: http://purl.org/net/http-errata\r\n\r\n----------------------\r\nThis report was mistakenly posted based on a typo (2127 vs. 2617) \r\nin a message from 2002, and thus has been rejected. ", "submit_date": "2002-03-21", "submitter_name": "Larry Masinter", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4742", "doc-id": "RFC7530", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "section-6.2.", "orig_text": "https://tools.ietf.org/html/rfc7530#section-6.2.1\r\n\r\n The client can use the OPEN or ACCESS\r\n operations to check access without modifying or reading data or\r\n metadata.", "correct_text": " The client can use the OPEN or ACCESS\r\n operations to check access without modifying or reading data.", "notes": "Whenever client does OPEN/ACCESS call, there is an inadvertent change in the Last Access time of the file. Hence we think that the Metadata is modified due to OPEN/ACCESS call. Hence the Suggestion is to change the text as above.", "submit_date": "2016-07-15", "submitter_name": "Manju Karthik", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "497", "doc-id": "RFC2119", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "", "orig_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications must be understood and\r\n carefully weighed before choosing a different course.\r\n\r\n4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.", "correct_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications should be understood and\r\n carefully weighed before choosing a different course.\r\n\r\n4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.", "notes": "OR should say:\r\n 3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications is understood and\r\n carefully weighed before choosing a different course.\r\n\r\n4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.\r\n\r\n\r\nThe change request is \"must\" to \"should\".\r\nIt may be self definition.\r\nFor the balance of SHOULD and SHOULD NOT , it should use \"should\", not\r\n\"must\". \n --VERIFIER NOTES-- \nThe full implications MUST be understood in order to ignore a \"SHOULD\" or \"SHOULD NOT\" statement in a specification. ", "submit_date": "2006-07-10", "submitter_name": "Kiyoshi Ogawa", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "498", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.", "correct_text": "4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\", means that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.\r\n", "notes": "", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "499", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Abstract", "orig_text": " The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\r\n NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and\r\n \"OPTIONAL\" in this document are to be interpreted as described in\r\n RFC 2119.", "correct_text": " The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\r\n NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT \r\n RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to \r\n be interpreted as described in RFC 2119.", "notes": "The phrase \"NOT RECOMMENDED\" is missing from this sentence.", "submit_date": "2006-01-09", "submitter_name": "Anders Langmyr", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "500", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications must be understood and\r\n carefully weighed before choosing a different course.", "correct_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", means that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications must be understood and\r\n carefully weighed before choosing a different course.\r\n", "notes": "", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "501", "doc-id": "RFC2104", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9", "orig_text": " MD5Update(&context, k_ipad, 64) /* start with inner pad */\r\n", "correct_text": " MD5Update(&context, k_ipad, 64); /* start with inner pad */\r\n", "notes": " \r\n", "submit_date": "2005-06-23", "submitter_name": "Gregory Ogonowski", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "502", "doc-id": "RFC2092", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.3.", "orig_text": " Triggered RIP will NOT fuction properly (and should NOT be used) if a\n routing information will be retained/advertised for an arbitrarily\n long period of time (until an update in the opposite direction fails\n to obtain a response).", "correct_text": " Triggered RIP will NOT function properly (and should NOT be used) if a\n routing information will be retained/advertised for an arbitrarily\n long period of time (until an update in the opposite direction fails\n to obtain a response).\n", "notes": "", "submit_date": "2004-03-30", "submitter_name": "Kwan Jong Yoo", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "503", "doc-id": "RFC2060", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.4.8", "orig_text": " Example: C: A999 UID FETCH 4827313:4828442 FLAGS\n S: * 23 FETCH (FLAGS (\\Seen) UID 4827313)\n S: * 24 FETCH (FLAGS (\\Seen) UID 4827943)\n S: * 25 FETCH (FLAGS (\\Seen) UID 4828442)\n S: A999 UID FETCH completed", "correct_text": " Example: C: A999 UID FETCH 4827313:4828442 FLAGS\n S: * 23 FETCH (FLAGS (\\Seen) UID 4827313)\n S: * 24 FETCH (FLAGS (\\Seen) UID 4827943)\n S: * 25 FETCH (FLAGS (\\Seen) UID 4828442)\n S: A999 OK UID FETCH completed", "notes": "A list of known errata can be found at: ftp://ftp.cac.washington.edu/mail/rfc2060-errata ", "submit_date": "2002-05-28", "submitter_name": "Mathieu Fenniak", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "554", "doc-id": "RFC1319", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.1", "orig_text": " Padding is performed as follows: \"i\" bytes of value \"i\" are appended\n to the message so that the length in bytes of the padded message\n becomes congruent to 0, modulo 16. At least one byte and at most 16\n 16 bytes are appended.", "correct_text": " Padding is performed as follows: \"i\" bytes of value \"i\" are appended\n to the message so that the length in bytes of the padded message\n becomes congruent to 0, modulo 16. At least one byte and at most \n 16 bytes are appended.\n", "notes": "", "submit_date": "2002-01-30", "submitter_name": "Jem Berkes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "579", "doc-id": "RFC791", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "On page 21, it says:", "orig_text": "The intitial contents of the route data area must be zero.", "correct_text": "The initial contents of the route data area must be zero.", "notes": "", "submit_date": "2004-06-16", "submitter_name": "Pavel Uvarov", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "580", "doc-id": "RFC783", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2", "orig_text": "Any transsfer begins with a request to read or write a file, which also \r\nserves to request a connection.", "correct_text": "Any transfer begins with a request to read or write a file, which also \r\nserves to request a connection.", "notes": "from pending", "submit_date": "2006-02-18", "submitter_name": "\"Yin Shuming\"", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "504", "doc-id": "RFC2047", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": " (2) An 'encoded-word' may appear within a 'comment' delimited by \"(\" and\n \")\", i.e., wherever a 'ctext' is allowed. More precisely, the RFC\n 822 ABNF definition for 'comment' is amended as follows:\n\n comment = \"(\" *(ctext / quoted-pair / comment / encoded-word) \")\"\n\n A \"Q\"-encoded 'encoded-word' which appears in a 'comment' MUST NOT\n contain the characters \"(\", \")\" or \"\n 'encoded-word' that appears in a 'comment' MUST be separated from\n any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.", "correct_text": " (2) An 'encoded-word' may appear within a 'comment' delimited by \"(\" and\n \")\", i.e., wherever a 'ctext' is allowed. More precisely, the RFC\n 822 ABNF definition for 'comment' is amended as follows:\n\n comment = \"(\" *(ctext / quoted-pair / comment / encoded-word) \")\"\n\n A \"Q\"-encoded 'encoded-word' which appears in a 'comment' MUST NOT\n contain the characters \"(\", \")\" or \"\\\". In addition, an\n 'encoded-word' that appears in a 'comment' MUST be separated from\n any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.\n", "notes": "", "submit_date": "2001-11-10", "submitter_name": "Jose M. Cainzos", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "506", "doc-id": "RFC2047", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": " especials = \"(\" / \")\" / \"<\" / \">\" / \"@\" / \",\" / \";\" / \":\" / \"\r\n <\"> / \"/\" / \"[\" / \"]\" / \"?\" / \".\" / \"=\"", "correct_text": " especials = \"(\" / \")\" / \"<\" / \">\" / \"@\" / \",\" / \";\" / \":\" / \"\\\" /\r\n <\"> / \"/\" / \"[\" / \"]\" / \"?\" / \".\" / \"=\"\r\n", "notes": "Also reported by Jon Steinhart 2002-01-17, but corrected by Bruce Lilly. ", "submit_date": "2003-02-13", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "507", "doc-id": "RFC2046", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.1.5", "orig_text": " Date: Mon, 22 Mar 1994 13:34:51 +0000", "correct_text": " Date: Tue, 22 Mar 1994 13:34:51 +0000 ", "notes": "", "submit_date": "2003-10-04", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "508", "doc-id": "RFC2046", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix A states: ", "orig_text": " discard-text := *(*text CRLF)", "correct_text": " discard-text := *(*text CRLF) *text\n", "notes": "", "submit_date": "2001-10-04", "submitter_name": "Herman Meerlo", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "509", "doc-id": "RFC2046", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9", "orig_text": "9. Security Considerations", "correct_text": "8. Security Considerations", "notes": "In the Table of Contents, the Security Considerations is listed to be in Section 8. However, in the text, both the Security Considerations and Authors' Addresses are in Section 9; there is no Section 8.\r\n\r\n", "submit_date": "2004-02-03", "submitter_name": "Steve Bellovin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "510", "doc-id": "RFC2046", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.1.5", "orig_text": "undesireble \r\n\r\nseperate", "correct_text": "undesirable\r\n\r\nseparate", "notes": "Spelling errors.", "submit_date": "2001-12-22", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "511", "doc-id": "RFC2046", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": " (2) image -- image data. \"Image\" requires a display device\r\n (such as a graphical display, a graphics printer, or a\r\n FAX machine) to view the information. An initial\r\n subtype is defined for the widely-used image format\r\n JPEG. . subtypes are defined for two widely-used image\r\n formats, jpeg and gif.", "correct_text": " (2) image -- image data. \"Image\" requires a display device\r\n (such as a graphical display, a graphics printer, or a\r\n FAX machine) to view the information. Subtypes are defined\r\n for two widely-used image formats, jpeg and gif.\r\n", "notes": "The sentence previous to the last should be deleted, as it is covered by the last sentence.\r\n\r\n", "submit_date": "2005-01-06", "submitter_name": "Lars Kasper", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "512", "doc-id": "RFC2045", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.1", "orig_text": " tspecials := \"(\" / \")\" / \"<\" / \">\" / \"@\" /\r\n \",\" / \";\" / \":\" / \"\\\" / <\">\r\n \"/\" / \"[\" / \"]\" / \"?\" / \"=\"", "correct_text": " tspecials := \"(\" / \")\" / \"<\" / \">\" / \"@\" /\r\n \",\" / \";\" / \":\" / \"\\\" / <\"> /\r\n \"/\" / \"[\" / \"]\" / \"?\" / \"=\"", "notes": "Missing alternative separator on the second line.\r\n", "submit_date": "2005-02-24", "submitter_name": "Ned Freed", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "513", "doc-id": "RFC2040", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8", "orig_text": " This mode handles any length of plaintext and produces ciphertext \r\n whose length matches the plaintext length. ", "correct_text": " This mode handles any length of plaintext longer than one\r\n block and produces ciphertext whose length matches the\r\n plaintext length.", "notes": "", "submit_date": "2004-03-22", "submitter_name": "Bob Baldwin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "514", "doc-id": "RFC2040", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": " 1. Exclusive-or Pn-1 with the previous ciphertext\r\n block, Cn-2, to create Xn-1.", "correct_text": " 1. Exclusive-or Pn-1 with the previous ciphertext\r\n block, Cn-2, to create Xn-1. For short messages where\r\n Cn-2 does not exist, use IV.", "notes": "", "submit_date": "2004-03-26", "submitter_name": "Bob Baldwin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "515", "doc-id": "RFC2030", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": "T = ((T2 - T1) + (T3 - T4)) / 2.", "correct_text": "T = ((T2 - T1) + (T4 - T3)) / 2.", "notes": "Because T4 always will be greater than (or equal to) T3\r\n\r\nFor example assume\r\nT1 = 1\r\nT2 = 3\r\nT3 = 4\r\nT4 = 6\r\nCase 1: As per the given formula the local clock offset will be\r\n T = ((3 - 1) + (4 - 6)) / 2 = 0 which is wrong\r\nCase 2: As per the corrected formula the local clock offset will be\r\n T = ((3 - 1)+ (6 - 4)) / 2 = 2 which is correct", "submit_date": "2005-12-16", "submitter_name": "vijeeshep", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "516", "doc-id": "RFC2030", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "1", "orig_text": " Each SNTP packet is transmitted as tht TS-Userdata\r\n parameter of a T-UNITDATA Request primitive.", "correct_text": " Each SNTP packet is transmitted as the TS-Userdata\r\n parameter of a T-UNITDATA Request primitive.", "notes": "", "submit_date": "2002-11-12", "submitter_name": "Ben Fountain", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "517", "doc-id": "RFC2030", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": " d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.", "correct_text": " d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.\n", "notes": "", "submit_date": "2001-05-04", "submitter_name": "David L. Mills", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "518", "doc-id": "RFC2030", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " Note that when calculating the correspondence, 2000 is not a\n leap year. ", "correct_text": "", "notes": "Please disregard above statement regarding Leap Year, as the year 2000\nwas indeed a Leap Year.", "submit_date": "2001-03-16", "submitter_name": "Joe Hutcheson", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "581", "doc-id": "RFC31", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": " This size declaration should appear at the end of the\n message description; thus, forcing the reader to postpone an early\n consideration of bit details. xmodmap -e \"add lock = Caps_Lock\"", "correct_text": " This size declaration should appear at the end of the\n message description; thus, forcing the reader to postpone an early\n consideration of bit details. \n", "notes": "", "submit_date": "2000-09-25", "submitter_name": "Jim Ursetto", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "519", "doc-id": "RFC2030", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": " Field Name Unicast/Anycast Multicast\n Request Reply\n ----------------------------------------------------------\n LI 0 0-2 0-2\n VN 1-4 copied from 1-4\n request\n Mode 3 4 5\n Stratum 0 1-14 1-14\n Poll 0 ignore ignore", "correct_text": "\n Field Name Unicast/Anycast Multicast\n Request Reply\n ----------------------------------------------------------\n LI 0 0-2 0-2\n VN 1-4 copied from 1-4\n request\n Mode 3 4 5\n Stratum 0 1-15 1-15\n Poll 0 ignore ignore\n", "notes": "", "submit_date": "2003-07-18", "submitter_name": "Akinori Shoji", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "520", "doc-id": "RFC2030", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1", "orig_text": " An important provision in this document is the reinterpretation of\r\n certain NTP Versino 4 header fields which provide for IPv6 and OSI\r\n addressing and optional anycast extensions designed specifically for\r\n multicast service. \r\n", "correct_text": " An important provision in this document is the reinterpretation of\r\n certain NTP Version 4 header fields which provide for IPv6 and OSI\r\n addressing and optional anycast extensions designed specifically for\r\n multicast service.\r\n", "notes": "", "submit_date": "2002-11-12", "submitter_name": "Ben Fountain", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "521", "doc-id": "RFC2028", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.6", "orig_text": "The IAB appoints the IETF chair and is responsible for approving\r\nother IESG candidates put forward by the IETF nominating committee.", "correct_text": "Full IAB members, including the IETF chair, are selected and \r\nappointed according to the procedures defined in [E].", "notes": "The document references include:\r\n\r\n [E] Galvin, J (Ed.), \"IAB and IESG Selection, Confirmation, and\r\n Recall Process: Operation of the Nominating and Recall Committees\",\r\n RFC 2027, October 1996.\r\n\r\nOf course, this document has been revised since RFC 2028 was written.", "submit_date": "2006-03-21", "submitter_name": "Pete Resnick", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "522", "doc-id": "RFC2026", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "10.4", "orig_text": " \"The IETF takes no position regarding the validity or scope of\n any intellectual property or other rights that might be claimed\n to pertain to the implementation or use of the technology\n described in this document or the extent to which any license\n under such rights might or might not be available; neither does\n it represent that it has made any effort to identify any such\n rights. Information on the IETF's procedures with respect to\n rights in standards-track and standards-related documentation\n can be found in BCP-11...\"", "correct_text": "", "notes": "The reference to BCP-11 should be to BCP-9 (RFC 2026 itself).", "submit_date": "2002-08-01", "submitter_name": "Scott Bradner", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "523", "doc-id": "RFC2026", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.1", "orig_text": " This variance procedure is for use when a one-time waving of some\r\n provision of this document is felt to be required.", "correct_text": " This variance procedure is for use when a one-time waiving of some\r\n provision of this document is felt to be required.", "notes": "", "submit_date": "2003-10-07", "submitter_name": "Morris M. Keesan", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "524", "doc-id": "RFC2026", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.1", "orig_text": " Some RFCs standardize the results of community deliberations about\n statements of principle or conclusions about what is the best way to\n perform some operations or IETF process function. These RFCs form\n the specification has been adopted as a BCP, it is given the\n additional label \"BCPxxx\", but it keeps its RFC number and its place\n in the RFC series. (see section 5)", "correct_text": " Some RFCs standardize the results of community deliberations about\r\n statements of principle or conclusions about what is the best way to\r\n to perform some operations or IETF process function. These RFCs form\r\n the 'BCP' (Best Current Practice) subseries of the RFC series. When \r\n a specification has been adopted as a BCP, it is given the \r\n additional label \"BCPxxx\", but it keeps its RFC number and its place\r\n in the RFC series. (see section 5)", "notes": "The following words are missing:\r\n\r\n'BCP' (Best Current Practice) subseries of the RFC Series. When a", "submit_date": "2002-12-30", "submitter_name": "Bob Harvey", "verifier_id": "", "verifier_name": null, "update_date": "2023-01-27 20:52:36"}, {"errata_id": "555", "doc-id": "RFC1319", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.2", "orig_text": " ...\n /* Process each 16-word block. */\n For i = 0 to N/16-1 do\n\n /* Checksum block i. */\n For j = 0 to 15 do\n Set c to M[i*16+j].\n Set C[j] to S[c xor L].\n Set L to C[j].\n end /* of loop on j */\n end /* of loop on i */\n\n The 16-byte checksum C[0 ... 15] is appended to the message. Let\n M[0\n with checksum), where N' = N + 16.", "correct_text": " ...\n /* Process each 16-word block. */\n For i = 0 to N/16-1 do\n\n /* Checksum block i. */\n For j = 0 to 15 do\n Set c to M[i*16+j].\n Set C[j] to C[j] xor S[c xor L].\n Set L to C[j].\n end /* of loop on j */\n end /* of loop on i */\n\n The 16-byte checksum C[0 ... 15] is appended to the (padded)\n message.\n Let M[0..N'-1] be the message with padding and checksum appended,\n where N' = N + 16.\n", "notes": "", "submit_date": "2002-02-11", "submitter_name": "David Hopwood", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "556", "doc-id": "RFC1180", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "In Section 5.10, Table 12 - Delta's Route Table: \r\n\r\n[Based on Figure 9] Network \"factory\" should correspond to Delta Interface #2;\r\nNetwork \"accounting\" should correspond to Delta Interface #3.", "correct_text": "", "notes": "", "submit_date": "2000-02-28", "submitter_name": "Chao Yel", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "557", "doc-id": "RFC1158", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.4.2", "orig_text": " egp(5),\n ggp(6),\n hello(7),\n rip(8),\n is-is(9),\n es-is(10),\n ciscoIgrp(11),\n bbnSpfIgp(12),\n ospf(13)\n bgp(14)", "correct_text": " egp(5),\n ggp(6),\n hello(7),\n rip(8),\n is-is(9),\n es-is(10),\n ciscoIgrp(11),\n bbnSpfIgp(12),\n ospf(13),\n bgp(14)\n", "notes": "", "submit_date": "2002-03-27", "submitter_name": "Vincent Berger", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "558", "doc-id": "RFC1123", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.5", "orig_text": "Host names of up to 635 characters |2.1 |x| | | | | ", "correct_text": "Host names of up to 63 characters |2.1 |x| | | | | ", "notes": " Section 2.1 says \"Host software MUST handle host names of up to 63 characters\" and doesn't mention the number 635 at all. ", "submit_date": "2003-02-12", "submitter_name": "Ben Harris", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "559", "doc-id": "RFC1122", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "Section 1.1.3 incorrectly implies that all support protocols are \nat the Application layer. In particular, it mentions that support \nprotocol RARP (Reverse ARP), which is not an application-layer protocol.\n", "correct_text": "", "notes": "", "submit_date": "2002-10-19", "submitter_name": "Grzegorz R. Gryczka", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "525", "doc-id": "RFC2021", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "The DESCRIPTION of probeDownloadAction uses the wrong INTEGER definitions for downloadToPROM and downloadToRAM. \n\nOn page 92, it reads: ", "orig_text": " probeDownloadAction OBJECT-TYPE\n SYNTAX INTEGER {\n notDownloading(1),\n downloadToPROM(2),\n downloadToRAM(3)\n }\n MAX-ACCESS read-write\n STATUS current\n DESCRIPTION\n \"When this object is set to downloadToRAM(2) or\n downloadToPROM(3), the device will discontinue its\n normal operation and begin download of the image specified\n by probeDownloadFile from the server specified by\n probeDownloadTFTPServer using the TFTP protocol. If\n downloadToRAM(2) is specified, the new image is copied\n to RAM only (the old image remains unaltered in the flash\n EPROM). If downloadToPROM(3) is specified\n the new image is written to the flash EPROM\n memory after its checksum has been verified to be correct.\n When the download process is completed, the device will\n\twarm boot to restart the newly loaded application.\n When the device is not downloading, this object will have\n a value of notDownloading(1).\"\n ::= { probeConfig 8 }", "correct_text": "probeDownloadAction OBJECT-TYPE\n SYNTAX INTEGER {\n notDownloading(1),\n downloadToPROM(2),\n downloadToRAM(3)\n }\n MAX-ACCESS read-write\n STATUS current\n DESCRIPTION\n \"When this object is set to downloadToRAM(3) or\n downloadToPROM(2), the device will discontinue its\n normal operation and begin download of the image specified\n by probeDownloadFile from the server specified by\n probeDownloadTFTPServer using the TFTP protocol. If\n downloadToRAM(3) is specified, the new image is copied\n to RAM only (the old image remains unaltered in the flash\n EPROM). If downloadToPROM(2) is specified\n the new image is written to the flash EPROM\n memory after its checksum has been verified to be correct.\n When the download process is completed, the device will\n warm boot to restart the newly loaded application.\n When the device is not downloading, this object will have\n a value of notDownloading(1).\"\n ::= { probeConfig 8 }\n", "notes": "", "submit_date": "2002-06-25", "submitter_name": "Frank McKiernan", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "526", "doc-id": "RFC2015", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": "&railing whitespace that occurs on lines in order to ensure =20", "correct_text": "& trailing whitespace that occurs on lines in order to ensure =20", "notes": "", "submit_date": "2004-01-11", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "527", "doc-id": "RFC1979", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": " Length\n\n 3", "correct_text": " Length\n\n 4\n", "notes": "", "submit_date": "2003-11-03", "submitter_name": "Bartlomiej Molenda", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "528", "doc-id": "RFC1959", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": " ::= a string as defined in RFC 1485", "correct_text": " ::= a string as defined in RFC 1779\n", "notes": "", "submit_date": "2001-02-07", "submitter_name": "Kurt D. Zeilenga", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "529", "doc-id": "RFC1939", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": " The server should never reuse an\n unique-id in a given maildrop, for as long as the entity\n using the unique-id exists.", "correct_text": " The server should never reuse a\n unique-id in a given maildrop for as long as the maildrop\n exists.\n", "notes": "", "submit_date": "2003-11-02", "submitter_name": "Bernard Treine", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "530", "doc-id": "RFC1936", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4", "orig_text": " 4-bit carry-lookahead 2's complement adder:\n a,b : input data\n p : carry propagate, where pi = ai*bi = (ai)(bi)\n g : carry generate, where gi = ai + bi", "correct_text": " 4-bit carry-lookahead 2's complement adder:\n a,b : input data\n p : carry propagate, where pi = ai + bi\n g : carry generate, where gi = ai*bi = (ai)(bi)", "notes": "Note: This change affects only page 4; the PLD code is known correct.\n", "submit_date": "2005-05-11", "submitter_name": "Joe Touch", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "531", "doc-id": "RFC1927", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7", "orig_text": " 1) they should not be used on data flines which might end\n up in the hands of very small children", "correct_text": " 1) they should not be used on data files which might end up\n in the hands of very young children\n", "notes": "", "submit_date": "2003-10-07", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "532", "doc-id": "RFC1925", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": " the word is \"agglutinate\", not \"aglutenate\"\n", "correct_text": "", "notes": "", "submit_date": "2003-04-08", "submitter_name": "John Ioannidis", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "533", "doc-id": "RFC1915", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the Title: ", "orig_text": " Variance for\n The PPP Connection Control Protocol\n and\n The PPP Encryption Control Protocol", "correct_text": " Variance for\n The PPP Compression Control Protocol\n and\n The PPP Encryption Control Protocol\n", "notes": "", "submit_date": "2002-02-26", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "534", "doc-id": "RFC1894", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.4", "orig_text": " Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk\n id ;\n Sun, 10 Jul 1994 00:36:51 +0100\n To: owner-info-mime@cs.utk.edu\n Date: Sun, 10 Jul 1994 00:36:51 +0100\n Subject: WARNING: message delayed at \"nsfnet-relay.ac.uk\"\n content-type: multipart/report; report-type=delivery-status;\n boundary=foobar", "correct_text": " Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk\n id ;\n Sun, 10 Jul 1994 00:36:51 +0100\n To: owner-info-mime@cs.utk.edu\n Date: Sun, 10 Jul 1994 00:36:51 +0100\n Subject: WARNING: message delayed at \"nsfnet-relay.ac.uk\"\n MIME-Version: 1.0\n content-type: multipart/report; report-type=delivery-status;\n boundary=foobar\n", "notes": "", "submit_date": "2002-02-25", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "535", "doc-id": "RFC1891", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.2", "orig_text": " DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to\r\n be sent with a NULL return address (\"reverse-path\").", "correct_text": " DISCUSSION: RFC 1123, section 5.3.3 requires error notifications to\r\n be sent with a NULL return address (\"reverse-path\"). ", "notes": "RFC 1123, section 2.3.3., does not exist. The correct section is 5.3.3.", "submit_date": "2002-10-21", "submitter_name": "Florian Weimer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "536", "doc-id": "RFC1867", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Every occurance of the string:", "orig_text": " , boundary=", "correct_text": " ; boundary=\n", "notes": "", "submit_date": "2002-03-09", "submitter_name": "Dirk Nimmich", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "537", "doc-id": "RFC1812", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "11", "orig_text": " ROUTE:4.\r\n Lougheed, K., and Y. Rekhter, \"A Border Gateway Protocol 3\r\n (BGP-3)\", RFC 1267, cisco, T.J. Watson Research Center, IBM\r\n Corp., October 1991.", "correct_text": " ROUTE:4.\r\n Rekhter, Y. and T. Li, \"A Border Gateway Protocol 4 (BGP-4)\", \r\n RFC 1771, March 1995.\r\n", "notes": "", "submit_date": "2005-05-12", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "538", "doc-id": "RFC1812", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7.3.1", "orig_text": " Although it was not designed as an exterior gateway protocol, RIP\r\n (described in Section [7.2.4]) is sometimes used for inter-AS\r\n routing.", "correct_text": " Although it was not designed as an exterior gateway protocol, RIP\r\n (described in Appendix F.2) is sometimes used for inter-AS\r\n routing.", "notes": "", "submit_date": "2005-05-12", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4743", "doc-id": "RFC4130", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "A.3, A.4", "orig_text": "A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous\r\n Receipt\r\n\r\n Message-ID: <#as2_company#01#a4260as2_companyout#>\r\n Date: Thu, 19 Dec 2002 15:04:18 GMT\r\n From: me@example.com\r\n Subject: Async MDN request\r\n Mime-Version: 1.0\r\n Content-Type: application/pkcs7-mime;\r\n smime-type=enveloped-data; name=smime.p7m\r\n Content-Transfer-Encoding: binary\r\n Content-Disposition: attachment; filename=smime.p7m\r\n Recipient-Address: 10.240.1.2//\r\n Disposition-Notification-To:\r\n http://10.240.1.2:8201/exchange/as2_company\r\n Disposition-Notification-Options: signed-receipt-protocol=optional,\r\n pkcs7-signature; signed-receipt-micalg=optional,sha1\r\n Receipt-Delivery-Option:\r\n http://10.240.1.2:8201/exchange/as2_company\r\n AS2-From: as2_company\r\n AS2-To: \"AS2 Test\"\r\n AS2-Version: 1.1\r\n Host: 10.240.1.2:8101\r\n Connection: close\r\n Content-Length: 3428\r\n\r\n [omitted binary encrypted data]\r\n\r\n\r\n\r\nMoberg & Drummond Standards Track [Page 44]\r\n\f\r\nRFC 4130 AS2 for Business Data Interchange Using HTTP July 2005\r\n\r\n\r\nA.4. Asynchronous MDN for Message A.3, Above\r\n\r\n POST / HTTP/1.1\r\n Host: 10.240.1.2:8201\r\n Connection: close, TE\r\n TE: trailers, deflate, gzip, compress\r\n User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)\r\n Date: Thu, 19 Dec 2002 15:03:38 GMT\r\n Message-ID: \r\n AS2-Version: 1.1\r\n Mime-Version: 1.0\r\n Recipient-Address:\r\n http://10.240.1.2:8201/exchange/as2_company\r\n AS2-To: as2_company\r\n AS2-From: \"AS2 Test\"\r\n Subject: Your Requested MDN Response\r\n From: as2debug@example.com\r\n Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress\r\n Content-Type: multipart/signed; micalg=sha1;\r\n protocol=\"application/pkcs7-signature\";\r\n boundary=\"----=_Part_337_6452266.1040310218750\"\r\n Content-Length: 3103\r\n\r\n ------=_Part_337_6452266.1040310218750\r\n Content-Type: multipart/report;\r\n report-type=disposition-notification;\r\n boundary=\"----=_Part_336_6069110.1040310218718\"\r\n\r\n ------=_Part_336_6069110.1040310218718\r\n Content-Type: text/plain; charset=us-ascii\r\n Content-Transfer-Encoding: 7bit\r\n\r\n The message sent to Recipient on Thu, 19 Dec\r\n 2002 15:04:18 GMT with Subject has been received.\r\n The EDI Interchange was successfully decrypted, and its integrity was\r\n verified. In addition, the sender of the message, Sender\r\n at Location http://10.240.1.2:8201/exchange/as2_company\r\n was authenticated as the originator of the message. There is no\r\n guarantee, however, that the EDI interchange was syntactically\r\n correct, or that it was received by the EDI application/translator.\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\nMoberg & Drummond Standards Track [Page 45]\r\n\f\r\nRFC 4130 AS2 for Business Data Interchange Using HTTP July 2005\r\n\r\n\r\n ------=_Part_336_6069110.1040310218718\r\n Content-Type: message/disposition-notification\r\n Content-Transfer-Encoding: 7bit\r\n\r\n Reporting-UA: AS2@test:8101\r\n Original-Recipient: rfc822; \"AS2 Test\"\r\n Final-Recipient: rfc822; \"AS2 Test\"\r\n Original-Message-ID: <#as2_company#01#a4260as2_companyout#>\r\n Disposition: automatic-action/MDN-sent-automatically;\r\n processed\r\n Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1\r\n\r\n ------=_Part_336_6069110.1040310218718--\r\n\r\n ------=_Part_337_6452266.1040310218750\r\n Content-Type: application/pkcs7-signature; name=smime.p7s\r\n Content-Transfer-Encoding: base64\r\n Content-Disposition: attachment; filename=smime.p7s\r\n\r\n BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM\r\n 4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j\r\n UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=\r\n\r\n ------=_Part_337_6452266.1040310218750-", "correct_text": "A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous\r\n Receipt\r\n\r\n Message-ID: <#as2_company#01#a4260as2_companyout#>\r\n Date: Thu, 19 Dec 2002 15:04:18 GMT\r\n From: me@example.com\r\n Subject: Async MDN request\r\n Mime-Version: 1.0\r\n Content-Type: application/pkcs7-mime;\r\n smime-type=enveloped-data; name=smime.p7m\r\n Content-Transfer-Encoding: binary\r\n Content-Disposition: attachment; filename=smime.p7m\r\n Recipient-Address: 10.240.1.2//\r\n Disposition-Notification-To:\r\n http://10.240.1.2:58201/exchange/as2_company\r\n Disposition-Notification-Options: signed-receipt-protocol=optional,\r\n pkcs7-signature; signed-receipt-micalg=optional,sha1\r\n Receipt-Delivery-Option:\r\n http://10.240.1.2:58201/exchange/as2_company\r\n AS2-From: as2_company\r\n AS2-To: \"AS2 Test\"\r\n AS2-Version: 1.1\r\n Host: 10.240.1.2:58101\r\n Connection: close\r\n Content-Length: 3428\r\n\r\n [omitted binary encrypted data]\r\n\r\n\r\n\r\nMoberg & Drummond Standards Track [Page 44]\r\n\f\r\nRFC 4130 AS2 for Business Data Interchange Using HTTP July 2005\r\n\r\n\r\nA.4. Asynchronous MDN for Message A.3, Above\r\n\r\n POST / HTTP/1.1\r\n Host: 10.240.1.2:58201\r\n Connection: close, TE\r\n TE: trailers, deflate, gzip, compress\r\n User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)\r\n Date: Thu, 19 Dec 2002 15:03:38 GMT\r\n Message-ID: \r\n AS2-Version: 1.1\r\n Mime-Version: 1.0\r\n Recipient-Address:\r\n http://10.240.1.2:58201/exchange/as2_company\r\n AS2-To: as2_company\r\n AS2-From: \"AS2 Test\"\r\n Subject: Your Requested MDN Response\r\n From: as2debug@example.com\r\n Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress\r\n Content-Type: multipart/signed; micalg=sha1;\r\n protocol=\"application/pkcs7-signature\";\r\n boundary=\"----=_Part_337_6452266.1040310218750\"\r\n Content-Length: 3103\r\n\r\n ------=_Part_337_6452266.1040310218750\r\n Content-Type: multipart/report;\r\n report-type=disposition-notification;\r\n boundary=\"----=_Part_336_6069110.1040310218718\"\r\n\r\n ------=_Part_336_6069110.1040310218718\r\n Content-Type: text/plain; charset=us-ascii\r\n Content-Transfer-Encoding: 7bit\r\n\r\n The message sent to Recipient on Thu, 19 Dec\r\n 2002 15:04:18 GMT with Subject has been received.\r\n The EDI Interchange was successfully decrypted, and its integrity was\r\n verified. In addition, the sender of the message, Sender\r\n at Location \r\n http://10.240.1.2:58201/exchange/as2_company\r\n was authenticated as the originator of the message. There is no\r\n guarantee, however, that the EDI interchange was syntactically\r\n correct, or that it was received by the EDI application/translator.\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\nMoberg & Drummond Standards Track [Page 45]\r\n\f\r\nRFC 4130 AS2 for Business Data Interchange Using HTTP July 2005\r\n\r\n\r\n ------=_Part_336_6069110.1040310218718\r\n Content-Type: message/disposition-notification\r\n Content-Transfer-Encoding: 7bit\r\n\r\n Reporting-UA: AS2@test:58101\r\n Original-Recipient: rfc822; \"AS2 Test\"\r\n Final-Recipient: rfc822; \"AS2 Test\"\r\n Original-Message-ID: <#as2_company#01#a4260as2_companyout#>\r\n Disposition: automatic-action/MDN-sent-automatically;\r\n processed\r\n Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1\r\n\r\n ------=_Part_336_6069110.1040310218718--\r\n\r\n ------=_Part_337_6452266.1040310218750\r\n Content-Type: application/pkcs7-signature; name=smime.p7s\r\n Content-Transfer-Encoding: base64\r\n Content-Disposition: attachment; filename=smime.p7s\r\n\r\n BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM\r\n 4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j\r\n UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=\r\n\r\n ------=_Part_337_6452266.1040310218750-", "notes": "Port numbers used in examples need to either refer to the intended service (e.g., 80 for HTTP) or use dynamic ports (49152-65535). The examples provided used examples in the assigned User ports range (8101, 8201) both as source and destination, and neither is appropriate for the example service described.\r\n\r\nThe simplest change was to add a \"5\" in front of the numbers, placing them in the dynamic range (e.g., 58101, 58201).", "submit_date": "2016-07-15", "submitter_name": "Joe Touch", "verifier_id": "", "verifier_name": "Orie Steele", "update_date": "2024-03-29 21:15:39"}, {"errata_id": "541", "doc-id": "RFC1712", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "3", "orig_text": "the definitions for Latitude and Longitude are swapped.\r\n\r\nI believe this can be considered a typo as the actual values in the\r\nresource record can (and should) be kept in their current order.=20\r\n\r\nThe correct descriptions are (in general terms):=20\r\n Latitude is the degrees North or South of the Equator and can be\r\nreferenced with a range of -90 to +90.=20\r\n Longitude is the degrees East or West of the prime meridian and can\r\nbe referenced with a range of -180 to +180.\r\n\r\nBelow is my attempt to write the errata. If someone wants to make\r\nsuggestion about how the errata should be written, please tell me and I\r\nwill make a go at doing it as requested.\r\n\r\n Art Coleman acoleman@verisign.com\r\n\r\n\r\nIn RFC 1712 the terms Latitude and Longitude are swapped in that each\r\nwas given the other's definition. =20\r\nAlso the preferred order of the terms is Latitude then Longitude. In\r\naddition to matching the terms with their correct definitions, this\r\nordering is also addressed.\r\n\r\nIn Section 3, page 3 is a table, it says:\r\n\r\n MSB LSB=20\r\n +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20\r\n / LONGITUDE /=20\r\n +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20\r\n / LATITUDE /=20\r\n +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20\r\n / ALTITUDE /=20\r\n +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r\n\r\nIt should say:\r\n\r\n MSB LSB=20\r\n +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20\r\n / LATITUDE /=20\r\n +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20\r\n / LONGITUDE /=20\r\n +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20\r\n / ALTITUDE /=20\r\n +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r\n\r\nRational: It is only the terms that are being corrected, the value\r\nranges associated with the first (-90..90) and second (-180..180)\r\narguments are in the preferred order.\r\n\r\n\r\nIn Section 3, page 3 under 'where:', it says:\r\n\r\n LONGITUDE The real number describing the longitude encoded as a=20\r\n printable string. The precision is limited by 256 charcters\r\n\r\n within the range -90..90 degrees. Positive numbers=20\r\n indicate locations north of the equator.\r\n\r\n LATITUDE The real number describing the latitude encoded as a=20\r\n printable string. The precision is limited by 256 charcters=20\r\n within the range -180..180 degrees. Positive numbers=20\r\n indicate locations east of the prime meridian.\r\n\r\nIs should say:\r\n\r\n LATITUDE The real number describing the latitude encoded as a=20\r\n printable string. The precision is limited by 256 characters\r\n\r\n within the range -90..90 degrees. Positive numbers=20\r\n indicate locations north of the equator.\r\n\r\n LONGITUDE The real number describing the longitude encoded as a=20\r\n printable string. The precision is limited by 256\r\ncharacters=20\r\n within the range -180..180 degrees. Positive numbers=20\r\n indicate locations east of the prime meridian.\r\n\r\nRational: to match the terms with their correct definitions, and fix the\r\nspelling of the word 'characters'.\r\n\r\n\r\nIn Section 4, page 3, it says:\r\n\r\n GPOS has the following format:=20\r\n GPOS \r\n\r\nIt should say:\r\n\r\n GPOS has the following format:=20\r\n GPOS \r\n\r\nRational: It is only the terms that are being corrected, the value\r\nranges associated with the first (-90..90) and second (-180..180)\r\narguments are in the preferred order.\r\n\r\n\r\nIn Section 4, page 4, it says:\r\n\r\n The owner, ttl, and class fields are optional and default to the last\r\n\r\n defined value if omitted. The longitude is a floating point number=20\r\n ranging from -90 to 90 with positive values indicating locations=20\r\n north of the equator. For example Perth, Western Australia is=20\r\n located at 32^ 7` 19\" south of the equator which would be specified=20\r\n as -32.68820. The latitude is a number ranging from -180.0 to 180.0.\r\n\r\n For example Perth, Western Australia is located at 116^ 2' 25\" east=20\r\n of the prime meridian which would be specified as 116.86520. Curtin=20\r\n University, Perth is also 10 meters above sea-level.\r\n\r\nIt should say:\r\n\r\n The owner, ttl, and class fields are optional and default to the last\r\n\r\n defined value if omitted. The latitude is a floating point number=20\r\n ranging from -90 to 90 with positive values indicating locations=20\r\n north of the equator. For example Perth, Western Australia is=20\r\n located at 32^ 7` 19\" south of the equator which would be specified=20\r\n as -32.68820. The longitude is a number ranging from -180.0 to\r\n180.0.=20\r\n For example Perth, Western Australia is located at 116^ 2' 25\" east=20\r\n of the prime meridian which would be specified as 116.86520. Curtin=20\r\n University, Perth is also 10 meters above sea-level.\r\n\r\nRational: to match the terms with their correct definitions.", "correct_text": "", "notes": "from pending", "submit_date": "2006-03-09", "submitter_name": "\"Coleman, Arthur\"", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "542", "doc-id": "RFC1662", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the References Section:", "orig_text": " [1] Simpson, W., Editor, \"The Point-to-Point Protocol (PPP)\", \n STD 50, RFC 1661, Daydreamer, July 1994.", "correct_text": " [1] Simpson, W., Editor, \"The Point-to-Point Protocol (PPP)\", \n STD 51, RFC 1661, Daydreamer, July 1994.\n", "notes": "", "submit_date": "2002-03-07", "submitter_name": "Charles Cranford", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "560", "doc-id": "RFC1071", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " while( count > 1 ) {\n /* This is the inner loop */\n sum += * (unsigned short) addr++;\n count -= 2;", "correct_text": " while( count > 1 ) {\n /* This is the inner loop */\n sum += * (unsigned short *) addr++;\n count -= 2;", "notes": "", "submit_date": "2004-04-05", "submitter_name": "Tim Moors", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "561", "doc-id": "RFC1036", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.1.4", "orig_text": " If the message is submitted in response to another message (e.g.,\n is a follow-up) the default subject should begin with the four\n characters \"Re:\", and the \"References\" line is required.", "correct_text": " If the message is submitted in response to another message (e.g.,\n is a follow-up) the default subject should begin with the four\n characters \"Re: \", and the \"References\" line is required.\n", "notes": "", "submit_date": "2001-05-17", "submitter_name": "Florian Weimer", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "567", "doc-id": "RFC1002", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.2.16", "orig_text": "WAIT FOR ACKNOWLEDGEMENT (WACK) RESPONSE\r\n\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | NULL (0x0020) | IN (0x0001) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "correct_text": "The values for the first field (the resource record type) are defined above\r\nin section 4.2.1.3. RESOURCE RECORD:\r\n\r\n NULL 0x000A NULL Resource Record (See WAIT FOR\r\n ACKNOWLEDGEMENT RESPONSE)\r\n NB 0x0020 NetBIOS general Name Service Resource Record\r\n (See NB_FLAGS and NB_ADDRESS, below)", "notes": "\r\nThe value for type NULL is defined as 0x000A and the\r\ncomment specifically mentions WACK responses. The value shown in the packet\r\nlayout is 0x0020, the value for NB resource records, the most common value\r\nfor this field. In truth, I can't get Windows boxes to respond to this\r\npacket as documented with either value in that field.\r\n", "submit_date": "2001-04-26", "submitter_name": "Sir Dystic", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "568", "doc-id": "RFC959", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.1", "orig_text": " The use of a \"Set Data Type\" transaction was proposed in RFC 294 in\n January 1982. ", "correct_text": " The use of a \"Set Data Type\" transaction was proposed in RFC 294 in\n January 1972.\n", "notes": "", "submit_date": "2001-01-03", "submitter_name": "Juan Li", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "569", "doc-id": "RFC951", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4", "orig_text": "How can the server send an IP datagram to the client, if the client doesnt \r\nknow its own IP address (yet)?", "correct_text": "How can the server send an IP datagram to the client, if the client doesn't \r\nknow its own IP address (yet)?\r\n", "notes": "", "submit_date": "2006-02-18", "submitter_name": "\"Yin Shuming\"", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "570", "doc-id": "RFC894", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Section Frame Format: ", "orig_text": " The minimum length of the data field of a packet sent over an\n Ethernet is 1500 octets, thus the maximum length of an IP datagram\n sent over an Ethernet is 1500 octets.", "correct_text": " The maximum length of the data field of a packet sent over an\n Ethernet is 1500 octets, thus the maximum length of an IP datagram\n sent over an Ethernet is 1500 octets.\n", "notes": "", "submit_date": "2001-03-28", "submitter_name": "Gerald Park", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "571", "doc-id": "RFC854", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3", "orig_text": "Neither can unilaterally seize control from the other; rather the \r\ncontrolling end must relinguish its control explicitly.\r\n ^^^^^^^^^^", "correct_text": "Neither can unilaterally seize control from the other; rather the \r\ncontrolling end must relinquish its control explicitly.\r\n ^^^^^^^^^^", "notes": "", "submit_date": "2006-08-18", "submitter_name": "SungWoon Lee", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "572", "doc-id": "RFC793", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.1", "orig_text": "The format of data blocks exchanged within the a network will generally not \r\nbe of concern to us.", "correct_text": "The format of data blocks exchanged within the network will generally not \r\nbe of concern to us.", "notes": "from pending", "submit_date": "2006-02-18", "submitter_name": "\"Yin Shuming\"", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "582", "doc-id": "RFC5", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "In the Forward, it says:", "orig_text": "It was generally agreed beforehand that the runmning of interactive\r\nprograms across the network was the first problem that would be\r\nfaced.", "correct_text": "It was generally agreed beforehand that the running of interactive\r\nprograms across the network was the first problem that would be\r\nfaced.\r\n", "notes": "", "submit_date": "2005-05-23", "submitter_name": "Zhang Xin Liang", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "543", "doc-id": "RFC1661", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.4", "orig_text": "On reception of a Configure-Reject, the Identifier field MUST\r\nmatch that of the last transmitted Configure-Request.\r\nAdditionally, the Configuration Options in a Configure-Reject MUST\r\nbe a proper subset of those in the last transmitted Configure-\r\nRequest. Invalid packets are silently discarded.", "correct_text": "On reception of a Configure-Reject, the Identifier field MUST\r\nmatch that of the last transmitted Configure-Request.\r\nAdditionally, the Configuration Options in a Configure-Reject MUST\r\nbe a subset of those in the last transmitted Configure-\r\nRequest. Invalid packets are silently discarded.", "notes": "The word \"proper\" should be deleted. (I discussed this a while ago with \r\nthe author, Bill Simpson, and he agreed.)\r\n\r\nIf A is a subset of B, then set A contains only elements that are also in \r\nset B, up to and including all the elements of B (in which case A == B).\r\n\r\nIf A is a PROPER subset of B, then A contains only elements that are in \r\nB, up to BUT NOT including all the elements of B.\r\n\r\nIn this case, the word \"proper\" is just a mistake, perhaps added because \r\nsomeone thought it made the sentence sound better, without realizing that \r\nthe mathematical term \"proper subset\" has a specific precise meaning, \r\nwhich is the wrong meaning in this case. As written in the RFC, the \r\nsentence states that if a Configure-Request packet has n Configuration \r\nOptions in it, ALL of which are not recognizable or not acceptable, then \r\nwhen the implementation returns its Configure-Reject packet, it's only \r\nallowed to indicate that up to n-1 options were rejected, when in truth \r\nALL were rejected. Removing the word \"proper\" removes this unintended and \r\nincorrect limitation.", "submit_date": "2006-09-27", "submitter_name": "Stuart Cheshire", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "544", "doc-id": "RFC1542", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.1.1", "orig_text": " If a client falls into this category, it SHOULD set (to 1) the\r\n newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY\r\n messages it generates. This will provide a hint to BOOTP servers\r\n and relay agents that they should attempt to broadcast their\r\n BOOTREPLY messages to the client.", "correct_text": " If a client falls into this category, it SHOULD set (to 1) the\r\n newly-defined BROADCAST flag in the 'flags' field of BOOTREQUEST\r\n messages it generates. This will provide a hint to BOOTP servers\r\n and relay agents that they should attempt to broadcast their BOOTREPLY\r\n messages to the client.", "notes": "(i.e. the first instance of \"BOOTREPLY\" should be \"BOOTREQUEST\".)\r\n", "submit_date": "2002-10-24", "submitter_name": "Grzegorz R. Gryczka", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "545", "doc-id": "RFC1534", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": " Any message received by a DHCP server that includes a 'DHCP message\n type' (51) option is assumed to have been sent by a DHCP client.", "correct_text": " Any message received by a DHCP server that includes a 'DHCP message\n type' (53) option is assumed to have been sent by a DHCP client.\n", "notes": "", "submit_date": "2001-09-05", "submitter_name": "Tyler Tidman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "546", "doc-id": "RFC1531", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.4.4", "orig_text": " Any DHCPACK messages that arrive with an 'xid' that does not match the\n When the client receives a DHCPACK from the server, the client\n computes the lease expiration time as the sum of the time at which the\n client sent the DHCPREQUEST message and the duration of the lease in\n the DHCPACK message.", "correct_text": " Any DHCPACK messages that arrive with an 'xid' that does not match the\n 'xid' of the client's DHCPREQUEST message are silently discarded.\n When the client receives a DHCPACK from the server, the client\n computes the lease expiration time as the sum of the time at which the\n client sent the DHCPREQUEST message and the duration of the lease in\n the DHCPACK message. \n", "notes": "", "submit_date": "2001-10-31", "submitter_name": "Jim Withnall", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "547", "doc-id": "RFC1517", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": " It has become clear that the first two of these problems are likely\n to become critical in the near term. Classless Inter-Domain\n Routing (CIDR) ttempts to deal with these problems by defining a\n mechanism to slow the growth of routing tables and reduce the need\n to allocate new IP network numbers.", "correct_text": " It has become clear that the first two of these problems are likely\n to become critical in the near term. Classless Inter-Domain\n Routing (CIDR) attempts to deal with these problems by defining a\n mechanism to slow the growth of routing tables and reduce the need\n to allocate new IP network numbers.\n", "notes": "", "submit_date": "2002-03-30", "submitter_name": "Mr. Sharky", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "548", "doc-id": "RFC1413", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6", "orig_text": " 3) The 512 character limit on user IDs and the 64\r\n character limit on tokens should be understood to mean\r\n as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)\r\n token will be defined that has a length greater than 64", "correct_text": " 3) The 512 character limit on user IDs and the 64\r\n character limit on tokens should be understood to mean\r\n as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)\r\n will be defined that has a length greater than 64", "notes": "", "submit_date": "2004-08-17", "submitter_name": "Tymon Rzes'niowiecki", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "549", "doc-id": "RFC1340", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "On page 87, it says:", "orig_text": "SUN OS 3.5\r\nSUN OS 4.0", "correct_text": "SUN-OS-3.5\r\nSUN-OS-4.0", "notes": "The white space isn't supposed to be accepted as part of a system name.\r\n\r\n\r\n", "submit_date": "2002-07-08", "submitter_name": "Jean Delvare", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "550", "doc-id": "RFC1321", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Section A.4: ", "orig_text": " #define MD MD5", "correct_text": " #define MD 5\n", "notes": "", "submit_date": "2001-01-19", "submitter_name": "Matt Borland", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "551", "doc-id": "RFC1321", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.4", "orig_text": " /* Round 3. */\r\n /* Let [abcd k s t] denote the operation\r\n a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */\r\n /* Do the following 16 operations. */", "correct_text": " /* Round 3. */\r\n /* Let [abcd k s i] denote the operation\r\n a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */\r\n /* Do the following 16 operations. */", "notes": "", "submit_date": "2002-06-14", "submitter_name": "Gregory Smith", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "552", "doc-id": "RFC1321", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.4", "orig_text": " the each bit of F(X,Y,Z) will be independent", "correct_text": " then each bit of F(X,Y,Z) will be independent\n", "notes": "", "submit_date": "2000-04-12", "submitter_name": "Michael Amling", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "553", "doc-id": "RFC1321", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix A says:", "orig_text": " printf\r\n (\"MD%d time trial. Digesting %d %d-byte blocks ...\", MD,\r\n TEST_BLOCK_LEN, TEST_BLOCK_COUNT);", "correct_text": " printf\r\n (\"MD%d time trial. Digesting %d %d-byte blocks ...\", MD,\r\n TEST_BLOCK_COUNT, TEST_BLOCK_LEN);", "notes": "", "submit_date": "2006-11-15", "submitter_name": "Gennaro Prota", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2630", "doc-id": "RFC5988", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": " ext-name-star = parmname \"*\" ; reserved for RFC2231-profiled\r\n ; extensions. Whitespace NOT\r\n ; allowed in between.", "correct_text": " ext-name-star = parmname \"*\" ; reserved for RFC5987-profiled\r\n ; extensions. Whitespace NOT\r\n ; allowed in between.", "notes": "RFC5987 clarifies RFC2231 for use in HTTP. The update in RFC5988 left two mentions of RFC2231 which should be updated.", "submit_date": "2010-11-13", "submitter_name": "Julian Reschke", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "562", "doc-id": "RFC1035", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.4.2", "orig_text": " +-----------------------------------------+\r\n Header | OPCODE=RESPONSE, ID=997 |\r\n +-----------------------------------------+\r\n Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |\r\n +-----------------------------------------+\r\n Answer | VENERA.ISI.EDU A IN 10.1.0.52 |\r\n +-----------------------------------------+\r\n Authority | |\r\n +-----------------------------------------+\r\n Additional | |\r\n +-----------------------------------------+\r\n", "correct_text": " +-----------------------------------------+\r\n Header | OPCODE=IQUERY, ID=997, QR=1 |\r\n +-----------------------------------------+\r\n Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |\r\n +-----------------------------------------+\r\n Answer | VENERA.ISI.EDU A IN 10.1.0.52 |\r\n +-----------------------------------------+\r\n Authority | |\r\n +-----------------------------------------+\r\n Additional | |\r\n +-----------------------------------------+", "notes": "There is an error in the Header line. It should be\r\n\"OPCODE=IQUERY, ID=997, QR=1\" because the OPCODE does not have a \r\nvalue of RESPONSE (see Section 4.1.1). \r\n", "submit_date": "2003-02-09", "submitter_name": "CFeng", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "563", "doc-id": "RFC1035", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.1", "orig_text": "Because these files are text files several special encodings are\r\nnecessary to allow arbitrary data to be loaded. In particular:\r\n\r\n of the root.\r\n\r\n@ A free standing @ is used to denote the current origin.", "correct_text": "Because these files are text files several special encodings are\r\nnecessary to allow arbitrary data to be loaded. In particular:\r\n\r\n@ A free standing @ is used to denote the current origin.", "notes": "\"of the root.\" makes no sense here.", "submit_date": "2006-03-04", "submitter_name": "Allan Edward Prentice", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "564", "doc-id": "RFC1034", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.3", "orig_text": " The usual mail address @ is mapped into a\n domain name by converting into a single label\n (regardles of dots it contains), converting into a\n domain name using the usual text format for domain names (dots\n denote label breaks), and concatenating the two to form a single\n domain name. ", "correct_text": " The usual mail address @ is mapped into a\n domain name by converting into a single label\n (regardless of dots it contains), converting into a\n domain name using the usual text format for domain names (dots\n denote label breaks), and concatenating the two to form a single\n domain name.\n", "notes": "", "submit_date": "2003-02-06", "submitter_name": "Chlisin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "565", "doc-id": "RFC1034", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.3.1", "orig_text": "This bit specifies specifies whether the requester wants recursive service \r\nfor this query. Clients may.....", "correct_text": "This bit specifies whether the requester wants recursive service for this \r\nquery. Clients may.....\r\n", "notes": "", "submit_date": "2006-02-18", "submitter_name": "\"Yin Shuming\"", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "566", "doc-id": "RFC1033", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "7", "orig_text": " SRI.COM. NS\r\n*Here-->> KL.SRI.COM. KL.SRI.COM. A 10.1.0.2.", "correct_text": " SRI.COM. NS KL.SRI.COM. \r\n*Here-->> KL.SRI.COM. A 10.1.0.2.", "notes": " You can refer to RR \"NS (Name Server)\" on Page 6 in the same RFC for the reason.\n --VERIFIER NOTES-- \n The status of this document is UNKNOWN. This means that it is so old, that it should not be used as a reference. There is really no way to know if the syntax that you point out was valid in 1987, when the document was published.\r\n\r\nMaybe we should transition the document to HISTORIC?", "submit_date": "2002-05-05", "submitter_name": "\"CFeng\"", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "573", "doc-id": "RFC793", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A number of details in RFC 793 were corrected, modified, or clarified in RFC 1122. Familiarity with RFC 1122 and more recent TCP documents is imperative before any implementation of RFC 793 is attempted.", "orig_text": "TCP Feature RFC 793 Ref See RFC 1122 Section\r\n\r\nReceived PUSH bit\tSection 2.8\t\t4.2.2.2\t\r\nUrgent Pointer\t\tSection 3.1\t\t4.2.2.4\r\nTCP state diagram\tSection 3.2, p.23\t4.2.2.8\r\nSimultaneous Open\tSection 3.4, Fig 8\t4.2.2.10\r\nRetransmission Timeout\tSection 3.7\t\t4.2.2.15, 4.2.3.1\r\nEvent Processing\tSection 3.9\t\t4.2.2.20\r\n", "correct_text": "", "notes": "", "submit_date": "2007-02-22", "submitter_name": "Robert Braden", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "574", "doc-id": "RFC793", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "In Section 3.7, page 43, it says:", "orig_text": " If the the user signals a push function then the\r\n data must be sent even if it is a small segment.", "correct_text": " If the user signals a push function then the\r\n data must be sent even if it is a small segment.\r\n", "notes": "", "submit_date": "2005-05-22", "submitter_name": "Yin Shuming", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "575", "doc-id": "RFC793", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.7", "orig_text": " If there are several pending passive OPENs (recorded in TCBs) with the\r\n same local socket, an foreign active OPEN ...", "correct_text": " If there are several pending passive OPENs (recorded in TCBs) with\r\n the same local socket, a foreign active OPEN ...\r\n", "notes": "", "submit_date": "2003-10-29", "submitter_name": "Morris M. Keesan", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "576", "doc-id": "RFC792", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "In the Introduction, fourth paragraph, it says:", "orig_text": "Also ICMP messages are only sent about errors in handling fragment zero of\r\nfragemented datagrams. (Fragment zero has the fragment offeset equal\r\nzero).", "correct_text": "Also ICMP messages are only sent about errors in handling fragment zero of\r\nfragmented datagrams. (Fragment zero has the fragment offset equal\r\nzero).", "notes": "", "submit_date": "2004-03-26", "submitter_name": "Arun Darlie Koshy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "583", "doc-id": "RFC791", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "On page 23, it says:", "orig_text": "The intitial contents of the timestamp data area must be zero \r\nor internet address/zero pairs.", "correct_text": "The initial contents of the timestamp data area must be zero \r\nor internet address/zero pairs.", "notes": "Spelling error.", "submit_date": "2004-06-16", "submitter_name": "Pavel Uvarov", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "584", "doc-id": "RFC1123", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7", "orig_text": "[TELNET:9] \"Telnet End-Of-Record Option,\" J. Postel, RFC-855, December 1983. \r\n", "correct_text": "[TELNET:9] \"Telnet End-Of-Record Option,\" J. Postel, RFC-885, December 1983.", "notes": "RFC 855 is \"Telnet Option Specifications\"; RFC 885 is \"Telnet end of record option\".", "submit_date": "2003-02-12", "submitter_name": "Ben Harris", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "586", "doc-id": "RFC2026", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "10.3.1", "orig_text": " 4. The contributor represents that contribution properly\r\n acknowledge major contributors.\r\n\r\n 5. The contribuitor, the organization (if any) he represents and\r\n the owners of any proprietary rights in the contribution, agree\r\n that no information in the contribution is confidential and\r\n that the ISOC and its affiliated organizations may freely\r\n disclose any information in the contribution.", "correct_text": " 4. The contributor represents that the contribution properly\r\n acknowledges major contributors.\r\n\r\n 5. The contributor, the organization (if any) he represents and\r\n the owners of any proprietary rights in the contribution, agree\r\n that no information in the contribution is confidential and\r\n that the ISOC and its affiliated organizations may freely\r\n disclose any information in the contribution.", "notes": "verb agreement (\"acknowledges\") and spelling correction (\"contributor\")", "submit_date": "2003-10-07", "submitter_name": "Morris M. Keesan", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "587", "doc-id": "RFC2040", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": "6. Decrypt En to create Pn-1.", "correct_text": "6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.\r\n For short messages where Cn-2 does not exist, use the IV.", "notes": "", "submit_date": "2004-03-22", "submitter_name": "Bob Baldwin", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "588", "doc-id": "RFC2046", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.2.2.2", "orig_text": "Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)\r\nSubject: Audio mail\r\nMessage-ID: ", "correct_text": "Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)\r\nMessage-ID: \r\nSubject: Audio mail", "notes": "", "submit_date": "2001-12-22", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "589", "doc-id": "RFC2046", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.2.3.7", "orig_text": "Content-Type: message/external-body;\r\n access-type=mail-server\r\n server=\"listserv@bogus.bitnet\";\r\n expiration=\"Fri, 14 Jun 1991 19:13:14 -0400 (EDT)\"", "correct_text": "Content-Type: message/external-body;\r\n access-type=mail-server;\r\n server=\"listserv@bogus.bitnet\";\r\n expiration=\"Fri, 14 Jun 1991 19:13:14 -0400 (EDT)\"", "notes": "Semicolons were missing.", "submit_date": "2001-12-22", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "590", "doc-id": "RFC2231", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.1", "orig_text": " Content-Type: application/x-stuff\r\n title*0*=us-ascii'en'This%20is%20even%20more%20\r\n title*1*=%2A%2A%2Afun%2A%2A%2A%20\r\n title*2=\"isn't it!\"", "correct_text": " Content-Type: application/x-stuff;\r\n title*0*=us-ascii'en'This%20is%20even%20more%20;\r\n title*1*=%2A%2A%2Afun%2A%2A%2A%20;\r\n title*2=\"isn't it!\"", "notes": "", "submit_date": "2001-04-17", "submitter_name": "Shuhei KOBAYASHI", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "591", "doc-id": "RFC2252", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": " [ \"EQUALITY\" woid ; Matching Rule name\r\n [ \"ORDERING\" woid ; Matching Rule name", "correct_text": " [ \"EQUALITY\" woid ] ; Matching Rule name\r\n [ \"ORDERING\" woid ] ; Matching Rule name", "notes": "", "submit_date": "2003-10-15", "submitter_name": "Mark Wahl", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "592", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.1.2", "orig_text": " C ciphertext to be decrypted, an octet string of length k,\r\n where k = 2hLen + 2\r\n", "correct_text": " C ciphertext to be decrypted, an octet string of length k,\r\n where k >= 2hLen + 2\r\n", "notes": "In the \"Input:\" section, near the top of the page, the condition\r\nspecified for 'k' is too restrictive. {This becomes clear from\r\nthe context - see e.g. 'step 1. c.' in mid-page 22.}\r\n", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "593", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7.1.2", "orig_text": " b. Apply the RSADP decryption primitive (Section 5.1.2) to the\r\n\t RSA private key K and the ciphertext representative c to\r\n produce an integer message representative m:\r\n \r\n ", "correct_text": " b. Apply the RSADP decryption primitive (Section 5.1.2) to the\r\n RSA private key K and the ciphertext representative c to\r\n produce an integer message representative m:", "notes": "The first line of 'step 2. b.', is indented too much (by 3 chars)", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "594", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": " c. Convert the message representative m to an encoded message\r\n EM of length k octets (see Section 4.1):\r\n\r\n EM' = I2OSP (m, k).\r\n ", "correct_text": " c. Convert the message representative m to an encoded message\r\n EM of length k octets (see Section 4.1):\r\n\r\n EM = I2OSP (m, k).\r\n\r\n", "notes": " In 'step 2. c.', in fact \"EM\" is computed, not \"EM'\" -- as stated\r\n in the text; see also 'step 3.' below.", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4712", "doc-id": "RFC5661", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "6.2.1.3.1.", "orig_text": " ACE4_DELETE\r\n\r\n Operation(s) affected:\r\n\r\n REMOVE", "correct_text": " ACE4_DELETE\r\n\r\n Operation(s) affected:\r\n\r\n REMOVE\r\n\r\n RENAME", "notes": "ACE4_DELETE on the source file may allow a rename to proceed in cases where the user does not have ACE4_DELETE_CHILD on the source directory. It may also affect the ability of the user to be able to RENAME if there is an existing file in the target directory with the target name.\r\n\r\nAD notes based on Chuck Lever's input. \r\no\tThe text in RFC 5661 Section 6.2.1.3.1 matches the text in RFC 7530 Section 6.2.1.3.1. Are updaed of RFC 7530 also needed for this reason?\r\no\tShould the Notes section of the errata be added to Section 6.2.1.3.2?\r\no\tA consideration is if there are already server implementations that reject RENAME operations in these cases, or do all server implementations permit RENAME?\r\no\tThis is held so that the issues can be addressed in rfc5661bis after further discussion.\r\no\tAdditional Editorial correction: The Discussion subsections of ACE4_DELETE and ACE4_DELETE are missing the word \"how\". \r\n", "submit_date": "2016-06-16", "submitter_name": "Trond Myklebust", "verifier_id": "", "verifier_name": "Magnus Westerlund", "update_date": "2020-09-03 11:11:06"}, {"errata_id": "609", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Section A.2 The Options field: ", "orig_text": " 1 2\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3\r\n -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+\r\n | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|\r\n -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+", "correct_text": " 1 2\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+\r\n | | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "611", "doc-id": "RFC4342", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.3", "orig_text": " Its four data bytes indicate the rate at which\r\n the receiver has received data since it last sent an\r\n acknowledgement, in bytes per second. To calculate this receive\r\n rate, the receiver sets t to the larger of the estimated round-\r\n trip time and the time since the last Receive Rate option was\r\n sent.", "correct_text": " Its four data bytes indicate the rate at which\r\n the receiver has received data over the last round-trip time,\r\n in bytes per second. To calculate the time interval t for\r\n calculating this receive rate, the receiver follows Section\r\n 6.2 of [RFC3448].", "notes": "This errata updates RFC 4342 to use the definition of the receive rate \r\nas specified in RFC 3448.", "submit_date": "2007-10-24", "submitter_name": "Sally Floyd", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "595", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.1", "orig_text": " +-----------+\r\n | M |\r\n +-----------+\r\n |\r\n V\r\n Hash\r\n |\r\n V\r\n +--------+----------+----------+\r\n M' = |Padding1| mHash | salt |\r\n +--------+----------+----------+\r\n |\r\n +--------+----------+ V\r\n DB = |Padding2|maskedseed| Hash\r\n +--------+----------+ |\r\n | |\r\n V | +--+\r\n xor <--- MGF <---| |bc|\r\n | | +--+\r\n | | |\r\n V V V\r\n +-------------------+----------+--+\r\n EM = | maskedDB |maskedseed|bc|\r\n +-------------------+----------+--+\r\n", "correct_text": " +-----------+\r\n | M |\r\n +-----------+\r\n |\r\n V\r\n Hash\r\n |\r\n V\r\n +--------+----------+----------+\r\n M' = |Padding1| mHash | salt |\r\n +--------+----------+----------+\r\n |\r\n +--------+----------+ V\r\n DB = |Padding2| salt | Hash\r\n +--------+----------+ |\r\n | |\r\n V | +--+\r\n xor <--- MGF <---| |bc|\r\n | | +--+\r\n | | |\r\n V V V\r\n +-------------------+----------+--+\r\n EM = | maskedDB | H |bc|\r\n +-------------------+----------+--+\r\n", "notes": " Figure 2 names two fields \"maskedseed\" which in fact are _very_\r\n different, and this nomenclature matches neither the figure\r\n caption given nor the subsequent text -- see e.g. 'step 6.' and \r\n 'step 8.' on page 39 and 'step 12.' on page 40.", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "596", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.2", "orig_text": " SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00\r\n 04 40 || H.\r\n", "correct_text": " SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00\r\n 04 40 || H.\r\n", "notes": "The second line of the last example of 'Note 1.' (for SHA-512) is indented too much (by 3 chars).", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "597", "doc-id": "RFC4679", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.3.17", "orig_text": "Valid values for the sub-fields are as follows:\r\n\r\n Data Link\r\n\r\n 0x01 AAL5\r\n 0x02 Ethernet", "correct_text": "Valid values for the sub-fields are as follows:\r\n\r\n Data Link\r\n\r\n 0x00 AAL5\r\n 0x01 Ethernet\r\n", "notes": "\"Data Link\" values in the Value field of the Access-Loop-Encapsulation (Section 3.3.17, paragraph 14) are incorrect, should start from 0x00 and not 0x01 (see TR-101).", "submit_date": "2007-10-03", "submitter_name": "Carlos Pignataro", "verifier_id": "", "verifier_name": "Vince Mammoliti", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "598", "doc-id": "RFC4623", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.3", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |M|H|0|0|0|0| Length | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | MRU |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |M|H|0|0|0|0| Length | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 94 | MRU |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "notes": "Missing \"Attribute Type\" in the AVP Header of Figure 4.", "submit_date": "2006-10-25", "submitter_name": "Carlos Pignataro", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "599", "doc-id": "RFC4623", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.4", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |M|H|0|0|0|0| Length | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | MRRU |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |M|H|0|0|0|0| Length | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 95 | MRRU |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "notes": "Missing \"Attribute Type\" in the AVP Header of Figure 5.", "submit_date": "2006-10-25", "submitter_name": "Carlos Pignataro", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "8625", "doc-id": "RFC4086", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.1.3.", "orig_text": "Despite meeting all the tests suggested by Knuth, that sequence is unsuitable\r\nfor cryptographic us, as adversaries must be assumed to have copies\r\nof all commonly published \"random\" sequences and to be able to spot\r\nthe source and predict future values.", "correct_text": "Despite meeting all the tests suggested by Knuth, that sequence is unsuitable\r\nfor cryptographic use, as adversaries must be assumed to have copies\r\nof all commonly published \"random\" sequences and to be able to spot\r\nthe source and predict future values.", "notes": "Simple typo; missing \"e\" in the expression \"for cryptographic us,\".", "submit_date": "2025-11-02", "submitter_name": "mrrccc", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2025-11-05 21:05:19"}, {"errata_id": "610", "doc-id": "RFC4342", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6", "orig_text": " 2. A Receive Rate option, defined in Section 8.3, specifying the\r\n rate at which data was received since the last DCCP-Ack was\r\n sent.", "correct_text": " 2. A Receive Rate option, defined in Section 8.3, specifying the\r\n rate at which data was received over the last round-trip time.", "notes": "Section 8.3 of RFC 4342 (DCCP CCID 3) specifies that the Receive\r\nRate option reports the receive rate since the last feedback packet\r\nwas sent. In contrast, Section 6.2 of RFC 3448 (TFRC) specifies\r\nthat the feedback packet reports the receive rate over the last\r\nround-trip time. As a result, the receive rate specified by\r\nRFC 4342 differs from that of TFRC for a feedback packet after an\r\nidle period; the receive rate report specified in RFC 4342 reports\r\nthe receive rate over the entire idle period. The receive rate\r\nreported by RFC 4342 also differs from that of TFRC for an early\r\nfeedback packet reporting a new loss event. This errata updates\r\nRFC 4342 to use the definition of the receive rate as specified in\r\nRFC 3448.", "submit_date": "2007-10-24", "submitter_name": "Sally Floyd", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "631", "doc-id": "RFC3987", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "GLOBAL", "orig_text": "[semicolon outside]\r\n\"http://example.org/rosé\";", "correct_text": "[semicolon inside]\r\n\"http://example.org/rosé\"", "notes": "In ALL cases, the final semicolon has to be inside the double quotes, not outside. See the example above.\r\n\r\nfrom pending", "submit_date": "2007-06-26", "submitter_name": "Martin Duerst", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "1060", "doc-id": "RFC2631", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "This reference is cited in Section 1, but does not appear in the\r\nReferences section. It should be added:\r\n\r\n[DH76] W. Diffie and M. E. Hellman, \"New Directions in Cryptography\",\r\n IEEE Transactions on Information Theory, vol. IT-22, Nov. 1976, \r\n pp: 644-654.", "correct_text": "", "notes": "", "submit_date": "2007-09-13", "submitter_name": "Javier Ader", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "600", "doc-id": "RFC4623", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.6", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |M|H|0|0|0|0| Length | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Tunnel ID | Session ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Ns (opt) | Nr (opt) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Offset Size (opt) | Offset pad... (opt) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "notes": "Extraneous part of the AVP Header in Figure 7.", "submit_date": "2006-10-25", "submitter_name": "Carlos Pignataro", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "601", "doc-id": "RFC4866", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": " If the Binding Update message is authenticated based on the CGA \r\n property of the mobile node's home address or by a proof of the\r\n mobile node's knowledge of a permanent home keygen token, the\r\n lifetime for the binding SHOULD be set to the maximum of\r\n ^^^^^^^\r\n MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime\r\n field of the Binding Update message.", "correct_text": " If the Binding Update message is authenticated based on the CGA\r\n property of the mobile node's home address or by a proof of the\r\n mobile node's knowledge of a permanent home keygen token, the\r\n lifetime for the binding SHOULD be set to the minimum of\r\n ^^^^^^^ \r\n MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime\r\n field of the Binding Update message.", "notes": "Page 21, 1st paragraph", "submit_date": "2007-05-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Christian Vogt", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "602", "doc-id": "RFC4866", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": " If the Binding Update message\r\n is authenticated through a proof of the mobile node's reachability at\r\n the home address, then the lifetime for the binding SHOULD be set to\r\n the maximum of MAX_RR_BINDING_LIFETIME [1] and the value specified in\r\n ^^^^^^^\r\n the Lifetime field of the Binding Update message.\r\n\r\n", "correct_text": " If the Binding Update message\r\n is authenticated through a proof of the mobile node's reachability at\r\n the home address, then the lifetime for the binding SHOULD be set to\r\n the minimum of MAX_RR_BINDING_LIFETIME [1] and the value specified in\r\n ^^^^^^^\r\n the Lifetime field of the Binding Update message.\r\n", "notes": "Page 21, 1st paragraph", "submit_date": "2007-05-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Christian Vogt", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "603", "doc-id": "RFC4866", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2", "orig_text": " The correspondent\r\n node may in either case grant a further reduced lifetime, but it MUST\r\n ^^^\r\n NOT accept a higher lifetime.", "correct_text": " The correspondent\r\n node MAY in either case grant a further reduced lifetime, but it MUST\r\n ^^^\r\n NOT accept a higher lifetime.", "notes": "Page 21, 1st paragraph", "submit_date": "2007-05-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Christian Vogt", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "604", "doc-id": "RFC4782", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.4", "orig_text": "The TCP host SHOULD set its congestion window cwnd to QS-cwnd only if\r\nQS-cwnd is greater than cwnd; otherwise, QS-cwnd is ignored.", "correct_text": "The TCP host SHOULD set its congestion window cwnd to QS-cwnd\r\nonly if QS-cwnd is greater than cwnd; otherwise, QS-cwnd is\r\nignored. In either case, the sender can transmit up to the\r\nminimum of the cwnd and the receiver's advertised window rwnd,\r\nas specified in [RFC2581].", "notes": "Clarification regarding the receive window.\r\n\r\nfrom pending", "submit_date": "2007-04-10", "submitter_name": "Michael Scharf", "verifier_id": "", "verifier_name": "Sally Floyd", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "605", "doc-id": "RFC4717", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "5.1.1", "orig_text": "- ATM One-to-one Cell Mode\r\n- AAL5 PDU Frame Mode", "correct_text": "- ATM One-to-one Cell Mode - PW Types: 0x000C and 0x000D\r\n- AAL5 PDU Frame Mode - PW Type: 0x000E", "notes": "\n --VERIFIER NOTES-- \n The author has correctly named the PW types and the reader can find the numeric identifier in both RFC4446 and the IANA registry. Thus the restatement of the numeric identifier is unnecessary.", "submit_date": "2007-10-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "606", "doc-id": "RFC2617", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.6", "orig_text": "These headers are instances of the Proxy-Authenticate and\r\nProxy-Authorization headers specified in sections 10.33 and 10.34 of the\r\nHTTP/1.1 specification [2] ...", "correct_text": "These headers are instances of the Proxy-Authenticate and\r\nProxy-Authorization headers specified in sections 14.33 and 14.34 of the\r\nHTTP/1.1 specification [2] ...", "notes": "Wrong section references in RFC 2616.\r\n\r\nReported by Julian Reschke on an IETF mailing list.", "submit_date": "2007-10-17", "submitter_name": "St\u00e9phane Bortzmeyer", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "607", "doc-id": "RFC4627", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2.2", "orig_text": " object = begin-object [ member *( value-separator member ) ]\r\n end-object\r\n", "correct_text": " object = begin-object [ member *( value-separator member ) ]\r\n end-object\r\n", "notes": "(edited by Alexey): Wrong indentation on the second line of the ABNF production, otherwise this is not legal ABNF.\r\n\r\n", "submit_date": "2007-10-17", "submitter_name": "St\u00e9phane Bortzmeyer", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "608", "doc-id": "RFC3958", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6.5", "orig_text": "iana-registered-protocol = ALPHA *31ALPHANUM", "correct_text": "Maybe:\r\n\r\niana-registered-protocol = ALPHA *31ALPHANUM\r\nALPHANUM = ALPHA / DIGIT", "notes": "The ALPHANUM production is missing from the grammar (and is not in\r\nRFC 4234 either).\r\n\r\nAlexey: this was obsoleted by Erratum # 2106.\r\n\n --VERIFIER NOTES-- \nObsoleted by Erratum # 2106, which fixed this properly.\r\n", "submit_date": "2007-10-17", "submitter_name": "St\u00e9phane Bortzmeyer", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2631", "doc-id": "RFC5988", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": " The example below shows an instance of the Link header encoding\r\n multiple links, and also the use of RFC 2231 encoding to encode both\r\n non-ASCII characters and language information.", "correct_text": " The example below shows an instance of the Link header encoding\r\n multiple links, and also the use of RFC 5987 encoding to encode both\r\n non-ASCII characters and language information.", "notes": "RFC5987 clarifies RFC2231 for use in HTTP. The update in RFC5988 left two mentions of RFC2231 which should be updated.", "submit_date": "2010-11-13", "submitter_name": "Julian Reschke", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "612", "doc-id": "RFC4342", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.3", "orig_text": " ", "correct_text": " Assume that the sender receives two feedback packets with \r\n Acknowledgement Numbers A1 and A2, respectively. Further assume\r\n that the sender sent no data packets in between Sequence Numbers\r\n A1+1 and A2, inclusive. (All those packets must have been pure\r\n acknowledgements, Sync and SyncAck packets, and so forth.) Then\r\n the sender MAY, at its discretion, ignore the second feedback\r\n packet's Receive Rate option. Note that when the sender decides\r\n to ignore such an option, it MUST NOT reset the nofeedback timer\r\n as it normally would; the nofeedback timer will expire as if the\r\n second feedback packet had not been received.", "notes": "This is a new paragraph to be added to the end of Section 8.3.\r\nIt specifies that if the interval covered by a feedback packet doesn't include \r\nany data packets, then the sender doesn't have to use the reported receive rate.", "submit_date": "2007-10-24", "submitter_name": "Sally Floyd", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "613", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": " acl = \"(\" [acl-identrights *(SP acl-identrights)] \")\"\r\n *(SPACE acl-identrights)] \")\"", "correct_text": " acl = \"(\" [acl-identrights *(SP acl-identrights)] \")\"", "notes": "", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "614", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": "[Formal syntax for UPDATECONTEXT was missing.] \r\n", "correct_text": "command-updatectx = \"UPDATECONTEXT\" 1*(SP context)\r\n", "notes": "", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "615", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.6.2", "orig_text": " Example: C: Z4S9 DELETEDSINCE \"/folder/site/\" 19951205103412\r\n S: Z4S9 DELETED \"blurdybloop\"\r\n S: Z4S9 DELETED \"anteaters\"\r\n S: Z4S9 OK \"DELETEDSINCE completed\"\r\n C: Z4U3 DELETEDSINCE \"/folder/site/\" 19951009040854\r\n S: Z4U3 NO (TOOOLD) \"Don't have that information\"\r\n", "correct_text": " Example: C: Z4S9 DELETEDSINCE \"/folder/site/\" \"19951205103412\"\r\n S: Z4S9 DELETED \"blurdybloop\"\r\n S: Z4S9 DELETED \"anteaters\"\r\n S: Z4S9 OK \"DELETEDSINCE completed\"\r\n C: Z4U3 DELETEDSINCE \"/folder/site/\" \"19951009040854\"\r\n S: Z4U3 NO (TOOOLD) \"Don't have that information\"\r\n ", "notes": "Fix DELETEDSINCE example to include quotes around timestamps\r\n\r\n", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "616", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "\"count\" metadata-type is not documented in prose. Will be removed in next revision.", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "617", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8", "orig_text": "command-lang = \"LANG\" *(SP lang-tag)", "correct_text": "command-lang = \"LANG\" 1*(SP lang-tag)", "notes": "Formal syntax for LANG command didn't require at least one language tag. Since it doesn't make sense to change the language to an unspecified value, the ABNF needs to be changed.", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "618", "doc-id": "RFC1122", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2.5", "orig_text": " OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x|\r\n Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | |\r\n", "correct_text": " OPEN to broadcast/multicast IP Address |4.2.3.10| | | | |x|\r\n Silently discard seg to bcast/mcast addr |4.2.3.10|x| | | | |\r\n", "notes": "", "submit_date": "2007-10-25", "submitter_name": "Bob Braden", "verifier_id": "", "verifier_name": "Bob Braden", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "619", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.4.5.", "orig_text": " C: A049 SEARCH \"/addressbook/~/public\" RETURN (\"addressbook.Alias\"\r\n \"addressbook.Email\") MAKECONTEXT ENUMERATE \"blob\" LIMIT 100 1\r\n SORT (\"addressbook.Alias\" \"i;octet\") NOT EQUAL\r\n \"addressbook.Email\" NIL", "correct_text": " C: A049 SEARCH \"/addressbook/~/public\" RETURN (\"addressbook.Alias\"\r\n \"addressbook.Email\") MAKECONTEXT ENUMERATE \"blob\" LIMIT 100 1\r\n SORT (\"addressbook.Alias\" \"i;octet\") NOT EQUAL\r\n \"addressbook.Email\" \"i;octet\" NIL\r\n\r\n", "notes": "One SEARCH example is missing comparator in EQUAL statement.\r\n\r\n", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "620", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "Need to use entry-path on notifications when DEPTH > 1 is specified.\r\n\r\n", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "621", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "Note explicitly that client commands must be transmitted in full\r\nbefore starting a new command. This includes literals and the\r\nAUTHENTICATE exchange.", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "622", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "", "correct_text": "", "notes": "Note that \"revocation of rights\" is also know as \"negative rights\".\r\n\r\n", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "623", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.6.1.", "orig_text": "An atom consists of one to 1024 non-special characters. It must\r\nbegin with a letter. Atoms are used for protocol keywords.", "correct_text": "", "notes": "Need to define the term \"non-special\" as equivalent to the syntax for \"ATOM-CHAR\".", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "624", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.6.2.", "orig_text": "A number consists of one or more digit characters, and represents a\r\nnumeric value. Numbers are restricted to the range of an unsigned\r\n32-bit integer: 0 < number < 4,294,967,296.\r\n", "correct_text": "", "notes": "Permit number to include 0 to match formal syntax.", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "625", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1.5.", "orig_text": " UTC Universal Coordinated Time as maintained by the Bureau\r\n International des Poids et Mesures (BIPM).", "correct_text": "", "notes": "\"Universal Coordinated Time\" should be \"Coordinated Universal Time\".\r\n", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "626", "doc-id": "RFC2244", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.5.", "orig_text": "An ACL is represented by a multi-value with each value containing an \r\nidentifier followed by a tab character followed by the rights. ", "correct_text": "", "notes": "This is incorrect and should be deleted from the document. The formal syntax in errata 1 is normative.\r\n", "submit_date": "2001-01-23", "submitter_name": "Chris Newman", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "627", "doc-id": "RFC2286", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In the Appendix: ", "orig_text": " /* if key is longer than 64 bytes reset it to key=SHA1(key) */", "correct_text": " /* if key is longer than 64 bytes reset it to key=RMD160(key) */", "notes": "\r\n", "submit_date": "2002-09-17", "submitter_name": "Kevin Springle", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "629", "doc-id": "RFC3987", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1", "orig_text": "Syntaxical. ", "correct_text": "Syntactical. ", "notes": "from pending", "submit_date": "2007-06-26", "submitter_name": "Martin Duerst", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "632", "doc-id": "RFC4028", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9", "orig_text": "If the incoming request contains a Supported header field with a\r\nvalue 'timer' but does not contain a Session-Expires header, it means\r\nthat the UAS is indicating support for timers but is not requesting\r\none.", "correct_text": "If the incoming request contains a Supported header field with a\r\nvalue 'timer' but does not contain a Session-Expires header, it means\r\nthat the UAC is indicating support for timers but is not requesting\r\none.", "notes": "I believe that in the first sentence, the reference to \"...the UAS is\r\nindicating support....\" should read \"... the UAC is indicating\r\nsupport...\"\r\n", "submit_date": "2007-06-25", "submitter_name": "Ervin Wittner", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "633", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.1.1", "orig_text": " +----------+---------+-------+\r\n DB = | lHash | PS | M |\r\n +----------+---------+-------+\r\n |\r\n +----------+ V\r\n | seed |--> MGF ---> xor\r\n +----------+ |\r\n | |\r\n +--+ V |\r\n |00| xor <----- MGF <-----|\r\n +--+ | |\r\n | | |\r\n V V V\r\n +--+----------+----------------------------+\r\n EM = |00|maskedSeed| maskedDB |\r\n +--+----------+----------------------------+", "correct_text": " +----------+--------+--+-------+\r\n DB = | lHash | PS |01| M |\r\n +----------+--------+--+-------+\r\n |\r\n +----------+ V\r\n | seed |--> MGF ---> xor\r\n +----------+ |\r\n | |\r\n +--+ V |\r\n |00| xor <----- MGF <-----|\r\n +--+ | |\r\n | | |\r\n V V V\r\n +--+----------+------------------------------+\r\n EM = |00|maskedSeed| maskedDB |\r\n +--+----------+------------------------------+", "notes": "", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "635", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.2.3", "orig_text": " * maskGenAlgorithm identifies the mask generation function. It\r\n shall be an algorithm ID with an OID in the set\r\n\r\n PKCS1MGFAlgorithms (see Appendix A.2.1). The default mask\r\n generation function is MGF1 with SHA-1. For MGF1 (and more\r\n generally, ...", "correct_text": " * maskGenAlgorithm identifies the mask generation function. It\r\n shall be an algorithm ID with an OID in the set\r\n PKCS1MGFAlgorithms (see Appendix A.2.1). The default mask\r\n generation function is MGF1 with SHA-1. For MGF1 (and more\r\n generally, ...", "notes": "The bulleted section for 'maskGenAlgorithm' contains an unexpected\r\nblank line within the second sentence.\r\n\r\n\r\n\r\n\r\n \r\n", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3362", "doc-id": "RFC6110", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "GLOBAL", "orig_text": "Table of Contents\r\n-----------------\r\nOLD\r\n 12.16. The @nma:unique Annotation ..............................74\r\n\r\n\r\nSec. 5.3, entry in Table 2:\r\n---------------------------\r\nOLD\r\n | @nma:unique | 10.55 | |\r\n\r\nSec. 10.55:\r\n-----------\r\nOLD\r\n\r\n This statement is mapped to the @nma:unique attribute. ARGUMENT MUST\r\n be translated so that every node identifier in each of its components\r\n is prefixed with the namespace prefix of the local module, unless the\r\n prefix is already present. The result of this translation then\r\n becomes the value of the @nma:unique attribute.\r\n\r\n For example, assuming that the local module prefix is \"ex\",\r\n\r\n unique \"foo ex:bar/baz\"\r\n\r\n is mapped to the following attribute/value pair:\r\n\r\n nma:unique=\"ex:foo ex:bar/ex:baz\"\r\n\r\nSec. 11.2, second paragraph:\r\n----------------------------\r\nOLD\r\n\r\n In a Schematron schema generated by the second mapping step, the\r\n basic unit of organization is a rule represented by the \r\n element. The following NETMOD-specific annotations from the hybrid\r\n schema (henceforth called \"semantic annotations\") are mapped to\r\n corresponding Schematron rules: , @nma:key, @nma:unique,\r\n @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma:\r\n leaf-list, and also @nma:mandatory appearing as an attribute of (see Section 11.2.1).\r\n\r\nSec. 12.16 (including its title):\r\n---------------------------------\r\nOLD\r\n\r\n12.16. The @nma:unique Annotation\r\n\r\n The mapping of this annotation is almost identical as for @nma:key,\r\n see Section 12.8, with two small differences:\r\n\r\n o The value of @nma:unique is a list of descendant schema node\r\n identifiers rather than simple leaf names. However, the XPath\r\n expressions specified in Section 12.8 work without any\r\n modifications if the descendant schema node identifiers are\r\n substituted for k_1, k_2, ..., k_n.\r\n\r\n o The message appearing as the text of is different:\r\n \"Violated uniqueness for list CONTELEM\".\r\n\r\nAppendix A:\r\n-----------\r\nOLD\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n\r\n\r\n", "correct_text": "Table of Contents\r\n-----------------\r\nNEW\r\n 12.16. The Annotation ..............................74\r\n\r\nSec. 5.3, entry in Table 2:\r\n---------------------------\r\nNEW\r\n | | 10.55 | |\r\n\r\nSec. 10.55:\r\n-----------\r\n\r\nNEW\r\n\r\n This statement is mapped to the element. ARGUMENT MUST\r\n be translated so that every node identifier in each of its components\r\n is prefixed with the namespace prefix of the local module, unless the\r\n prefix is already present. The result of this translation then\r\n becomes the value of the @tag attribute which is attached to the\r\n element.\r\n\r\n For example, assuming that the local module prefix is \"ex\",\r\n\r\n unique \"foo ex:bar/baz\"\r\n\r\n is mapped to the following annotation element:\r\n\r\n \r\n\r\nSec. 11.2, second paragraph:\r\n----------------------------\r\nNEW\r\n\r\n In a Schematron schema generated by the second mapping step, the\r\n basic unit of organization is a rule represented by the \r\n element. The following NETMOD-specific annotations from the hybrid\r\n schema (henceforth called \"semantic annotations\") are mapped to\r\n corresponding Schematron rules: , , @nma:key,\r\n @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma:\r\n leaf-list, and also @nma:mandatory appearing as an attribute of (see Section 11.2.1).\r\n\r\nSec. 12.16 (including its title):\r\n---------------------------------\r\n12.16. The Annotation\r\n\r\n The mapping of this annotation is similar to @nma:key,\r\n see Section 12.8, with two small differences:\r\n\r\n o The value of the @tag attribute of is a list of\r\n descendant schema node identifiers rather than simple leaf names.\r\n However, the XPath expressions specified in Section 12.8 work\r\n without any modifications if the descendant schema node\r\n identifiers are substituted for k_1, k_2, ..., k_n.\r\n\r\n o The message appearing as the text of is different:\r\n \"Violated uniqueness of NODES\", where NODES is the value of the\r\n @tag attribute.\r\n\r\nAppendix A:\r\n-----------\r\nNEW\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n ", "notes": "The 'unique' YANG statement, which is a substatement of 'list', has the cardinality of \"0..n\". Multiple sibling 'unique' statements cannot be mapped to a single @nma:unique attribute in the hybrid schema. Therefore, an XML element, , has to be used for mapping the 'unique' statement instead of the attribute, much like the it is done for the 'must' statement.\r\n\r\nThis change to the mapping of the 'unique' statement is realized by changing the text of Section 10.55. Several other sections are also affected by this change.", "submit_date": "2012-09-21", "submitter_name": "Jernej Tuljak", "verifier_id": "", "verifier_name": "Benoit Claise", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "646", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.3", "orig_text": "Content-Location: images/ietflogo2.gif\r\n; Note - Relative Content-Location is resolved by base\r\n; specified in the Multipart/Related Content-Location heading", "correct_text": "Content-Location: images/ietflogo2.gif\r\nComments: Note - Relative Content-Location is resolved by base\r\nspecified in the Multipart/Related Content-Location heading", "notes": "", "submit_date": "2002-01-21", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "647", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.3", "orig_text": "Content-Location: images/ietflogo2.gif\r\n; Note - Relative Content-Location is resolved by base\r\n; specified in the Multipart/Related Content-Location heading", "correct_text": "Content-Location: images/ietflogo2.gif\r\nComments: Note - Relative Content-Location is resolved by base\r\nspecified in the Multipart/Related Content-Location heading", "notes": "", "submit_date": "2002-01-21", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "648", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.6", "orig_text": "Content-ID: ", "correct_text": "Content-ID: ", "notes": "", "submit_date": "2002-01-21", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "649", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.6", "orig_text": "Content-Type: multipart/related; boundary=\"boundary-example-2\";\r\n type=\"text/html\"\r\n--boundary-example-2", "correct_text": "Content-Type: multipart/related; boundary=\"boundary-example-2\";\r\n type=\"text/html\"\r\n\r\n--boundary-example-2", "notes": "\r\n", "submit_date": "2002-01-21", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "650", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.6", "orig_text": "Content-ID: ", "correct_text": "Content-ID: ", "notes": "\r\n", "submit_date": "2002-01-21", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "651", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.6", "orig_text": "Content-Type: multipart/related; boundary=\"boundary-example-3\";\r\n type=\"text/html\"\r\n--boundary-example-3\r\nContent-Type: text/html;charset=\"US-ASCII\"\r\nContent-ID: <4@foo@bar.net>", "correct_text": "Content-Type: multipart/related; boundary=\"boundary-example-3\";\r\n type=\"text/html\"\r\n\r\n--boundary-example-3\r\nContent-Type: text/html;charset=\"US-ASCII\"\r\nContent-ID: <4.foo@bar.net>\r\n\r\n", "notes": "\r\n\r\n", "submit_date": "2002-01-21", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3008", "doc-id": "RFC6351", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "Appendix A", "orig_text": "### Section 3.3: vCard Format Specification\r\n#\r\n# 3.3\r\niana-token = xsd:string { pattern = \"[a-zA-Z0-9-]+\" }\r\nx-name = xsd:string { pattern = \"x-[a-zA-Z0-9-]+\" }\r\n", "correct_text": "### Section 3.3: vCard Format Specification\r\n#\r\n# 3.3\r\niana-token = xsd:string { pattern = \"[a-zA-Z0-9\\-]+\" }\r\nx-name = xsd:string { pattern = \"x-[a-zA-Z0-9\\-]+\" }\r\n", "notes": "The minus sign has to be escaped with a backslash.", "submit_date": "2011-10-31", "submitter_name": "Torsten Fusswinkel", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "682", "doc-id": "RFC2324", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.1.1", "orig_text": "Content-Type set to \"application/coffee-pot-command\".", "correct_text": "Content-Type set to \"message/coffeepot\".", "notes": "There is a discrepancy in RFC2324 regarding the content type for HTCPCP \r\nrequests. In section 2.1.1, the MIME type is \r\n\"application/coffee-pot-command\", while in section 4 the MIME type is \r\n\"message/coffepot\".\r\n\r\n--VERIFIER NOTE--\r\nThis change will make section 2.1.1 consistent with section 4.", "submit_date": "2002-11-20", "submitter_name": "Andrew Cook", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "636", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "B.1", "orig_text": "Six hash functions are given as examples for the encoding methods\r\nin this document: MD2 [33], MD5 [41], SHA-1 [38], and the\r\nproposed algorithms SHA-256, SHA-384, and SHA-512 [39].", "correct_text": "Six hash functions are given as examples for the encoding methods\r\nin this document: MD2 [33], MD5 [41], and the algorithms SHA-1,\r\nSHA-256, SHA-384, and SHA-512 [38'].", "notes": "RFC 3447 has been published on Feb 04, 2003 (according to the\r\ntime stamp of rfc3447.txt on ).\r\n\r\nThe new \"Secure Hash Standard\", FIPS Pub 180-2 had been published\r\non \"2002 August 1\" and became \"effective on February 1, 2003\" as\r\nspecified on page ii of FIPS 180-2, \"9. Implementation Schedule\".\r\n\r\nBoth events predate the publishing date of RFC 3447.\r\n\r\nTherefore, the first sentence of the second paragraph on page 53 should be as noted above.", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "638", "doc-id": "RFC3447", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "F", "orig_text": "[38] National Institute of Standards and Technology (NIST).\r\n FIPS Publication 180-1: Secure Hash Standard. April 1994.\r\n\r\n[39] National Institute of Standards and Technology (NIST).\r\n Draft FIPS 180-2: Secure Hash Standard. Draft, May 2001.\r\n Available from http://www.nist.gov/sha/.", "correct_text": "[38] National Institute of Standards and Technology (NIST).\r\n FIPS Publication 180-2: Secure Hash Standard. August\r\n 2002.\r\n\r\n", "notes": "RFC 3447 has been published on Feb 04, 2003 (according to the\r\ntime stamp of rfc3447.txt on ).\r\n\r\nThe new \"Secure Hash Standard\", FIPS Pub 180-2 had been published\r\non \"2002 August 1\" and became \"effective on February 1, 2003\" as\r\nspecified on page ii of FIPS 180-2, \"9. Implementation Schedule\".\r\n\r\nBoth events predate the publishing date of RFC 3447.\r\n\r\nThe reference should be updated as noted above.\r\n", "submit_date": "2003-08-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "639", "doc-id": "RFC3217", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.4", "orig_text": " This section contains a RC2 Key Wrap example. Intermediate values\r\n corresponding to the named items in section 4.1 are given in\r\n hexadecimal.", "correct_text": " This section contains a RC2 Key Wrap example. Intermediate values\r\n corresponding to the named items in section 4.1 are given in\r\n hexadecimal. In this example, the effective key length parameter for\r\n the RC2 algorithm should be 40 bits.\r\n\r\n==========================================\r\n\r\nRC2 Effective Key Bits: 40\r\n\r\nCEK is (16 bytes):\r\n b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9\r\n\r\nLENGTH is: 16\r\n\r\nLCEK is (17 bytes):\r\n 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4\r\n d9\r\n\r\nPAD is (7 bytes):\r\n 48 45 cc e7 fd 12 50\r\n\r\nLCEKPAD is (24 bytes):\r\n 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4\r\n d9 48 45 cc e7 fd 12 50\r\n\r\nSHA-1 Digest is (20 bytes):\r\n 0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98\r\n 7e ca 48 06\r\n\r\nICV is (8 bytes):\r\n 0a 6f f1 9f db 40 49 88\r\n\r\nLCEKPADICV is (32 bytes):\r\n 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4\r\n d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88\r\n\r\nIV is (8 bytes):\r\n c7 d9 00 59 b2 9e 97 f7\r\n\r\nKEK (16 bytes):\r\n fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05\r\n\r\nTEMP1 (32 bytes):\r\n a0 1d a2 59 37 93 12 60 e4 8c 55 f5 04 ce 70 b8\r\n ac 8c d7 9e ff 8e 99 32 9f a9 8a 07 a3 1f f7 a7\r\n\r\nTEMP2 (40 bytes):\r\n c7 d9 00 59 b2 9e 97 f7 a0 1d a2 59 37 93 12 60\r\n e4 8c 55 f5 04 ce 70 b8 ac 8c d7 9e ff 8e 99 32\r\n 9f a9 8a 07 a3 1f f7 a7\r\n\r\nTEMP3 (40 bytes):\r\n a7 f7 1f a3 07 8a a9 9f 32 99 8e ff 9e d7 8c ac\r\n b8 70 ce 04 f5 55 8c e4 60 12 93 37 59 a2 1d a0\r\n f7 97 9e b2 59 00 d9 c7\r\n\r\nFinalIV (8 bytes):\r\n 4a dd a2 2c 79 e8 21 05\r\n\r\nKEK (16 bytes):\r\n fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05\r\n\r\nRESULT (40 bytes):\r\n 70 e6 99 fb 57 01 f7 83 33 30 fb 71 e8 7c 85 a4\r\n 20 bd c9 9a f0 5d 22 af 5a 0e 48 d3 5f 31 38 98\r\n 6c ba af b4 b2 8d 4f 35\r\n\r\n==========================================\r\n\r\nRC2 Effective Key Bits: 128\r\n\r\nCEK is (16 bytes):\r\n b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4 d9\r\n\r\nLENGTH is: 16\r\n\r\nLCEK is (17 bytes):\r\n 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4\r\n d9\r\n\r\nPAD is (7 bytes):\r\n 48 45 cc e7 fd 12 50\r\n\r\nLCEKPAD is (24 bytes):\r\n 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4\r\n d9 48 45 cc e7 fd 12 50\r\n\r\nSHA-1 Digest is (20 bytes):\r\n 0a 6f f1 9f db 40 49 88 a2 fa ee 2e 53 37 12 98\r\n 7e ca 48 06\r\n\r\nICV is (8 bytes):\r\n 0a 6f f1 9f db 40 49 88\r\n\r\nLCEKPADICV is (32 bytes):\r\n 10 b7 0a 25 fb c9 d8 6a 86 05 0c e0 d7 11 ea d4\r\n d9 48 45 cc e7 fd 12 50 0a 6f f1 9f db 40 49 88\r\n\r\nIV is (8 bytes):\r\n c7 d9 00 59 b2 9e 97 f7\r\n\r\nKEK (16 bytes):\r\n fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05\r\n\r\nTEMP1 (32 bytes):\r\n 03 5e 97 2a b1 5c c4 c9 c4 a0 3d ba a3 5a 21 66\r\n 67 e4 3e bc a2 67 46 ae 86 08 db c8 9e 64 ca 29\r\n\r\nTEMP2 (40 bytes):\r\n c7 d9 00 59 b2 9e 97 f7 03 5e 97 2a b1 5c c4 c9\r\n c4 a0 3d ba a3 5a 21 66 67 e4 3e bc a2 67 46 ae\r\n 86 08 db c8 9e 64 ca 29\r\n\r\nTEMP3 (40 bytes):\r\n 29 ca 64 9e c8 db 08 86 ae 46 67 a2 bc 3e e4 67\r\n 66 21 5a a3 ba 3d a0 c4 c9 c4 5c b1 2a 97 5e 03\r\n f7 97 9e b2 59 00 d9 c7\r\n\r\nFinalIV (8 bytes):\r\n 4a dd a2 2c 79 e8 21 05\r\n\r\nKEK (16 bytes):\r\n fd 04 fd 08 06 07 07 fb 00 03 fe ff fd 02 fe 05\r\n\r\nRESULT (40 bytes):\r\n f4 d8 02 1c 1e a4 63 d2 17 a9 eb 69 29 ff a5 77\r\n 36 d3 e2 03 86 c9 09 93 83 5b 4b e4 ad 8d 8a 1b\r\n c6 3b 25 de 2b f7 79 93\r\n", "notes": "The text is silent about the RC2 parameter that indicates the effective key size. This errata resolves the ambiguity.\r\n\r\nTo aid implementors, this errata includes two examples. The first one matches section 4.4 and uses a 40-bit effective key size. The second one uses a 128-bit effective key size. Many thanks to Peter Yee for generating the examples and Blake Ramsdell for checking them.", "submit_date": "2007-10-28", "submitter_name": "Russ Housley", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "640", "doc-id": "RFC2445", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2", "orig_text": "DESCRIPTION;ALTREP=\"http://www.wiz.org\":The Fall'98 Wild Wizards\r\n Conference - - Las Vegas, NV, USA", "correct_text": "DESCRIPTION;ALTREP=\"http://www.wiz.org\":The Fall'98 Wild Wizards\r\n Conference - - Las Vegas\\, NV\\, USA", "notes": "", "submit_date": "2004-01-07", "submitter_name": "Dave Flater", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "641", "doc-id": "RFC2445", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2.1", "orig_text": "DESCRIPTION;ALTREP=\"CID:\":Project\r\nXYZ Review Meeting will include the following agenda items: (a)\r\nMarket Overview, (b) Finances, (c) Project Management", "correct_text": "DESCRIPTION;ALTREP=\"CID:\":Project\r\nXYZ Review Meeting will include the following agenda items: (a)\r\nMarket Overview\\, (b) Finances\\, (c) Project Management\r\n", "notes": "\r\n\r\n\r\n\r\n\r\n \r\n", "submit_date": "2004-01-07", "submitter_name": "Dave Flater", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "642", "doc-id": "RFC2445", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.8.1.7", "orig_text": "LOCATION:Conference Room - F123, Bldg. 002\r\n\r\nLOCATION;ALTREP=\"http://xyzcorp.com/conf-rooms/f123.vcf\":\r\nConference Room - F123, Bldg. 002\r\n", "correct_text": "LOCATION:Conference Room - F123\\, Bldg. 002\r\n\r\nLOCATION;ALTREP=\"http://xyzcorp.com/conf-rooms/f123.vcf\":\r\nConference Room - F123\\, Bldg. 002\r\n", "notes": "", "submit_date": "2004-01-07", "submitter_name": "Dave Flater", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "643", "doc-id": "RFC2445", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": "DESCRIPTION:Networld+Interop Conference\r\nand Exhibit\\nAtlanta World Congress Center\\n\r\nAtlanta, Georgia END:VEVENT END:VCALENDAR\r\n", "correct_text": "DESCRIPTION:Networld+Interop Conference\r\nand Exhibit\\nAtlanta World Congress Center\\n\r\nAtlanta\\, Georgia END:VEVENT END:VCALENDAR\r\n", "notes": "", "submit_date": "2004-01-07", "submitter_name": "Dave Flater", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "644", "doc-id": "RFC2445", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": "CATEGORY:Project Report, XYZ, Weekly Meeting\r\nDESCRIPTION:Project xyz Review Meeting Minutes\\n\r\nAgenda\\n1. Review of project version 1.0 requirements.\\n2.\r\nDefinition\r\nof project processes.\\n3. Review of project schedule.\\n\r\nParticipants: John Smith, Jane Doe, Jim Dandy\\n-It was", "correct_text": "CATEGORIES:Project Report,XYZ,Weekly Meeting\r\nDESCRIPTION:Project xyz Review Meeting Minutes\\n\r\nAgenda\\n1. Review of project version 1.0 requirements.\\n2.\r\nDefinition of project processes.\\n3. Review of project schedule.\\n\r\nParticipants: John Smith\\, Jane Doe\\, Jim Dandy\\n-It was\r\n", "notes": "The following change addresses the escaping of commas and two\r\nunrelated issues: the spurious CATEGORY property and a line wrapping\r\nerror.", "submit_date": "2004-01-07", "submitter_name": "Dave Flater", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "645", "doc-id": "RFC2557", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "9.2", "orig_text": "Content-Type: multipart/related; boundary=\"boundary-example\";\r\n type=\"text/html\"; start=\"\"\r\n\r\n--boundary-example\r\nContent-Type: text/html;charset=\"US-ASCII\"\r\nContent-ID: ", "correct_text": "Content-Type: multipart/related; boundary=\"boundary-example\";\r\n type=\"text/html\"; start=\"\"\r\n\r\n--boundary-example\r\nContent-Type: text/html;charset=\"US-ASCII\"\r\nContent-ID: ", "notes": "\r\n\r\n", "submit_date": "2002-01-21", "submitter_name": "Bruce Lilly", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4713", "doc-id": "RFC6184", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "8.1", "orig_text": "profile-level-id:\r\n A base16 [7] (hexadecimal) representation of the following\r\n three bytes in the sequence parameter", "correct_text": "profile-level-id:\r\n A base16 [7] (hexadecimal) representation of the following\r\n six bytes in the sequence parameter", "notes": "profile-level-id is composed of three 2-byte length fields.\n --VERIFIER NOTES-- \nThe original text is correct; 3 bytes in the binary representation become 6 text characters in base16. ", "submit_date": "2016-06-17", "submitter_name": "I\u00f1aki Baz Castillo", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2023-11-07 09:13:01"}, {"errata_id": "652", "doc-id": "RFC2616", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.4", "orig_text": "4.If the message uses the media type \"multipart/byteranges\", and the\r\n ransfer-length is not otherwise specified, then this self-\r\n elimiting media type defines the transfer-length. This media type\r\n UST NOT be used unless the sender knows that the recipient can arse\r\n it; the presence in a request of a Range header with ultiple byte-\r\n range specifiers from a 1.1 client implies that the lient can parse\r\n multipart/byteranges responses.", "correct_text": "4.If the message uses the media type \"multipart/byteranges\", and the\r\n Transfer-length is not otherwise specified, then this self-\r\n delimiting media type defines the transfer-length. This media type\r\n MUST NOT be used unless the sender knows that the recipient can parse\r\n it; the presence in a request of a Range header with multiple byte-\r\n range specifiers from a 1.1 client implies that the client can parse\r\n multipart/byteranges responses.", "notes": "Missing the first character of 6 words.", "submit_date": "2000-12-23", "submitter_name": "Justin Erenkrantz", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "653", "doc-id": "RFC2616", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "1.3", "orig_text": "Each of these representations is termed a `varriant'.", "correct_text": "Each of these representations is termed a `variant'.\r\n\r\n", "notes": "", "submit_date": "2000-12-23", "submitter_name": "Justin Erenkrantz", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "655", "doc-id": "RFC2625", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.2", "orig_text": " 1. This is REQUIRED for FC-4 (IP and ARP) packets\r\n\r\n - Routing bits of R_CTL field MUST indicate Device Data\r\n frames (0000)\r\n - Information Category of R_CTL field MUST indicate\r\n Unsolicited Data (0100)", "correct_text": " 1. This is REQUIRED for FC-4 (IP and ARP) packets\r\n\r\n - Routing bits of R_CTL field MUST indicate Device Data\r\n frames (0000)\r\n - Information Category of R_CTL field MUST indicate\r\n Unsolicited Data (0100)\r\n \r\n This does not apply to FARP-REQ and FARP-REPLY.", "notes": "Add a blank line and the sentence:\r\nThis does not apply to FARP-REQ and FARP-REPLY.\r\nindented as shown so that it applies to both bulleted items.", "submit_date": "2003-07-21", "submitter_name": "Elizabeth G. Rodriguez", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "656", "doc-id": "RFC2625", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "E.4.2", "orig_text": " Code Points for FC Frame with FARP-REQ Command for MATCH_WW_PN_NN\r\n +---+----------------+----------------+----------------+------------+\r\n |Wrd| <31:24> | <23:16> | <15:08> | <07:00> |\r\n +---+----------------+----------------+----------------+------------+\r\n | 0 | 0x04 | D_ID = |\r\n | | | 0xFF 0xFF 0xFF |\r\n +---+----------------+----------------+----------------+------------+\r\n | 1 | 0x00 | S_ID |\r\n +---+----------------+----------------+----------------+------------+\r\n | 2 | 0x05 | F_CTL |\r\n +---+----------------+----------------+----------------+------------+\r\n | 3 | SEQ_ID | 0x20 | SEQ_CNT |\r\n +---+----------------+----------------+----------------+------------+\r\n\r\n", "correct_text": " Code Points for FC Frame with FARP-REQ Command for MATCH_WW_PN_NN\r\n +---+----------------+----------------+----------------+------------+\r\n |Wrd| <31:24> | <23:16> | <15:08> | <07:00> |\r\n +---+----------------+----------------+----------------+------------+\r\n | 0 | 0x22 | D_ID = |\r\n | | | 0xFF 0xFF 0xFF |\r\n +---+----------------+----------------+----------------+------------+\r\n | 1 | 0x00 | S_ID |\r\n +---+----------------+----------------+----------------+------------+\r\n | 2 | 0x01 | F_CTL |\r\n +---+----------------+----------------+----------------+------------+\r\n | 3 | SEQ_ID | 0x00 | SEQ_CNT |\r\n +---+----------------+----------------+----------------+------------+", "notes": "This embodies three changes:\r\n- R_CTL (word 0, bits 31:24) should be 0x22, not 0x04\r\n- TYPE (word 2, bits 31:24) should be 0x01, not 0x05\r\n- DF_CTL (word 3, bits 23:16) should be 0x00, not 0x20\r\n", "submit_date": "2003-07-21", "submitter_name": "Elizabeth G. Rodriguez", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "674", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1.1.1", "orig_text": "Normally, the response to EHLO will be a multiline reply. Each line\r\nof the response contains a keyword and, optionally, one or more\r\nparameters. Following the normal syntax for multiline replies, these\r\nkeyworks follow the code (250) and a hyphen for all but the last\r\n^^^^^^^^", "correct_text": "Normally, the response to EHLO will be a multiline reply. Each line\r\nof the response contains a keyword and, optionally, one or more\r\nparameters. Following the normal syntax for multiline replies, these\r\nkeywords follow the code (250) and a hyphen for all but the last\r\n", "notes": "Should be \"keywords\".\r\n", "submit_date": "2004-01-12", "submitter_name": "Vincent Lefevre", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "675", "doc-id": "RFC4368", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": " [...]. Note that mplsLcAtmStdUnlabTrafVci and mplsLcAtmStdCtrlVci\r\n MUST not be equal; nor should mplsLcAtmStdCtrlVpi or\r\n mplsLcAtmStdUnlabTrafVpi be equal.\r\n", "correct_text": " Note that the VPI/VCI pair used for unlabeled traffic \r\n (mplsLcAtmStdUnlabTrafVpi, mplsLcAtmStdUnlabTrafVci) MUST NOT equal\r\n the VPI/VIC pair used for control traffic (mplsLcAtmStdCtrlVpi,\r\n mplsLcAtmStdCtrlVci).\r\n", "notes": "The (Vpi, Vci) - *pairs* must not be equal for every\r\nmplsLcAtmStdInterfaceConfEntry.", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "676", "doc-id": "RFC4377", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1", "orig_text": " Furthermore, the automation of path liveliness is desired in cases\r\n where large numbers of LSPs might be tested. [...]", "correct_text": "| Furthermore, the automation of path liveliness testing is desired in\r\n cases where large numbers of LSPs might be tested. [...]", "notes": "Fix word omission. Insert \"testing\"\r\n", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "677", "doc-id": "RFC4377", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.11.1", "orig_text": " (1) At an ingress LSR, accounting of traffic through LSPs that\r\n| begin at each egress in question.\r\n ^^^^^\r\n\r\n (2) At an intermediate LSR, accounting of traffic through LSPs for\r\n| each pair of ingress to egress.\r\n ^^ \r\n v\r\n| (3) At egress LSR, accounting of traffic through LSPs for each\r\n ingress.", "correct_text": " (1) At an ingress LSR, accounting of traffic through LSPs that\r\n| end at each egress in question.\r\n\r\n (2) At an intermediate LSR, accounting of traffic through LSPs for\r\n| each pair of ingress and egress.\r\n\r\n| (3) At an egress LSR, accounting of traffic through LSPs for each\r\n ingress.", "notes": "Fix wrong wording in bullet (1) [s/begin/end/]\r\n\r\nMinor typos in bullets (2) and (3).\r\n", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2376", "doc-id": "RFC4650", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3", "orig_text": "Figure 1 in Section 3, on page 8, says:\r\n\r\n Initiator Responder\r\n\r\n I_message = HDR, T, RAND, [IDi], IDr,\r\n {SP}, DHi, KEMAC\r\n -----------------------> R_message = HDR, T,\r\n [IDr], IDi, DHr,\r\n DHi, KEMAC\r\n <----------------------\r\n\r\n\r\n", "correct_text": "To avoid optional empty protocol elements,\r\nit should perhaps better say:\r\n\r\n Initiator Responder\r\n\r\n| I_message = HDR, T, RAND, [IDi,] IDr,\r\n {SP}, DHi, KEMAC\r\n -----------------------> R_message = HDR, T,\r\n| [IDr,] IDi, DHr,\r\n DHi, KEMAC\r\n <----------------------\r\n\r\n\r\n\r\n Similar corrections would be suitable in Section 3.1 for Figure 2,\r\non page 10.\r\n", "notes": "error in message syntax notation:\r\n", "submit_date": "2006-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "657", "doc-id": "RFC2625", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "E.4.2", "orig_text": " Code Points for FC Frame with FARP-REPLY Command\r\n +---+----------------+----------------+----------------+------------+\r\n |Wrd| <31:24> | <23:16> | <15:08> | <07:00> |\r\n +---+----------------+----------------+----------------+------------+\r\n | 0 | 0x04 | D_ID |\r\n +---+----------------+----------------+----------------+------------+\r\n | 1 | 0x00 | S_ID |\r\n +---+----------------+----------------+----------------+------------+\r\n | 2 | 0x05 | F_CTL |\r\n +---+----------------+----------------+----------------+------------+\r\n | 3 | SEQ_ID | 0x20 | SEQ_CNT |\r\n +---+----------------+----------------+----------------+------------+", "correct_text": " Code Points for FC Frame with FARP-REPLY Command\r\n +---+----------------+----------------+----------------+------------+\r\n |Wrd| <31:24> | <23:16> | <15:08> | <07:00> |\r\n +---+----------------+----------------+----------------+------------+\r\n | 0 | 0x23 | D_ID |\r\n +---+----------------+----------------+----------------+------------+\r\n | 1 | 0x00 | S_ID |\r\n +---+----------------+----------------+----------------+------------+\r\n | 2 | 0x01 | F_CTL |\r\n +---+----------------+----------------+----------------+------------+\r\n | 3 | SEQ_ID | 0x00 | SEQ_CNT |\r\n +---+----------------+----------------+----------------+------------+", "notes": "This embodies three changes:\r\n- R_CTL (word 0, bits 31:24) should be 0x23, not 0x04\r\n- TYPE (word 2, bits 31:24) should be 0x01, not 0x05\r\n- DF_CTL (word 3, bits 23:16) should be 0x00, not 0x20\r\n", "submit_date": "2003-07-21", "submitter_name": "Elizabeth G. Rodriguez", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "658", "doc-id": "RFC2630", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Reference", "orig_text": "NEWPKCS#1 Kaliski, B., \"PKCS #1: RSA Encryption, Version 2.0\",\r\n RFC 2347, October 1998.", "correct_text": "NEWPKCS#1 Kaliski, B., \"PKCS #1: RSA Encryption, Version 2.0\",\r\n RFC 2437, October 1998.\r\n", "notes": "", "submit_date": "2000-12-26", "submitter_name": "Joseph Baran", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "659", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.3.3", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 2 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Interface MTU | 0 |0|0|0|0|0|I|M|MS\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | DD sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- -+\r\n | |\r\n +- An LSA Header -+\r\n | |\r\n +- -+\r\n | |\r\n +- -+\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n\r\n", "correct_text": "\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 2 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Interface MTU | 0 |0|0|0|0|0|I|M|MS\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | DD sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- -+\r\n | |\r\n +- An LSA Header -+\r\n | |\r\n +- -+\r\n | |\r\n +- -+\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "5007", "doc-id": "RFC5309", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.3", "orig_text": "For the ARP implementation (which checks that the subnet of the source \r\naddress of the ARP request matches the local interface address), \r\nthis check needs to be relaxed for the unnumbered p2p-over-lan circuits.", "correct_text": "For the ARP implementation (which checks that the subnet of the source \r\naddress of the ARP request matches the local interface address), \r\nthis check needs to be relaxed for the p2p-over-lan circuits \r\n(both numbered and unnumbered).", "notes": "Consider the following situation: \r\n1.\tTwo routers, R1 and R2, are connected by a physical P2P Ethernet link\r\n2.\tOSPFv2 is enabled on the interfaces representing the endpoints of this link. \r\n3. From the OSPF POV these interfaces:\r\no\tAre configured as P2P\r\no\tBelong to the same area\r\no\tAre assigned with IP addresses and subnet masks yielding different subnets\r\n4. ARP check mentioned in the problematic text is not relaxed.\r\n\r\nUnder this conditions:\r\n-Both R1 and R2 will accept Hello messages sent by the other router \r\n(becase it ignores subnet in Hello messages received via P2P interfaces)\r\n- Adjacency between R1 and R2 will progress to FULL state (because all OSPFv2 messages \r\nwill be sent with AllSPFRouters multicast IPv4 address)\r\n- Unicast traffic sent by R1 to R2 (and vice versa) will be blackholed because ARP \r\nwill not resolve addresses assigned to the corresponding interfaces.\n --VERIFIER NOTES-- \nRFC 5309 introduced the possibility of supporting an unnumbered configuration on a LAN. Statements in this RFC regarding ARP concerns are therefore deliberately limited to this new configuration.\r\n\r\nFor IS-IS, RFC 3787 Section 10 discusses concerns regarding mismatched subnets on numbered links.\r\n\r\nFor OSPF it is well known that there are some existing implementations which have supported mismatched subnets for many years.\r\n\r\nAny concerns with ARP behavior in support of mismatched subnets on numbered LANs is out of scope of RFC 5309.\r\n\r\n[https://mailarchive.ietf.org/arch/msg/isis-wg/aCFWc8KuE8xEy0-qIrN63odct1o/?qid=623f2d68947e2ec849fb2e2a7f2e6242]", "submit_date": "2017-04-30", "submitter_name": "Alexander Vainshtein", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "678", "doc-id": "RFC3261", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "25.1", "orig_text": "On page 220, it says \"The TEXT-UTF8-TRIM rule is used for descriptive\r\nfield contents that are n t quoted strings, where leading and trailing\r\nLWS is not meaningful.\" (And no, I'm not talking about the \"n t\"\r\ntypo.) The rule for TEXT-UTF8-TRIM is\r\n\r\n TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)\r\n TEXT-UTF8char = %x21-7E / UTF8-NONASCII\r\n\r\nwhich pretty clearly says that the final character of TEXT-UTF8-TRIM\r\ncannot be whitespace. TEXT-UTF8-TRIM appears only as the value of a\r\nheader field, and the rule for message-header does not generate\r\ntrailing whitespace either.\r\n\r\nSo the text talks about trailing whitespace, which seems reasonable\r\nbecause whitespace is allowed in many other places, but the grammar\r\ndoes not allow it. Was trailing whitespace intended?", "correct_text": "[not submitted]", "notes": "from pending", "submit_date": "2006-08-14", "submitter_name": "Matthew S. Harris", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "679", "doc-id": "RFC1001", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "I found something strange in rfc1001\r\nMaybe my code is wrong, but it returns \"Tge NetBIOS tame\"\r\ninstead of \"The NetBIOS name\" when I try to encode\r\nFEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF\r\n\r\n\"For example, the NetBIOS name \"The NetBIOS name\" in the NetBIOS scope\r\n\"SCOPE.ID.COM\" would be represented at level one by the ASCII\r\n\r\ncharacter string:\r\n\r\nFEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM\"", "correct_text": "[not submitted]", "notes": "from pending", "submit_date": "2002-02-25", "submitter_name": "Anvish", "verifier_id": "", "verifier_name": "ron bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "683", "doc-id": "RFC1195", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "3.3", "orig_text": "In chapter '3.3 Addressing Routers in ISIS Packets' the RFC describes a\r\nstandard procedure\r\nfor deriving NSAP-addresses for IS in IP-only environments. However, the\r\nDFI as well as the AA\r\nare defined to be 'xx' and 'xx xx xx' respectively, which represents\r\nneither a valid decimal nor\r\nhexadecimal value.", "correct_text": "[not submitted]", "notes": "from pending", "submit_date": "2003-03-04", "submitter_name": "Joerg Ammon", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "685", "doc-id": "RFC4307", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.1.4", "orig_text": "Transfer Type 2 Algorithms are pseudo-random functions used to\r\ngenerate random values when needed.", "correct_text": "Transform Type 2 Algorithms are pseudo-random functions used to\r\ngenerate random values when needed.", "notes": "from pending", "submit_date": "2006-02-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "686", "doc-id": "RFC3461", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": " The \"addr-type\" portion MUST be an IANA-registered electronic mail\r\n address-type (as defined in [3]), while the \"xtext\" portion contains\r\n an encoded representation of the original recipient address using the\r\n rules in section 5 of this document. The entire ORCPT parameter MAY\r\n be up to 500 characters in length.", "correct_text": " The \"addr-type\" portion MUST be an IANA-registered electronic mail\r\n address-type (as defined in [3]), while the \"xtext\" portion contains\r\n an encoded representation of the original recipient address using the\r\n rules in section 4 of this document. The entire ORCPT parameter MAY\r\n ^\r\n be up to 500 characters in length.", "notes": "xtext encoding is described in Section 4, not in Section 5", "submit_date": "2004-08-10", "submitter_name": "Valdis Kletniek", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "687", "doc-id": "RFC4307", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.1.5", "orig_text": "Transfer Type 3 Algorithms are Integrity algorithms used to protect\r\ndata against tampering.", "correct_text": "Transform Type 3 Algorithms are Integrity algorithms used to protect\r\ndata against tampering.", "notes": "from pending", "submit_date": "2006-02-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "688", "doc-id": "RFC4307", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "Like other contemporary RFCs, RFC 4307 seems to have been infected\r\nby a common 'virus'. In the case or RFC 4307, the first sentence of the Introduction has been inadvertantly split by a spurious blank line.", "correct_text": "", "notes": "from pending", "submit_date": "2006-02-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "660", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.3.4", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 3 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | LS type |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 3 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | LS type |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "661", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.3.5", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 4 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | # LSAs |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- +-+\r\n | LSAs |\r\n +- +-+\r\n | ... |\r\n\r\n", "correct_text": "\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 4 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | # LSAs |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- +-+\r\n | LSAs |\r\n +- +-+\r\n | ... |\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2377", "doc-id": "RFC4650", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "\r\n\r\n(6) missing comma, causing possible mis-interpretation\r\n\r\nThe last sentence of Section 3, at the bottom of page 9, says:\r\n\r\n [...]. The HMAC SHALL be\r\n computed over the entire message, excluding the MAC field using\r\n auth_key; see also section 4.2.", "correct_text": "It should say:\r\n\r\n [...]. The HMAC SHALL be\r\n| computed over the entire message, excluding the MAC field, using\r\n auth_key; see also section 4.2.\r\n\r\nor perhaps even better and clearer:\r\n\r\n [...]. The HMAC SHALL be\r\n| computed (using auth_key) over the entire message excluding the MAC\r\n| field; see also section 4.2.", "notes": "from pending", "submit_date": "2006-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "710", "doc-id": "RFC3281", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.3.2", "orig_text": " Note: [X.509-2000] defines the extension syntax as a \"SEQUENCE OF\r\n Targets\". Conforming AC issuer implementations MUST only produce one\r\n \"Targets\" element. Confirming AC users MUST be able to accept a\r\n \"SEQUENCE OF Targets\". If more than one Targets element is found in\r\n an AC, the extension MUST be treated as if all Target elements had\r\n been found within one Targets element.", "correct_text": " Note: [X.509-2000] defines the extension syntax as a \"SEQUENCE OF\r\n Targets\". Conforming AC issuer implementations MUST only produce one\r\n \"Targets\" element. Conforming AC users MUST be able to accept a\r\n \"SEQUENCE OF Targets\". If more than one Targets element is found in\r\n an AC, the extension MUST be treated as if all Target elements had\r\n been found within one Targets element.", "notes": "Confirming -> Conforming", "submit_date": "2006-12-20", "submitter_name": "Gidon Moont", "verifier_id": "", "verifier_name": "Stephen Farrell", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "711", "doc-id": "RFC3965", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "a) Change the first sentence of section 2.1.3, on page 4, from:\r\n\r\n \"An offramp gateway that operate as an MTA serving multiple users\r\n SHOULD use SMTP;\" ...\r\n\r\nto:\r\n\r\n| \"An offramp gateway that operates as an MTA serving multiple users\r\n SHOULD use SMTP;\" ...\r\n\r\nb) Change the first sentence of section 2.2.4, on page 4, from:\r\n\r\n \"A single multi-page document SHOULD be sent as a single multi- page\r\n TIFF file, even though recipients MUST process multipart/mixed\r\n containing multiple TIFF files.\"\r\n\r\nto:\r\n\r\n| \"A single multi-page document SHOULD be sent as a single multi-page\r\n TIFF file, even though recipients MUST process multipart/mixed\r\n containing multiple TIFF files.\"\r\n\r\nc) Change section 5.1. on page 6 from:\r\n\r\n \"This specification is based on use of existing Internet mail. To\r\n maintain interoperability with Internet mail, any security to be\r\n provided should be part of the of the Internet security\r\n infrastructure, rather than a new mechanism or some other mechanism\r\n outside of the Internet infrastructure.\"\r\n\r\nto:\r\n\r\n| \"This specification is based on the use of existing Internet mail.\r\n To maintain interoperability with Internet mail, any security to be\r\n| provided should be part of the Internet security infrastructure,\r\n rather than a new mechanism or some other mechanism outside of the\r\n Internet infrastructure.\"\r\n\r\nd) Change the final sentence of section 5.2, on page 6, from:\r\n\r\n ... \"This section reviews relevant concerns about\r\n Internet mail for IFax environments, as well as considering the\r\n potential problems which can result of integrating the existing G3Fax\r\n service with Internet mail.\"\r\n\r\nto:\r\n ... \"This section reviews relevant concerns about\r\n Internet mail for IFax environments, as well as considering the\r\n| potential problems which can result from integrating the existing\r\n G3Fax service with Internet mail.\"\r\n\r\ne) Change the first paragraph of section 5.2.1, on page 6, from:\r\n\r\n \"The actual sender of the message might not be the same as that\r\n specified in the Sender or From fields of the message content headers\r\n or the MAIL FROM address from the SMTP envelope.\"\r\n\r\nto:\r\n\r\n \"The actual sender of the message might not be the same as that\r\n specified in the Sender or From fields of the message content headers\r\n| or the MAIL FROM address in the SMTP envelope.\"\r\n\r\nf) Change the second-to-last paragraph of section 5.2.2, on page 7,\r\nfrom:\r\n\r\n \"Originator authentication entails the use of weak or strong\r\n mechanisms, such as cleartext keywords or encryption-based\r\n data-signing, respectively, to determine and validate the identify\r\n of the sender and assess permissions accordingly.\"\r\n\r\nto:\r\n\r\n \"Originator authentication entails the use of weak or strong\r\n mechanisms, such as cleartext keywords or encryption-based\r\n| data-signing, respectively, to determine and validate the identity\r\n of the sender and assess permissions accordingly.\"\r\n\r\ng) Change the first sentence of the last paragraph of section 5.2.3,\r\non page 8, from:\r\n\r\n \"Typically authorization needs to be associated to specific senders\r\n and specific messages, in order to prevent a \"replay\" attack which\r\n causes and earlier authorization to enable a later dial-out by a\r\n different (and unauthorized) sender.\" ...\r\n\r\nto:\r\n\r\n| \"Typically authorization needs to be associated with specific senders\r\n and specific messages, in order to prevent a \"replay\" attack which\r\n| causes an earlier authorization to enable a later dial-out by a\r\n different (and unauthorized) sender.\" ...", "correct_text": "[see above]", "notes": "from pending ", "submit_date": "2005-01-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "724", "doc-id": "RFC4758", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix B.4 says:", "orig_text": " ", "correct_text": " ", "notes": "from pending", "submit_date": "2007-01-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Magnus Nystrom", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "725", "doc-id": "RFC4758", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix D says:", "orig_text": "n = ROUND( dsLen / bLen )", "correct_text": "n = CEILING( dsLen / bLen )", "notes": "Appendix D repeatedly uses the \"ROUND\" function where in fact it\r\nshould use the \"CEILING function (3 instances: on pp. 49, 51, and 52).\r\n\r\nfrom pending", "submit_date": "2007-01-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Magnus Nystrom", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "662", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.3.6", "orig_text": "\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 5 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- -+\r\n | |\r\n +- An LSA Header -+\r\n | |\r\n +- -+\r\n | |\r\n +- -+\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n\r\n", "correct_text": "\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 3 | 5 | Packet length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Area ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Checksum | Instance ID | 0 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- -+\r\n | |\r\n +- An LSA Header -+\r\n | |\r\n +- -+\r\n | |\r\n +- -+\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "663", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.2", "orig_text": "\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age | LS type |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n", "correct_text": "\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age | LS type |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "664", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.3", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 1 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 |W|V|E|B| Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Type | 0 | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Type | 0 | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n\r\n\r\n\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 1 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 |W|V|E|B| Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Type | 0 | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Type | 0 | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor Interface ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Neighbor Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "665", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.4", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 2 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Attached Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 2 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Attached Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "680", "doc-id": "RFC2834", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.3", "orig_text": "On page 19 :\r\n\r\nData sizes and field meaning:\r\n ar$hrd 16 bits Hardware type\r\n ar$pro 16 bits Protocol type of the protocol fields below\r\n ar$op 16 bits Operation code (request, reply, or NAK)\r\n ar$pln 8 bits byte length of each protocol address\r\n ar$rhl 8 bits requester's HIPPI hardware address length (q)\r\n ar$thl 8 bits target's HIPPI hardware address length (x)\r\n ar$rpa 32 bits requester's protocol address\r\n ar$tpa 32 bits target's protocol address\r\n ar$rha qbytes requester's HIPPI Hardware address\r\n ar$tha xbytes target's HIPPI Hardware address\r\n\r\nOn page 20, there is :\r\n\r\nWhere :\r\n ar$hrd - SHALL contain 28. (HIPARP)\r\n ar$pro - SHALL contain the IP protocol code 2048 (decimal).\r\n ar$op - SHALL contain the operational value (decimal):\r\n 1 for HARP_REQUESTs\r\n 2 for HARP_REPLYs\r\n 8 for InHARP_REQUESTs\r\n 9 for InHARP_REPLYs\r\n 10 for HARP_NAK\r\n ar$pln - SHALL contain 4.\r\n ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW address \r\n ELSE, for HIPPI-6400, it SHALL contain 6.\r\n ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW address\r\n ELSE, for HIPPI-6400, it SHALL contain 6.\r\n ar$rha - in requests and NAKs it SHALL contain the requester's\r\n HW address. In replies it SHALL contain the target\r\n port's HW address.\r\n ar$rpa - in requests and NAKs it SHALL contain the requester's IP\r\n address if known, otherwise zero.\r\n In other replies it SHALL contain the target\r\n port's IP address.\r\n ar$tha - in requests and NAKs it SHALL contain the target's\r\n HW address if known, otherwise zero.\r\n In other replies it SHALL contain the requester's\r\n HW addressA.\r\n ar$tpa - in requests and NAKs it SHALL contain the\r\n target's IP address if known, otherwise zero.\r\n In other replies it SHALL contain the requester's\r\n IP address.", "correct_text": "On page 19 :\r\n\r\nData sizes and field meaning:\r\n ar$hrd 16 bits Hardware type\r\n ar$pro 16 bits Protocol type of the protocol fields below\r\n ar$op 16 bits Operation code (request, reply, or NAK)\r\n ar$pln 8 bits byte length of each protocol address\r\n ar$rhl 8 bits requester's HIPPI hardware address length (q)\r\n ar$thl 8 bits target's HIPPI hardware address length (x)\r\n ar$rpa 32 bits requester's protocol address\r\n ar$tpa 32 bits target's protocol address\r\n ar$rha qbytes requester's HIPPI Hardware address\r\n ar$tha xbytes target's HIPPI Hardware address\r\n\r\nOn page 20, there is :\r\n\r\nWhere :\r\n ar$hrd - SHALL contain 28. (HIPARP)\r\n ar$pro - SHALL contain the IP protocol code 2048 (decimal).\r\n ar$op - SHALL contain the operational value (decimal):\r\n 1 for HARP_REQUESTs\r\n 2 for HARP_REPLYs\r\n 8 for InHARP_REQUESTs\r\n 9 for InHARP_REPLYs\r\n 10 for HARP_NAK\r\n ar$pln - SHALL contain 4.\r\n ar$rhl - SHALL contain 10 IF this is a HIPPI-800 HW address\r\n ELSE, for HIPPI-6400, it SHALL contain 6.\r\n ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW address\r\n ELSE, for HIPPI-6400, it SHALL contain 6.\r\n ar$rha - in requests and NAKs it SHALL contain the requester's\r\n HW address. In replies it SHALL contain the target\r\n port's HW address.\r\n ar$rpa - in requests and NAKs it SHALL contain the requester's IP\r\n address if known, otherwise zero.\r\n In other replies it SHALL contain the target\r\n port's IP address.\r\n ar$tha - in requests and NAKs it SHALL contain the target's\r\n HW address if known, otherwise zero.\r\n In other replies it SHALL contain the requester's\r\n HW addressA.\r\n ar$tpa - in requests and NAKs it SHALL contain the\r\n target's IP address if known, otherwise zero.\r\n In other replies it SHALL contain the requester's\r\n IP address.", "notes": "The descriptive text references ar$rln rather than the correct ar$rhl.", "submit_date": "2002-03-24", "submitter_name": "Sebastian Kulpa", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "667", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.5", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 3 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | (0) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n ", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 3 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | (0) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "668", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.6", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 4 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Destination Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 4 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | 0 | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Destination Router ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "669", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.7", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|1|0| 5 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |E|F|T| Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | Referenced LS Type |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- -+\r\n | |\r\n +- Forwarding Address (Optional) -+\r\n | |\r\n +- -+\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | External Route Tag (Optional) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Referenced Link State ID (Optional) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|1|0| 5 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |E|F|T| Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | Referenced LS Type |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- -+ \r\n | |\r\n +- Forwarding Address (Optional) -+\r\n | |\r\n +- -+\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | External Route Tag (Optional) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Referenced Link State ID (Optional) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "671", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.8", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|0| 8 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Rtr Pri | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- -+\r\n | |\r\n +- Link-local Interface Address -+\r\n | |\r\n +- -+\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | # prefixes |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | (0) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | (0) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|0| 8 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Rtr Pri | Options |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | |\r\n +- -+\r\n | |\r\n +- Link-local Interface Address -+\r\n | |\r\n +- -+\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | # prefixes |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | (0) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | (0) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "672", "doc-id": "RFC2740", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.9", "orig_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 9 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | # prefixes | Referenced LS type |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Referenced Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Referenced Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n\r\n\r\n", "correct_text": " 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS age |0|0|1| 9 |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS sequence number |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | LS checksum | length |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | # prefixes | Referenced LS type |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Referenced Link State ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Referenced Advertising Router |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | PrefixLength | PrefixOptions | Metric |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Address Prefix |\r\n | ... |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n", "notes": "", "submit_date": "2002-01-17", "submitter_name": "John Moy", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "673", "doc-id": "RFC2821", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1.1.1", "orig_text": "available), the client SHOULD send an address literal (see section\r\n4.1.3), optionally followed by information that will help to identify\r\nthe client system. y The SMTP server identifies itself to the SMTP\r\n ^^^", "correct_text": "available), the client SHOULD send an address literal (see section\r\n4.1.3), optionally followed by information that will help to identify\r\nthe client system. The SMTP server identifies itself to the SMTP\r\n ", "notes": "The \"y\" should be removed.\r\n", "submit_date": "2004-01-12", "submitter_name": "Vincent Lefevre", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2378", "doc-id": "RFC4650", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "Extraneous (duplicate) word error:\r\n\r\nIn Section 4.1, the last sentence on page 11, says:\r\n\r\n Other defined next payload values defined in [2] SHALL not be applied\r\n to DHHMAC.", "correct_text": "It should say:\r\n\r\n| Other next payload values defined in [2] SHALL not be applied to\r\n DHHMAC.", "notes": "from pending", "submit_date": "2006-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "689", "doc-id": "RFC3886", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.3.5, 3.3.6, 3.3.7", "orig_text": "(on page 7):\r\n\r\n a) in section 3.3.5 replace:\r\n\r\n \"The Remote-MTA field is defined as in section Reference 2.3.5 of\r\n [RFC-DSN-STAT].\" ...\r\n ^^^^^^^^^^\r\n by:\r\n\r\n \"The Remote-MTA field is defined as in section 2.3.5 of\r\n [RFC-DSN-STAT].\" ...\r\n\r\n b) in section 3.3.6 replace:\r\n\r\n \"The Last-Attempt-Date field is defined as in section Reference 2.3.7\r\n of [RFC-DSN-STAT].\" ...\r\n ^^^^^^^^^^\r\n by:\r\n\r\n \"The Last-Attempt-Date field is defined as in section 2.3.7 of\r\n [RFC-DSN-STAT].\" ...\r\n\r\n c) in section 3.3.7 replace:\r\n\r\n \"The Will-Retry-Until field is defined as in section Reference 2.3.9\r\n of [RFC-DSN-STAT].\" ...\r\n ^^^^^^^^^^\r\n by:\r\n\r\n \"The Will-Retry-Until field is defined as in section 2.3.9 of\r\n [RFC-DSN-STAT].\" ...", "correct_text": "[see above]", "notes": "The first line of these sections seem to have inherited some\r\nundue editing history inserting the appropriate references;\r\nthe word \"Reference\" should be removed in every case.\r\n\r\nfrom pending", "submit_date": "2004-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "690", "doc-id": "RFC4307", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "On pages 3 and 4 of RFC 4307, the text in Section 3.1.3 through\r\nSection 3.1.5 contains three instances of the same typo,\r\ntalking about [algorithms of] \"Transfer Type \" , where it\r\nshould refer to [algorithms of] \"Transform Type \".", "correct_text": "", "notes": "typo breaking IPsec terminology\r\n\r\nfrom pending", "submit_date": "2006-02-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "691", "doc-id": "RFC3798", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "Appendix A", "orig_text": "(1) disposition types\r\n=====================\r\nThe dispositions \"denied\" and \"failed\" were removed from the\r\ndocument reflecting the lack of implementation or usage ...\r\n\r\n\r\nNow, the syntax production \"disposition-type\" in section 3.2.6. (on\r\npage 14) and section 7. (on mid-page 22) has been changed to read:\r\n\r\n disposition-type = \"displayed\" / \"deleted\"\r\n\r\nThis means that the RFC 2298 disposition types \"dispatched\" and\r\n\"processed\" have been removed from the syntax definitions as well!\r\n\r\nThus, either Appendix A lacks mentioning these removals OR these\r\nitems should not have been removed from the syntax definitions.\r\n\r\nNevertheless, all these disposition types removed from the syntax are\r\nmentioned at many places throughout RFC 3798:\r\n\r\no \"dispatched\" :\r\n\r\n - section 3.2.6. , final paragraph of the section on page 16\r\n - section 4. , third-to-last bullet on page 17\r\n - section 4. , first bullet on page 18\r\n\r\no \"processed\" :\r\n\r\n - section 4. , third-to-last bullet on page 17\r\n - section 4. , first bullet on page 18\r\n - section 5. , 4th paragraph on page 18\r\n\r\no \"denied\" :\r\n\r\n - section 2.1. , bottom of page 4\r\n - section 2.1. , end of 3rd paragraph on page 5\r\n - section 4. , third-to-last bullet on page 17\r\n - section 4. , first bullet on page 18\r\n - section 6.2. , end of first paragraph on page 19\r\n\r\no \"failed\" :\r\n\r\n - section 2.2. , middle of second-to-last paragraph on page 6\r\n - section 2.2. , middle of second paragraph on page 7 (twice)\r\n - section 2.2. , third paragraph on page 7 (twice)\r\n - section 3.2.7. , in 2nd text line, on page 16\r\n (mis-spelled \"failure\" there)\r\n - section 4. , third-to-last bullet on page 17\r\n - section 4. , first bullet on page 18\r\n\r\nAll these places in the text deal with the issue/sending/generation\r\nof MDNs with the named deprecated disposition types (it would be\r\nacceptable to talk about what to do with *received* such disposition\r\ntypes for backwards compatibility with RFC 2298) !\r\n", "correct_text": "[not submitted]", "notes": "from pending\n --VERIFIER NOTES-- \nClearly this document is a mess. The solution is to publish an RFC that cleans up the mess (and verifies that there is indeed consensus to remove the \"denied\" and \"failed\" dispositions), not to handle this via the errata process. ", "submit_date": "2004-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "692", "doc-id": "RFC3798", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Several", "orig_text": "(2) disposition modifiers\r\n=========================\r\n\r\n The disposition modifiers \"warning\", \"superseded\", \"expired\",\r\n \"mailbox-terminated\" have not seen actual implementation. They have\r\n been deleted from this document.\r\n\r\n\r\nAccordingly, the syntax production \"disposition-type\" in section 3.2.6.\r\n(on page 14) and section 7. (on mid-page 22) has been changed to read:\r\n\r\n disposition-modifier = \"error\" / disposition-modifier-extension\r\n\r\nNevertheless, one of these 'removed' modifiers disposition is\r\nmentioned in the text of RFC 3798:\r\n\r\no \"warning\" :\r\n\r\n - section 3.2.7. , 3rd line of text on page 16\r\n\r\n", "correct_text": "", "notes": "Alexey: The editors have this change in their editorial copy of -bis.", "submit_date": "2004-10-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "693", "doc-id": "RFC4255", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.1", "orig_text": "The RDATA for a SSHFP RR consists of an algorithm number, fingerprint\r\ntype and the fingerprint of the public host key.\r\n\r\n 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | algorithm | fp type | /", "correct_text": "[not submitted]", "notes": "Section 3.1 has a packet format picture, and the upper row of bit \r\nnumbers seems to have been shifted to the left.\r\n\r\nfrom pending", "submit_date": "2006-02-10", "submitter_name": "Sam Weiler", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "694", "doc-id": "RFC2911", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "13, Appendix B", "orig_text": "The top half (128 values) of each range (0x0n40 to 0x0nFF, for \r\nn = 0 to 5) is reserved for vendor use within each status code\r\nclass. ", "correct_text": "The top half (128 values) of each range (0x0n80 to 0x0nFF, for \r\nn = 0 to 5) is reserved for vendor use within each status code\r\nclass. ", "notes": "\r\n\r\n\r\n", "submit_date": "2002-07-17", "submitter_name": "Tom Hastings", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "6810", "doc-id": "RFC8707", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4", "orig_text": "In typical OAuth deployments the authorization sever is in a position\r\nto observe and track a significant amount of user and client behavior.", "correct_text": "In typical OAuth deployments, the authorization server is in a position\r\nto observe and track a significant amount of user and client behavior.", "notes": "1. typo: sever -> server\r\n2. I think we also need a comma after \"In typical OAuth deployments\" because it is an introductory phrase, but maybe a native English speaker can confirm.", "submit_date": "2022-01-05", "submitter_name": "Jan Goebel", "verifier_id": "", "verifier_name": "Roman Danyliw", "update_date": "2022-01-20 14:49:51"}, {"errata_id": "726", "doc-id": "RFC4326", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.1", "orig_text": "The most significant bit of the Length field carries the value of the \r\nDestination Address Absent Field, the D-bit", "correct_text": "The most significant bit of the first byte of the SNDU base header \r\ncarries the value of the Destination Address Absent Field, the D-bit\r\n", "notes": "- Length field description refers to a 16-bit value.\r\nSource: Bernhard Collini-Nocker, 15th February 2006", "submit_date": "2006-08-02", "submitter_name": "Gorry Fairhurst", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "727", "doc-id": "RFC4326", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "In Example A.2, it says:", "orig_text": "| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |", "correct_text": "| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0xB5 |", "notes": "- Misrepresentation of hex byte in example, Change /0x65/0xB5/\r\nSource: Karsten Siebert, 26th February 2006", "submit_date": "2006-08-02", "submitter_name": "Gorry Fairhurst", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "728", "doc-id": "RFC3666", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1", "orig_text": "F2 INVITE Alice -> Proxy1", "correct_text": "F2 INVITE NGW 1 -> Proxy1", "notes": "", "submit_date": "2005-01-11", "submitter_name": "Mani Devarajan", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2471", "doc-id": "RFC3315", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "17.1.3", "orig_text": "The client MUST ignore any Advertise message that includes a Status\r\nCode option containing the value NoAddrsAvail, with the exception\r\nthat the client MAY display the associated status message to the\r\nuser.", "correct_text": "The client MUST ignore any IAs in an Advertise message that includes \r\na Status Code option containing the value NoAddrsAvail, with the \r\nexception that the client MAY display the associated status message \r\nto the user.", "notes": "", "submit_date": "2010-08-17", "submitter_name": "Ole Troan", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "695", "doc-id": "RFC3468", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "The header says:", "orig_text": "Network Working Group L. Andersson\r\nRequest for Comments: 3468 Consultant\r\nCategory: Informational G. Swallow\r\n Cisco Systems\r\n February 2003", "correct_text": "Network Working Group L. Andersson\r\nRequest for Comments: 3468 Consultant\r\nUpdates: 3212, 3472, 3475, 3476 G. Swallow\r\nCategory: Informational Cisco Systems\r\n February 2003", "notes": "RFC3468 documents the MPLS WG's decision to ice CR-LDP. \r\nHowever, RFC3468 is not marked as updating RFC3212 (CR-LDP base spec) in the registry.\r\n\r\nThe RFCs updated by 3468 are:\r\n3212, 3472, 3475, 3476\r\n\r\n[Note that the RFC Editor index has been updated accordingly, but the document itself remains incorrect.]\r\n\r\nOriginally sent by Adrian Farrel.\r\n\r\nfrom pending", "submit_date": "2004-10-23", "submitter_name": "Alex Zinin", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "696", "doc-id": "RFC3031", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.20", "orig_text": "For example, a set of distinct address prefixes might all have the same\r\negress node, and label swapping might be used only to get the the traffic \r\nto the egress node. ", "correct_text": "For example, a set of distinct address prefixes might all have the same\r\negress node, and label swapping might be used only to get the traffic \r\nto the egress node. \r\n", "notes": "Notice the double 'the'.", "submit_date": "2005-03-01", "submitter_name": "John Kristoff", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "697", "doc-id": "RFC3056", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.3", "orig_text": "apply any security checks (see Section 8);", "correct_text": "apply any security checks (see Section 9);\r\n", "notes": "\r\n", "submit_date": "2002-11-20", "submitter_name": "Brian Carpenter", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "698", "doc-id": "RFC3926", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) On page 31, the Informative Reference \"[21]\" is inconsistent;\r\n author, title, and publication month / year match RFC 2047,\r\n *not* \"RFC 1521\" as stated there.\r\n\r\n(2) The first use of reference \"[21]\" appears on page 27, in the\r\n 10th line of the 2nd paragraph. There, \"RFC 2047\" _might_ be\r\n what you meant (together with [20] pointing to RFC 2048).\r\n\r\n Now, unfortunately, the current basic MIME specifications,\r\n RFC 2045..2049, do not contain a substantial general\r\n discussion of security issues.\r\n\r\n The RFC 2045 and RFC 2049 \"Security Considerations\" just\r\n refer to RFC 2046.\r\n But RFC 2046 for this purpose refers to two specific media\r\n type explanations / 'informal registrations' contained in\r\n the body of that memo, and to RFC 2048, which in turn\r\n does *NOT* contain a \"Security Considerations\" section.\r\n(NB:\r\n - RFC 2048 just describes the registration PROCEDURES and\r\n states the Security Considerations *requirement* for any\r\n such registrations.\r\n - The formal ['skeleton'] Registrations for the basic MIME\r\n content types / subtypes from RFC 1521 - Appendix F -\r\n unfortunately have been lost on their [expected] way\r\n into RFC 2046. )\r\n\r\n RFC 2047, in particular, is an extreme:\r\n \"Security issues are not discussed in this memo.\"\r\n (Section 10 on page 14).\r\n\r\n Therefore I suspect that \"RFC 2047\" might indeed NOT be\r\n what you wanted to refer to in loc. cit. Perhaps the\r\n combination of RFC 2046 and RFC 2048 would have been\r\n the most appropriate selection for this citation.\r\n\r\n(3) The second use of reference \"[21]\" in RFC 3926 appears\r\n 2 lines further down in the same paragraph on page 27,\r\n explicitely referring to RFC 1521.\r\n The final statement there on RFC 1521,\r\n \"... even though its protocol is obsoleted \r\n by RFC 2048 [20].\"\r\n\r\n as well does not seem to be very appropriate for me:\r\n It might be disputable whether one should talk about a\r\n \"protocol\" when talking about message/document format\r\n descriptions, but more substantially, the major part\r\n of RFC 1521 has been superseded by RFC 2046 - see (2)\r\n above - while RFC 2048 only supersedes Appendix E of\r\n RFC 1521, which at the time of its publication already\r\n had been \"updated\" (i.e. obsoleted) by RFC 1590.\r\n\r\nTherefore, it might be appropriate to replace the impacted\r\nbad Informative Reference citation [21] on page 31 of RFC 3926\r\nby two citations (e.g. [21]' and [23]), one for RFC 1521 and\r\none for RFC 2046, and to modify the above mentioned phrase.", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2004-11-10", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Magnus Westerlund", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "712", "doc-id": "RFC4583", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1) [clarification]\r\n\r\nSection 4 of RFC 4583, near the top of page 4, says:\r\n\r\n If an 'm' line in an offer contains a 'floorctrl' attribute, the\r\n answerer MUST include one in the corresponding 'm' line in the\r\n answer. [...]\r\n\r\nIt should better say:\r\n\r\n If a SDP media description in an offer contains a 'floorctrl'\r\n attribute, the answerer accepting that media MUST include one in the\r\n corresponding media description of the answer. [...]\r\n\r\n\r\n(2) [clarification]\r\n\r\nSection 6 of RFC 4583, on mid-page 5, says:\r\n\r\n The 'floorid' attribute is used in BFCP 'm' lines. [...]\r\n\r\nIt should better say:\r\n\r\n The 'floorid' attribute is used in the SDP media description for BFCP\r\n media. [...]\r\n\r\n\r\nPlease comment.", "correct_text": "[not submitted]", "notes": "It's always the abuse of language, talking about an SDP attribute\r\nas being used \"in\" an SDP 'm' line, where in fact the attribute is\r\njust a media-level attribute, occurring as a standalone line in an\r\nSDP media description, i.e. the SDP part introduced by the particular\r\n'm' line.\r\n\r\nThis is, at best, a bit confusing.\r\n\r\nfrom pending", "submit_date": "2006-12-30", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "713", "doc-id": "RFC4758", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.7.1", "orig_text": " The XML format for CT-KIP messages have been designed to be\r\n extensible. [...] ", "correct_text": " The XML format for CT-KIP messages has been designed to be\r\n extensible. [...]", "notes": "from pending", "submit_date": "2007-01-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Magnus Nystrom", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "714", "doc-id": "RFC4758", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.8.2", "orig_text": " \r\n \r\n ", "correct_text": " \r\n ", "notes": "from pending", "submit_date": "2007-01-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Magnus Nystrom", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "731", "doc-id": "RFC4612", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": " Consider the following example, which describes a media stream that\r\n allows the transport of G.711 audio and T.38 fax information:\r\n\r\n m=audio 6800 RTP/AVP 0 98 a=rtpmap:98 t38/8000 a=fmtp:98\r\n T38FaxVersion=2;T38FaxRateManagement=transferredTCF", "correct_text": " Consider the following example, which describes a media stream that\r\n allows the transport of G.711 audio and T.38 fax information:\r\n\r\n m=audio 6800 RTP/AVP 0 98\r\n a=rtpmap:98 t38/8000\r\n a=fmtp:98 T38FaxVersion=2;T38FaxRateManagement=transferredTCF", "notes": "line folding issue", "submit_date": "2006-08-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "732", "doc-id": "RFC4612", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7", "orig_text": " [2] Handley, M. and V. Jacobson, \"SDP: Session Description\r\n Protocol\", RFC 2327, April 1998.", "correct_text": " [2] Handley, M., Jacobson, V., and C. Perkins, \"SDP: Session \r\n Description Protocol\", RFC 4566, July 2006.", "notes": "Item [2] refers to RFC 2327.\r\nThat RFC had been obsoleted by RFC 4566 at the time of publication\r\nof RFC 4612 (RFC 4566 had been published 3 weeks before RFC 4612).", "submit_date": "2006-08-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2430", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "Near the bottom of page 43, the Description of SHA224_256Reset says:\r\n\r\n * Description:\r\n * This helper function will initialize the SHA256Context in\r\n * preparation for computing a new SHA256 message digest.\r\n\r\nFor completeness and consistency, it should say:\r\n\r\n * Description:\r\n * This helper function will initialize the SHA256Context in\r\n|* preparation for computing a new SHA-224 or SHA-256 message digest.\r\n ^^^^^^^^^^ ^", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "699", "doc-id": "RFC4227", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.1.1", "orig_text": " If the authority component contains a domain name and a port number,\r\n e.g.,\r\n\r\n soap.beep://stockquoteserver.example.com:1026\r\n\r\n then the DNS is queried for the A Resource Records corresponding to\r\n the domain name, and the port number is used directly.\r\n\r\n If the authority component contains a domain name and no port number,\r\n e.g.,\r\n\r\n soap.beep://stockquoteserver.example.com\r\n\r\n the Service Record algorithm [11] is used with a service parameter of\r\n \"soap-beep\" and a protocol parameter of \"tcp\" to determine the IP/TCP\r\n addressing information. If no appropriate SRV RRs are found (e.g.,\r\n for \"_soap-beep._tcp.stockquoteserver.example.com\"), then the DNS is\r\n queried for the A RRs corresponding to the domain name and the port\r\n number used is assigned by the IANA for the registration in Section\r\n 8.4.", "correct_text": " If the authority component contains a domain name and a port number,\r\n e.g.,\r\n\r\n \tsoap.beep://stockquoteserver.example.com:1026\r\n\r\n then the DNS is queried for the Address Records (i.e. \"A\" for\r\n IPv4, \"AAAA\" for IPv6 based on the host resolver specifications) \r\n corresponding to the domain name, and the port number is used directly.\r\n\r\n If the authority component contains a domain name and no port number,\r\n e.g.,\r\n\r\n soap.beep://stockquoteserver.example.com\r\n\r\n the Service Record algorithm [11] is used with a service parameter of\r\n \"soap-beep\" and a protocol parameter of \"tcp\" to determine the IP/TCP\r\n addressing information. If no appropriate SRV RRs are found (e.g.,\r\n for \"_soap-beep._tcp.stockquoteserver.example.com\"), then the DNS is\r\n queried for the Address RRs corresponding to the domain name \r\n and the port number used is assigned by the IANA for the registration\r\n in Section 8.4.", "notes": "--VERIFIER NOTES--\r\nIt was first reported to us by Alfred H\u00eenes with helpful comments by Philip\r\nNesser.", "submit_date": "2006-02-08", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Eamon O'Tuathail", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "700", "doc-id": "RFC793", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.7", "orig_text": "One procedure for determining a retransmission time out is given here as an \r\nillustration.", "correct_text": "One procedure for determining a retransmission timeout is given here as an \r\nillustration.", "notes": "from pending", "submit_date": "2006-02-18", "submitter_name": "\"Yin Shuming\"", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "701", "doc-id": "RFC793", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.8", "orig_text": "since it will be specified in detail by the specification of the lowel \r\nlevel protocol.", "correct_text": "since it will be specified in detail by the specification of the lower \r\nlevel protocol.", "notes": "from pending", "submit_date": "2006-02-18", "submitter_name": "\"Yin Shuming\"", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "715", "doc-id": "RFC4360", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "Section 3.1. defines the Extended Community extended type classes\r\n0x00ss and 0x40ss, as does Section 3.2. for the type classes 0x01ss\r\nand 0x41ss, and Section 3.3. for the type classes 0x03ss and 0x43ss\r\n(where 'ss' is the Sub-Type).\r\nThese classes are also covered by the IANA Considerations section.\r\n\r\nSection 4. and Section 5. of RFC 4360 both define extended types\r\nwhere \"the value of the high-order octet of the Type field ... can\r\nbe 0x00, 0x01, or 0x02\".\r\nThere is no formal definition for the latter case, Type = 0x02ss,\r\nin the whole RFC, and the subtypes 0x0202 and 0x0203 are not covered\r\nby the IANA considerations section.\r\n>From text in Section 4. and 5., it can be concluded, that perhaps\r\nthe layout from Section 3.1. should be applicable in this case as\r\nwell, but that's all I could find!\r\n\r\nWas type 0x02ss deprecated during the evolution of the draft,\r\nor has the definition of that extended type been ommitted\r\naccidentially from the RFC ?", "correct_text": "[see above]", "notes": "This was addressed by RFC5668.", "submit_date": "2006-02-27", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "716", "doc-id": "RFC791", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.1", "orig_text": " +--------+--------+--------+--------+\r\n |10001000|00000010| Stream ID |\r\n +--------+--------+--------+--------+\r\n Type=136 Length=4", "correct_text": " +--------+--------+--------+--------+\r\n |10001000|00000100| Stream ID |\r\n +--------+--------+--------+--------+\r\n Type=136 Length=4\r\n\r\nRationale:\r\n\r\nThis number count the length which is 4 and not 2.\r\n10 in binary is 2 in decimal, 100 in binary is 4 in decimal.\r\n\r\nThe option-length octet counts the option-type octet and the \r\noption-length octet as well as the option-data octets.(see page 15)\r\nThe length is 4 for the Stream identifier option as we have 4 bytes and \r\nit is well written in page 16 of RFC 791:\r\n\r\nThe following internet options are defined:\r\n\r\n CLASS NUMBER LENGTH DESCRIPTION\r\n ----- ------ ------ -----------\r\n 0 0 - End of Option list. This option occupies only\r\n 1 octet; it has no length octet.\r\n 0 1 - No Operation. This option occupies only 1\r\n octet; it has no length octet.\r\n 0 2 11 Security. Used to carry Security,\r\n Compartmentation, User Group (TCC), and\r\n Handling Restriction Codes compatible with DOD\r\n requirements.\r\n 0 3 var. Loose Source Routing. Used to route the\r\n internet datagram based on information\r\n supplied by the source.\r\n 0 9 var. Strict Source Routing. Used to route the\r\n internet datagram based on information\r\n supplied by the source.\r\n 0 7 var. Record Route. Used to trace the route an\r\n internet datagram takes.\r\n 0 8 4 Stream ID. Used to carry the stream\r\n identifier.\r\n 2 4 var. Internet Timestamp.", "notes": "from pending", "submit_date": "2007-01-03", "submitter_name": "Damien Mattei", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "717", "doc-id": "RFC4301", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) [typo]\r\n\r\nIn section 4.1, on page 14, RFC 4301 says:\r\n\r\n DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit\r\n Congestion Notification (ECN) [RaFlBl01] fields are not \"selectors\",\r\n as that term in used in this architecture, the sender will need a\r\n mechanism to direct packets with a given (set of) DSCP values to the\r\n appropriate SA. This mechanism might be termed a \"classifier\".\r\n\r\nIt should say ( s/in used/is used/ ) :\r\n\r\n DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit\r\n Congestion Notification (ECN) [RaFlBl01] fields are not \"selectors\",\r\n| as that term is used in this architecture, the sender will need a\r\n mechanism to direct packets with a given (set of) DSCP values to the\r\n appropriate SA. This mechanism might be termed a \"classifier\".\r\n\r\n(2) [textual improvement]\r\n\r\nIn section 4.4.3.2, the last lines on page 45 say:\r\n\r\n [...]. An entry\r\n used with certificate-based authentication MAY include additional\r\n data to facilitate certificate revocation status, e.g., a list of\r\n << page break >>\r\n appropriate OCSP responders or CRL repositories, [...]\r\n\r\nThis seems to make not much sense. It should perhaps say:\r\n\r\n [...]. An entry\r\n used with certificate-based authentication MAY include additional\r\n data to facilitate certificate revocation status determination, e.g.,\r\n a list of appropriate OCSP responders or CRL repositories, [...]\r\n\r\n(3) [typo]\r\n\r\nThe second paragraph of section 4.4.3.3, on page 46, says:\r\n\r\n If the entry indicates that the IKE ID is to be used, then the PAD\r\n entry ID field defines the authorized set of IDs. If the entry\r\n indicates that child SAs traffic selectors are to be used, then an\r\n additional data element is required, in the form of IPv4 and/or IPv6\r\n address ranges. [...]\r\n\r\nIt should say ( s/SAa/SA/ ) :\r\n\r\n If the entry indicates that the IKE ID is to be used, then the PAD\r\n entry ID field defines the authorized set of IDs. If the entry\r\n| indicates that child SA traffic selectors are to be used, then an\r\n additional data element is required, in the form of IPv4 and/or IPv6\r\n address ranges. [...]\r\n\r\n(4) [textual consistency]\r\n\r\nBelow the table on page 59, section 5.1.2.2 says:\r\n\r\n Notes:\r\n\r\n (1) - (6) See Section 5.1.2.1.\r\n\r\nIt should say:\r\n\r\n Notes:\r\n\r\n| (1) - (3), (5), (6) See Section 5.1.2.1.\r\n\r\n\r\n(5) [typo]\r\n\r\nThe second paragraph of App. D.2, on page 89, says:\r\n\r\n [...]. (If we choose\r\n to allow carriage of fragments on transport mode SAs for IPv6, the\r\n problems arises in that context as well.)\r\n ^ ^^\r\n\r\nThere obviously is a singular/plural mismatch.\r\nThe text should say:\r\n [...]. (If we choose\r\n to allow carriage of fragments on transport mode SAs for IPv6, the\r\n| problem arises in that context as well.)\r\n\r\n\r\n(6) Insufficient IPcomp integration\r\n\r\nAt the end of section 3.1, on page 10, RFC 4301 says:\r\n\r\n IPsec optionally supports negotiation of IP compression [SMPT01],\r\n motivated in part by the observation that when encryption is employed\r\n within IPsec, it prevents effective compression by lower protocol\r\n layers.\r\n\r\nIt has also been observed that payload compression can help counter\r\nTPA. Thus, there are at least two reasons for a tight integration\r\nof IPComp with IPsec.\r\nBut I could not find any 'hook' in RFC 4301 (and in RFC 4302 / 4303\r\nas well) for the concrete support of IPComp in ESP / AH IPsec SAs.\r\n\r\nIKEv2 (RFC 4306) roughly allows negotiation of IPComp, but how shall\r\nthat be triggered and work, in an interoperable way, if there are no\r\narchitectural provisions for the support of IPComp designed in into\r\nthe IPsec databases (SPD, SAD) as described in RFC 4301 ????\r\n\r\n\r\n(7) Insufficient integration with QoS (DS)\r\n\r\nThe steps taken for the integration with Differentiated Services\r\nare half-hearted. The processing rules specified for the DSCP\r\nfield in the IP header[s] remain incomplete as long as there is\r\nno specified interoperable way to use DSCP as an selector as well.\r\n\r\nIMHO, the discussion on page 14 of RFC 4301 is misleading because\r\nDS classification and treatment needs to be done independent from\r\nIPsec treatment.\r\nIn many scenarios, e.g. on 'hosts' or 'QoS gateways' that must\r\nperform fine-grained traffic classification, DS treatment must\r\nbe performed strictly before IPsec treatment in the outbound\r\ncase (and after IPsec in the inbound case), to make ULP fields\r\naccessible to the DS classifiers.\r\nIPsec should then be capable of guaranteeing the same security\r\ntreatment of all packets of certain traffic class to a given\r\ndestination.\r\n\r\nI still have problems to imagine how DS integration could be\r\nachieved with the processing model of section 5.1 of RFC 4301.\r\n\r\nAt the end of section 3.1, on page 10, RFC 4301 says:\r\n\r\n\r\n(8) Inconsistent DS Field handling specified in Section 5.1.2.x\r\n\r\nThe IPv6 related table in section 5.1.2.2 contains the line,\r\n\r\n DS Field copied from inner hdr (5) no change (9)\r\n\r\nand the subsequent Notes give a lengthy explanation under (9).\r\n\r\nContrary to that, the corresponding table line for IPv4, in section\r\n5.1.2.1 on page 57, is *not* linked to such a note.\r\n\r\nI cannot see any reason precluding the application of the arguments\r\ngiven in Note (9) of section 5.1.2.2 to the IPv4 case as well.\r\n\r\nHave I missed any significant point there?\r\n\r\n\r\n(9) SA negotiation -- capability mismatch with IKEv2\r\n\r\nSee section 4.4.1.2, second paragraph.", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2006-03-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "718", "doc-id": "RFC4758", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.8.3", "orig_text": " \r\n \r\n", "correct_text": " \r\n \r\n", "notes": "from pending", "submit_date": "2007-01-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Magnus Nystrom", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "720", "doc-id": "RFC4758", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.9.3", "orig_text": " \r\n \r\n ", "correct_text": " \r\n \r\n ", "notes": "from pending", "submit_date": "2007-01-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Magnus Nystrom", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "721", "doc-id": "RFC4303", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1)\r\n\r\nSection 2.1 of RFC 4303 re-states a lot of material from the\r\nIPsec Architecture document, RFC 4301, without being able to\r\npresent all the details. SPI selection has become a quite\r\ncomplicated procedure with subtle details, which all can be\r\nfound in RFC 4301.\r\n\r\nIMHO, it would have been very much preferrable to replace most\r\nof the text in section 2.1 by a short referral to RFC 4301.\r\nAny replication of specification entails the danger of\r\ninconsistencies and raises the question of \"truth weight\"\r\nfor the concurring specifications; it is better to avoid\r\nsuch \"races\" from the beginning.\r\n\r\nThis same issue applies to section 2.4 of RFC 2402. (By accident,\r\nI have forgotten to mention it in my comments on that document.)\r\n\r\nMore concretely, I would have preferred the replacement of the\r\nsecond up to the second-to-last paragraph of section 2.1 of RFC 4303,\r\non pages 10/11,\r\n\r\n For a unicast SA, the SPI can be used by itself to specify an SA, or\r\n it may be used in conjunction with the IPsec protocol type (in this\r\n ...\r\n\r\n ...\r\n ...\r\n ...\r\n\r\n ...\r\n multicast address, and source address. An Any-Source Multicast group\r\n SA requires only an SPI and a destination multicast address as an\r\n identifier.\r\n\r\nby a short note, e.g.\r\n\r\n All implementations of ESP MUST support the Security Association\r\n Database (SAD) as specified in the IPsec Archtecture document\r\n [Ken-Arch] and the SA lookup procedures for unicast traffic\r\n specified therein. ESP implementations SHOULD support extensions\r\n to the SAD and the SA lookup procedures specified in documents\r\n amending [Ken-Arch], e.g. for multicast traffic or mobility support,\r\n if they intend to provide ESP support for such scenarios.\r\n\r\nA similar change would be applicable to RFC 4302, section 2.4,\r\npages 6/7.\r\n\r\n\r\n(2)\r\n\r\nIn section 3.4.3, on the lower half of page 29, RFC 4303 says:\r\n\r\n [...]. In either\r\n case, if the integrity check fails, the receiver MUST discard the\r\n received IP datagram as invalid; this is an auditable event. The\r\n audit log entry for this event SHOULD include the SPI value,\r\n [...]\r\n\r\nBecause the audit log details are in a separate sentence, the logical\r\nhierarchy implied by using one semicolon and one full stop is brocken.\r\nIt would have been better to say:\r\n [...]. In either\r\n case, if the integrity check fails, the receiver MUST discard the\r\n| received IP datagram as invalid. This is an auditable event. The\r\n audit log entry for this event SHOULD include the SPI value,\r\n [...]\r\n\r\nSimilar punctuation already is used in many places of the RFC.\r\n\r\n\r\n(3)\r\n\r\nAs mentioned in section 7, section 3.4 has been reorganized from\r\nRFC 2406.\r\nDuring that process, the perhaps most important part of ESP inbound\r\npacket processing has disappeared from the section headlines:\r\ndecryption !\r\n\r\nTo cover what's inside, and to make that locatable in the ToC,\r\nperhaps the section headline,\r\n\r\n 3.4.4. Integrity Check Value Verification\r\n\r\non page 30, and in the ToC, should be modified to read:\r\n\r\n 3.4.4. Integrity Check Value Verification and Payload Decryption\r\n\r\nI would like to recommend that you submit an RFC Errata Note to\r\ncatch this issue.\r\n\r\n\r\n(4)\r\n\r\nIn section 3.4.4.2, the same issue as (2) above also applies to\r\nthe item numbered \"2.\" on page 32.\r\n\r\n\r\n(5) References\r\n\r\nRFC 4306 repeatedly refers to its predecessor, RFC 2406, but it omits\r\ngiving a formal (Informative) Reference to that document in Section\r\n10.2 on page 37.\r\n\r\nPerhaps it would also have been worth noting that a *full* version\r\nof the research paper [Kra01] can be found on IACR ePrint, document\r\n2001/040.\r\n\r\n\r\n(6) Appendix A\r\n\r\nAs mentioned in my comments on RFC 4302, this appendix is the more\r\ncomplete and hence preferrable text compared to App. B of RFC 4302.\r\nThere is one exception:\r\nThe formatting of tha last part of A2.1 ia less pleasant.\r\nTo enhance readability, it is always preferrable not to break\r\nsimple expressions apart by line breaks, whenever possible. In\r\nthis case, simple relational expressions are broken into 2 lines.\r\n\r\nRFC 4303, on page 40, says:\r\n\r\n In checking for replayed packets,\r\n\r\n + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <=\r\n Tl, then check the corresponding bit in the window to see if\r\n this Seql has already been seen. If yes, reject the packet. If\r\n no, perform integrity check (see Appendix A2.2. below for\r\n determination of Seqh).\r\n\r\n + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <=\r\n Tl, then check the corresponding bit in the window to see if\r\n this Seql has already been seen. If yes, reject the packet. If\r\n no, perform integrity check (see Appendix A2.2. below for\r\n determination of Seqh).\r\n\r\nThe formatting in RFC 4302 of the same text (with the already\r\nmentioned typo there corrected, and the Appendix name adapted),\r\nis better:\r\n\r\n In checking for replayed packets,\r\n\r\n + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND\r\n Seql <= Tl, then check the corresponding bit in the window to\r\n see if this Seql has already been seen. If yes, reject the\r\n packet. If no, perform integrity check (see Appendix A2.2\r\n below for determination of Seqh).\r\n\r\n + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR\r\n Seql <= Tl, then check the corresponding bit in the window to\r\n see if this Seql has already been seen. If yes, reject the\r\n packet. If no, perform integrity check (see Appendix A2.2\r\n below for determination of Seqh).\r\n\r\nBut I would even have preferred this formatting:\r\n\r\n In checking for replayed packets,\r\n\r\n + Under Case A:\r\n If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <= Tl,\r\n then check the corresponding bit in the window to see if this\r\n Seql has already been seen. If yes, reject the packet.\r\n If no, perform integrity check (see Appendix A2.2 below for\r\n determination of Seqh).\r\n\r\n + Under Case B:\r\n If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <= Tl,\r\n then check the corresponding bit in the window to see if this\r\n Seql has already been seen. If yes, reject the packet.\r\n If no, perform integrity check (see Appendix A2.2 below for\r\n determination of Seqh).", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2006-03-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "722", "doc-id": "RFC4758", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix A says:", "orig_text": " \r\n \r\n \r\n \r\n ", "correct_text": " \r\n \r\n \r\n Currently, only the nonce is defined. In future versions,\r\n other payloads may be defined, e.g., for one-roundtrip\r\n initialization protocols.\r\n \r\n ", "notes": "documentation was missing\r\n\r\nfrom pending", "submit_date": "2007-01-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Magnus Nystrom", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "723", "doc-id": "RFC4758", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix B.2 says:", "orig_text": " \r\n \r\n \r\n \r\nBecause this is a server-to-server example, the xmlns for that stream \r\nheader should instead be 'jabber:server'.\r\n ", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2004-12-08", "submitter_name": "Peter Saint-Andre", "verifier_id": "", "verifier_name": null, "update_date": "2022-01-25 17:42:29"}, {"errata_id": "705", "doc-id": "RFC4327", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) [plaintext flaw]\r\n\r\nIn the final paragraph of Section 7, on page 8, RFC 4327 says:\r\n\r\n In parallel with the entry created in the lmpTeLinkTable, an entry\r\n may be created in the teLinkTable of TE Link MIB module\r\n [RFC4220].\r\n\r\nIt should better say:\r\n\r\n In parallel with the entry created in the lmpTeLinkTable, an entry\r\n| may be created in the teLinkTable of the TE Link MIB module\r\n [RFC4220].\r\n ^^^^^\r\n\r\n(2) [plaintext flaw]\r\n\r\nIn the second paragraph of Section 8, at the bottom of page 8,\r\nRFC 4327 says:\r\n\r\n [...]. The interrelation of entries in the\r\n ifTable is defined by Interfaces Stack Group defined in [RFC2863].\r\n\r\nIt should say:\r\n\r\n [...]. The interrelation of entries in the\r\n| ifTable is defined by the Interfaces Stack Group defined in\r\n [RFC2863].\r\n ^^^^^\r\n\r\n\r\n(3) LmpInterval TEXTUAL-CONVENTION (page 12)\r\n\r\nThe clause,\r\n\r\n DESCRIPTION\r\n \"The interval delay in milliseconds.\"\r\n\r\nperhaps should better say:\r\n\r\n DESCRIPTION\r\n| \"The delay interval in milliseconds.\"\r\n\r\nor even:\r\n\r\n DESCRIPTION\r\n| \"The interval period for a periodically performed LMP operation,\r\n| in milliseconds.\"\r\n\r\n\r\n(4) LmpRetransmitInterval TEXTUAL-CONVENTION (page 12)\r\n\r\nThe clause,\r\n\r\n DESCRIPTION\r\n \"The retransmission interval delay in milliseconds.\"\r\n\r\nperhaps should better say:\r\n\r\n DESCRIPTION\r\n| \"The retransmission delay interval in milliseconds.\"\r\n\r\nor even better:\r\n\r\n DESCRIPTION\r\n| \"The (initial) retransmission interval in milliseconds.\"\r\n\r\n\r\n(5) lmpNbrRetransmitInterval OBJECT-TYPE (page 14)\r\n\r\nThe sentence in the DESCRIPTION clause,\r\n\r\n \"[...] This object ... is used to implement congestion-handling\r\n mechanism as defined in Section 10 of the Link Management Protocol\r\n specification, which is based on RFC 2914.\"\r\n\r\nshould perhaps better say:\r\n vvvvv\r\n| \"[...] This object ... is used to implement the congestion-handling\r\n mechanism as defined in Section 10 of the Link Management Protocol\r\n specification, which is based on RFC 2914.\"\r\n\r\n\r\n(6) lmpNbrRetryLimit OBJECT-TYPE (page 14)\r\n\r\nThe correction from item (5) above should be applied here as well.\r\n\r\n\r\n(7) lmpCcRemoteAddressType OBJECT-TYPE (page 20)\r\n\r\n DESCRIPTION\r\n \"This value represents the remote control channel IP address\r\n type. In point-to-point configuration, this value can be set\r\n to unknown(0).\"\r\n ::= { lmpControlChannelEntry 6 }\r\n\r\nshould better say:\r\n\r\n DESCRIPTION\r\n \"This value represents the remote control channel IP address\r\n| type. In point-to-point configurations, this value can be set\r\n to unknown(0).\"\r\n ::= { lmpControlChannelEntry 6 }\r\n ^\r\n\r\n[ The possible alternative, \"In a point-to-point configuration, ...\"\r\n is not proposed here, to maintain a style similar to the minimal\r\n change for the next object -- see (8) below.]\r\n\r\n\r\n(8) lmpCcRemoteIpAddr OBJECT-TYPE (page 20)\r\n\r\n DESCRIPTION\r\n \"[...]\r\n Control channel must be numbered on non-point-to-point\r\n configuration. For point-to-point configuration, the\r\n remote control channel address can be of type unknown\r\n in which case this object must be a zero-length string. The\r\n lmpCcRemoteId object then identifies the unnumbered\r\n address.\"\r\n ::= { lmpControlChannelEntry 7 }\r\n\r\nshould better say:\r\n\r\n DESCRIPTION\r\n \"[...]\r\n| The control channel must be numbered on non-point-to-point\r\n| configurations. For point-to-point configurations, the\r\n remote control channel address can be of type unknown\r\n in which case this object must be a zero-length string. The\r\n lmpCcRemoteId object then identifies the unnumbered\r\n address.\"\r\n ::= { lmpControlChannelEntry 7 }\r\n\r\n\r\n(11) lmpControlChannelPerfEntry OBJECT-TYPE (page 24)\r\n\r\n DESCRIPTION\r\n \"An entry in this table is created by a LMP-enabled device for\r\n every control channel. lmpCcCounterDiscontinuityTime is used\r\n to indicate potential discontinuity for all counter objects\r\n in this table.\"\r\n\r\nThe latter is not true.\r\nIn this MIB module, the discontinuity is monitored per table *entry*\r\n(conceptual row), not for the table as a whole -- see the DESCRIPTIONs\r\nfor lmp<*>DiscontinuityTime later in the RFC.\r\n\r\nTherefore, the above clause should say:\r\n\r\n DESCRIPTION\r\n \"An entry in this table is created by a LMP-enabled device for\r\n every control channel. lmpCcCounterDiscontinuityTime is used\r\n to indicate potential discontinuity for all counter objects\r\n| in this entry (conceptual row).\"\r\n\r\n\r\n(12) lmpCcChannelStatusAckSent OBJECT-TYPE (page 34)\r\n\r\nThe clause,\r\n\r\n DESCRIPTION\r\n \"This object counts the number of ChannelStatus messages\r\n that have been sent on this control channel.\"\r\n ::= { lmpControlChannelPerfEntry 47 }\r\n\r\nrefers to the wrong message type; it should say:\r\n\r\n DESCRIPTION\r\n| \"This object counts the number of ChannelStatusAck messages\r\n that have been sent on this control channel.\"\r\n ::= { lmpControlChannelPerfEntry 47 }\r\n\r\n\r\n(14) lmpTeLinkPerfEntry OBJECT-TYPE (page 42)\r\n\r\nThe correction from item (11) above is to be applied here as well:\r\n\r\nReplace:\r\n\r\n DESCRIPTION\r\n \"An entry in this table is created by an LMP-enabled device for\r\n every TE link. lmpTeCounterDiscontinuityTime is used\r\n to indicate potential discontinuity for all counter objects\r\n in this table.\"\r\n\r\nby:\r\n\r\n DESCRIPTION\r\n \"An entry in this table is created by an LMP-enabled device for\r\n every TE link. lmpTeCounterDiscontinuityTime is used\r\n to indicate potential discontinuity for all counter objects\r\n| in this entry (conceptual row).\"\r\n\r\n\r\n(15) lmpTeEndVerifyRetransmit OBJECT-TYPE (page 45/46)\r\n\r\n DESCRIPTION\r\n \"This object counts the number of EndVerify messages that\r\n have been retransmitted over this control channel.\"\r\n ::= { lmpTeLinkPerfEntry 12 }\r\n\r\nis inappropriate. In accordance with the text supplied for the\r\nother objects in the LMP TE Link Performance Table, it should say:\r\n\r\n DESCRIPTION\r\n \"This object counts the number of EndVerify messages that\r\n| have been retransmitted for this TE link.\"\r\n ::= { lmpTeLinkPerfEntry 12 }\r\n\r\n\r\n(16) lmpTeTestStatusFailureRetransmit OBJECT-TYPE (page 47)\r\n\r\n DESCRIPTION\r\n \"This object counts the number of TestStatusFailure messages\r\n that have been retransmitted on this TE link.\"\r\n ::= { lmpTeLinkPerfEntry 20 }\r\n\r\nshould say:\r\n\r\n DESCRIPTION\r\n \"This object counts the number of TestStatusFailure messages\r\n that have been retransmitted for this TE link.\"\r\n ::= { lmpTeLinkPerfEntry 20 }\r\n\r\n[ According to Section 12.5.8. of the LMP specification [RFC 4204],\r\n LMP TestStatusFailure messages are transmitted over the control\r\n channel; hence, \"retransmitted *on* this TE Link\" is wrong! ]\r\n\r\n\r\n(17) lmpTeLinkSummaryRetransmit OBJECT-TYPE (page 48)\r\n\r\nThe correction from item (15) above is to be applied here as well:\r\n\r\nReplace:\r\n\r\n DESCRIPTION\r\n \"This object counts the number of LinkSummary messages that\r\n have been retransmitted over this control channel.\"\r\n ::= { lmpTeLinkPerfEntry 25 }\r\n\r\nby:\r\n\r\n DESCRIPTION\r\n \"This object counts the number of LinkSummary messages that\r\n| have been retransmitted for this TE link.\"\r\n ::= { lmpTeLinkPerfEntry 25 }\r\n\r\n\r\n(18) lmpTeChannelStatusAckSent OBJECT-TYPE (page 50)\r\n\r\nThe correction from item (12) above is to be applied here as well:\r\n\r\nReplace:\r\n\r\n DESCRIPTION\r\n \"This object counts the number of ChannelStatus messages\r\n that have been sent for this TE link.\"\r\n ::= { lmpTeLinkPerfEntry 34 }\r\n\r\nby:\r\n\r\n DESCRIPTION\r\n| \"This object counts the number of ChannelStatusAck messages\r\n that have been sent for this TE link.\"\r\n ::= { lmpTeLinkPerfEntry 34 }\r\n\r\n\r\n(20) lmpDataLinkPerfEntry OBJECT-TYPE (page 55)\r\n\r\nThe correction from item (11) above is to be applied here as well:\r\n\r\nReplace:\r\n\r\n DESCRIPTION\r\n \"An entry in this table contains information about\r\n the LMP performance counters for the data-bearing links.\r\n lmpDataLinkDiscontinuityTime is used to indicate potential\r\n discontinuity for all counter objects in this table.\"\r\n\r\nby:\r\n\r\n DESCRIPTION\r\n \"An entry in this table contains information about\r\n the LMP performance counters for the data-bearing links.\r\n lmpDataLinkDiscontinuityTime is used to indicate potential\r\n| discontinuity for all counter objects in this entry.\"\r\n\r\n\r\n(21) lmpNotificationMaxRate OBJECT-TYPE (page 57/58)\r\n\r\nThe DESCRIPTION text near the top of page 58 says:\r\n\r\n [...]. For instance, a network of 100 nodes\r\n with 5 links of 128 wavelengths each and a link verification\r\n of 1 minute with no more than 10% of the links failed at any\r\n given time would have 1 notification per second sent from\r\n each node, or 100 notifications per second for the whole\r\n network. The rest of the notifications are negligible\r\n compared to this number.\r\n\r\n To alleviate the congestion problem, the\r\n lmpNotificationMaxRate object can be used to implement a\r\n throttling mechanism. It is also possible to enable/disable\r\n certain type of notifications.\r\n\r\nIt should say, correcting two flaws (line breaks adjusted):\r\n\r\n [...]. For instance, a network of 100 nodes\r\n with 5 links of 128 wavelengths each and a link verification\r\n| interval of 1 minute with no more than 10% of the links failed\r\n at any given time would have 1 notification per second sent\r\n from each node, or 100 notifications per second for the whole\r\n network. The rest of the notifications are negligible\r\n compared to this number.\r\n\r\n To alleviate the congestion problem, the\r\n lmpNotificationMaxRate object can be used to implement a\r\n throttling mechanism. It is also possible to enable/disable\r\n| certain types of notifications.\r\n\r\n\r\n(23) lmpControlChannelGroup OBJECT-GROUP (page 72)\r\n\r\nAt the bottom of page 72, the RFC says:\r\n\r\n DESCRIPTION\r\n \"Objects that can be used to configure LMP interface.\"\r\n\r\nIt should say:\r\n\r\n DESCRIPTION\r\n| \"Objects that can be used to configure LMP interfaces.\"\r\n", "correct_text": "[see above]", "notes": "Verifier's analysis:\r\n\r\n1. Yes. Editorial nit.\r\n2. Yes. Editorial nit.\r\n3. Yes. Editorial nit.\r\n4. Yes. Editorial nit.\r\n5. Yes. Editorial nit.\r\n6. Yes. Editorial nit.\r\n7. Yes. Editorial nit.\r\n8. Yes. Editorial nit.\r\n11. Yes. Editorial change of substance.\r\n12. Yes. Editorial change of substance.\r\n14. Yes. Editorial change of substance.\r\n15. Yes. Editorial change of substance.\r\n16. Yes. Editorial change of substance.\r\n17. Yes. Editorial change of substance.\r\n18. Yes. Editorial change of substance.\r\n20. Yes. Editorial change of substance.\r\n21. Yes. Editorial nit.\r\n23. Yes. Editorial nit.\r\n\r\nRejected items have been moved to Errata ID 1938.", "submit_date": "2006-02-24", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "706", "doc-id": "RFC3967", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "Normative references to HMAC in future IETF Standards Track documents should always refer to FIPS-198 instead of RFC 2104.", "orig_text": "(2)\r\n MD5 [RFC1321]\r\n\r\nAccording to the contemporary cryptographic literature, protocols\r\nshould now better use SHA-xxx (xxx = [1 / ] 224 / 256 / 384 / 512)\r\nas a cryptographic hashing primitive instead of MD5.\r\n\r\nSee\r\n- FIPS PUB 180-2, issued '2002 August 1', and amended by\r\n Change Note 1, issued '2004 February 25', for SHA-224,\r\nand\r\n- RFC 3174 (for SHA-1) and RFC 3874 (for SHA-224) -- based on above.\r\n\r\nFIPS 180-2 should be used for Normative References in future IETF\r\nStandards Track documents.\r\n\r\n\r\n", "correct_text": "[see above]", "notes": "Remark 3:\r\n SHA-1 (as well as MD5) already is no more recommended for new\r\n applications to be used in the public administration and economy\r\n within the European Union, see the URL given in Remark 2 above!\r\n\r\nfrom pending\n --VERIFIER NOTES-- \n2021-10-06: moved from Held for Document Update to Rejected per request from Murray Kucherawy. This erratum was reviewed while working on a bis document.", "submit_date": "2005-01-03", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2021-10-06 18:47:32"}, {"errata_id": "707", "doc-id": "RFC3944", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "One general inconsistency observed throughout the text, is related\r\nto the use of 'architecture' (singular) vs. 'architectures' (plural).\r\nSince the H.350 series recommendations describe a *single*\r\n[LDAP directory] architecture [extension], I propose to modify the\r\ntext to use the singular form in a consistent manner as noted below.\r\n\r\nFurther, there are a lot of places where I miss expected articles\r\n('the' / 'a' / 'an') -- even in the text that is said to be copied\r\nfrom the ITU-T Recommendations.\r\n(1)\r\n\r\nChange the first 4 (identical) lines of\r\n- 'Abstract' on page 1, and\r\n- '1. Scope' on page 3, from :\r\n\r\n \"The International Telecommunications Union Standardization Sector\r\n (ITU-T) has created the H.350 series of Recommendations that specify\r\n directory services architectures in support of multimedia\r\n conferencing protocols. The goal of the architecture is to\" ...\r\n ^^^^^^^^^^^^^^^^!!\r\nto:\r\n\r\n \"The International Telecommunications Union Standardization Sector\r\n (ITU-T) has created the H.350 series of Recommendations that specify\r\n| a directory services architecture in support of multimedia\r\n conferencing protocols. The goal of the architecture is to\" ...\r\n\r\n\r\n(2)\r\n\r\nChange the second paragraph of '1. Scope' on page 3:\r\n\r\n \"H.350 architectures are not intended to change the operation of\r\n multimedia conferencing protocols in any way. Rather, they are meant\r\n to standardize the way the already defined protocol elements are\r\n stored in a directory, so that they can be accessed in a standardized\r\n manner.\"\r\n\r\nto:\r\n\r\n| \"The H.350 architecture is not intended to change the operation of\r\n| multimedia conferencing protocols in any way. Rather, it is meant\r\n to standardize the way the already defined protocol elements are\r\n stored in a directory, so that they can be accessed in a standardized\r\n manner.\"\r\n\r\n\r\n(3)\r\n\r\nIn lines 2..4 of '4.1. Scope' on page 4, change:\r\n\r\n ... \"Standardized directory services\r\n can support association of persons with endpoints, searchable white\r\n pages, and clickable dialling.\" ...\r\n\r\nto:\r\n\r\n ... \"Standardized directory services\r\n| can support the association of persons with endpoints, searchable white\r\n pages, and clickable dialling.\" ...\r\n\r\n\r\n(4)\r\n\r\nIn the bottom half of the second paragraph of section 4.1. on\r\npage 5, change:\r\n ... \"Each of these\r\n disparate systems can access the same underlying data source,\r\n reducing or eliminating the need to coordinate separate management of\r\n each system. A significant benefit to the user is that the\r\n management of this data can be incorporated into existing customer\r\n management tools, allowing for quick and flexible scaling up of\r\n applications. Indeed, many technology providers have already\r\n incorporate LDAP into their products, but have been forced to do so\r\n without benefit of a standardized schema.\" ...\r\n\r\nto:\r\n ... \"Each of these\r\n disparate systems can access the same underlying data source,\r\n| reducing or eliminating the need to coordinate the separate management\r\n of each system. A significant benefit to the user is that the\r\n management of this data can be incorporated into existing customer\r\n management tools, allowing for quick and flexible scaling up of\r\n applications. Indeed, many technology providers have already\r\n incorporate LDAP into their products, but have been forced to do so\r\n| without the benefit of a standardized schema.\" ...\r\n\r\n\r\n(5)\r\n\r\nIn lines 3..7 of the forth paragraph of section 4.1. on page 5,\r\nchange:\r\n ... \"LDAP provides a\r\n convenient storage location that can be accessed by both call server\r\n and endpoint; thus it is possible to use the directory to support\r\n endpoint configuration, which is important for simplified operation\r\n and supporting user mobility.\"\r\n\r\nto:\r\n ... \"LDAP provides a\r\n convenient storage location that can be accessed by both call server\r\n| and endpoint; thus it is possible to use the directory to support the\r\n endpoint configuration, which is important for simplified operation\r\n and supporting user mobility.\"\r\n\r\n\r\n(6)\r\n\r\nIn the bottom half of the sixth paragraph of section 4.1. on page 6,\r\nchange:\r\n ... \"Similarly, commObject contains a\r\n pointer, called commOwner, which points to the individual or resource\r\n that is associated with the commObject. In this way, people or\r\n resources can be associated with endpoints. The only change required\r\n in the enterprise directory is the addition of the simple object\r\n class commURI. CommObject data may be instantiated in the same or in\r\n entirely separate directories, thus allowing flexibility in\r\n implementation.\"\r\n\r\nto:\r\n\r\n| ... \"Similarly, each commObject contains a\r\n pointer, called commOwner, which points to the individual or resource\r\n that is associated with the commObject. In this way, people or\r\n resources can be associated with endpoints. The only change required\r\n| to the enterprise directory is the addition of the simple object\r\n class commURI. CommObject data may be instantiated in the same or in\r\n| an entirely separate directory, thus allowing flexibility in\r\n implementation.\"\r\n\r\n\r\n(7)\r\n\r\nIn the first lines of the final paragraph of section 4.1.2.1,\r\non page 9, change:\r\n\r\n \"Note that this example and approach demonstrate extension of the\r\n general commObject object class, and not any individual H.350.x\r\n classes.\" ...\r\n\r\nto:\r\n\r\n| \"Note that this example and approach demonstrate an extension of the\r\n general commObject object class, and not any individual H.350.x\r\n classes.\" ...\r\n\r\n\r\n(8)\r\n\r\nIn the first line of section 4.2., on page 10, change:\r\n\r\n \"Auxiliary object class that contains the commURI attribute.\" ...\r\n\r\nto:\r\n\r\n| \"An Auxiliary object class that contains the commURI attribute.\" ...\r\n\r\n\r\n(9)\r\n\r\nChange the 'definition' clause of section 5.2.4., on page 20, from:\r\n\r\n \"Address which specifies the domain location of SIP proxy within\r\n a domain. RFC 3261 defines the role of the SIP proxy.\"\r\n\r\nto:\r\n\r\n| \"Address which specifies the domain location of a SIP proxy within\r\n a domain. RFC 3261 defines the role of the SIP proxy.\"\r\n\r\n\r\n(10)\r\n\r\nIn the first two lines of the second paragraph of section 7.,\r\non page 27, change:\r\n\r\n \"H.350 does not alter the security architectures of any particular\r\n protocol.\"\r\n\r\nto:\r\n\r\n| \"H.350 does not alter the security architecture of any particular\r\n protocol.\"", "correct_text": "[see above]", "notes": "", "submit_date": "2005-01-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "708", "doc-id": "RFC3939", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "8", "orig_text": "according to BCP 90\r\n(= RFC 3864), the new IMAIL Header Fields, \"Caller-ID\" and\r\n\"Caller-Name\", as well should get formal IANA registrations listed\r\nin the RFC, using the templates from section 4.2. of RFC 3864 !\r\n", "correct_text": "[none submitted]", "notes": "Perhaps, a citation to BCP 90 would also have been appropriate.\r\n\r\nfrom pending", "submit_date": "2005-01-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "709", "doc-id": "RFC3939", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "Minor textual improvements:\r\n\r\na) Change the first line of section 6.1., on page 6, from\r\n\r\n \"The intent of these headers are to record telephone number that is\r\n sent by the analog phone system with an incoming call without\r\n alteration or interpretation.\" ...\r\n\r\nto:\r\n\r\n| \"The intent of these headers are to record the telephone number that\r\n ^^^\r\n is sent by the analog phone system with an incoming call without\r\n alteration or interpretation.\" ...\r\n\r\nb) In the first line of section '10. Acknowledgments', on page 9,\r\nchange:\r\n\r\n \"The previous authors of versions of this document were Derrick Dunne\r\n and Jason Collins.\" ...\r\n\r\nto:\r\n\r\n| \"The authors of previous versions of this document were Derrick Dunne\r\n and Jason Collins.\" ...", "correct_text": "[see above]", "notes": "", "submit_date": "2005-01-04", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "4950", "doc-id": "RFC6022", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2 (2,3)", "orig_text": "\r\n bar\r\n 2008-06-01\r\n \r\n\r\na. Via using identifer parameter:\r\n\r\n \r\n bar-types\r\n ", "correct_text": "\r\n bar\r\n 2008-06-01\r\n \r\n\r\na. Via using identifier parameter:\r\n\r\n \r\n bar-types\r\n ", "notes": "", "submit_date": "2017-02-24", "submitter_name": "Andreas Walden", "verifier_id": "", "verifier_name": "Benoit Claise", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "733", "doc-id": "RFC3781", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1", "orig_text": " Integer64 ::=\r\n [APPLICATION 10]\r\n IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)\r\n\r\n Unsigned64\r\n [APPLICATION 11]\r\n IMPLICIT INTEGER (0..18446744073709551615)\r\n\r\n Float32\r\n [APPLICATION 12]\r\n IMPLICIT OCTET STRING (SIZE (4))\r\n\r\n Float64\r\n [APPLICATION 13]\r\n IMPLICIT OCTET STRING (SIZE (8))\r\n\r\n Float128\r\n [APPLICATION 14]\r\n IMPLICIT OCTET STRING (SIZE (16))\r\n\r\n", "correct_text": " Integer64 ::=\r\n [APPLICATION 10]\r\n IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)\r\n\r\n Unsigned64 ::=\r\n [APPLICATION 11]\r\n IMPLICIT INTEGER (0..18446744073709551615)\r\n\r\n Float32 ::=\r\n [APPLICATION 12]\r\n IMPLICIT OCTET STRING (SIZE (4))\r\n\r\n Float64 ::=\r\n [APPLICATION 13]\r\n IMPLICIT OCTET STRING (SIZE (8))\r\n\r\n Float128 ::=\r\n [APPLICATION 14]\r\n IMPLICIT OCTET STRING (SIZE (16))\r\n\r\n", "notes": "", "submit_date": "2005-02-13", "submitter_name": "Michael Kirkham", "verifier_id": "", "verifier_name": "Bob Braden", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "734", "doc-id": "RFC3970", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5, page 16", "orig_text": " teTunnelLPOctets OBJECT-TYPE\r\n SYNTAX Counter32\r\n MAX-ACCESS read-only\r\n STATUS current\r\n DESCRIPTION \"The number of octets that have been forwarded over\r\n the Tunnel.\r\n\r\n Discontinuities in the value of this counter can\r\n occur at re-initialization of the management system\r\n and at other times, as indicated by the value of\r\n teTunnelDiscontinuityTimer.\r\n \"\r\n ::= { teTunnelEntry 14 }\r\n\r\n teTunnelLPPackets OBJECT-TYPE\r\n SYNTAX Counter32\r\n MAX-ACCESS read-only\r\n STATUS current\r\n DESCRIPTION \"The number of packets that have been forwarded over\r\n the Tunnel.\r\n Discontinuities in the value of this counter can\r\n occur at re-initialization of the management system\r\n and at other times, as indicated by the value of\r\n teTunnelDiscontinuityTimer.\r\n \"\r\n ::= { teTunnelEntry 15 }", "correct_text": "[not submitted]", "notes": "The DESCRIPTION clauses of\r\n - teTunnelOctects and teTunnelLPOctects\r\n - teTunnelPackets and teTunnelLPPackets\r\nare pairwise identical, respectively.\r\n\r\nThere is no precise description of the precise meaning of\r\nthese \"teTunnelLPxxx\" objects.\r\nAdmittedly, one might guess from the SYNTAX clauses of these\r\nobjects that \"LP\" stands for 'lower part' -- meaning that the\r\nvalue of a \"teTunnelLPOctets\" object should always equal the\r\nvalue of the corresponding \"teTunnelOctets\" object MODULO 2^32\r\n(and similarly for the \"...Packets\" objects), but this is not\r\nstated in the text.\r\n\r\nFurthermore, unfortunately the naming of these objects does\r\nnot conform to the conventional naming style used in (almost)\r\nall IETF standards track MIB modules with High Capacity\r\ncounters, e. g. \"xxxOctets\" and \"xxxHCOctets\" .\r\nThe above interpretation would be more manifest if this\r\nstandard naming convention would have been followed.\r\n\r\nNow, given that the naming of the objects cannot be changed\r\nany more, it would certainly be useful to have a textual\r\nclarification of these DESCRIPTIONs posted on the RFC Editor's\r\nRFC-Errata web page.\r\n\r\n[from pending]", "submit_date": "2005-02-25", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "joel jaeggli", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "735", "doc-id": "RFC4591", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.3", "orig_text": " With L2TPv3 as the tunneling protocol, the packet resulted from the\r\n encapsulation is N bytes longer than Frame Relay frame without the\r\n opening and closing HDLC flags or FCS. The value of N depends on the\r\n following fields:\r\n\r\n", "correct_text": " With L2TPv3 as the tunneling protocol, the packet resulting from the\r\n encapsulation is N bytes longer than the Frame Relay frame without\r\n the opening and closing HDLC flags or FCS. The value of N depends on\r\n the following fields:\r\n", "notes": "", "submit_date": "2006-08-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "736", "doc-id": "RFC4550", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.2", "orig_text": " [IMAP-DISC] Melnikov, A., \"Synchronization operations for\r\n disconnected IMAP4 clients\", Work in Progress, October\r\n 2004.\r\n", "correct_text": " [IMAP-DISC] Melnikov, A., Ed., \"Synchronization Operations for \r\n Disconnected IMAP4 Clients\", RFC 4549, June 2006.\r\n\r\n\r\n", "notes": "This I-D has been published -- synchronized with RFC 4550 -- as RFC 4549. \r\n\r\nfrom pending", "submit_date": "2006-08-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "737", "doc-id": "RFC3816", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "1a)\r\n Section 4.1.2., near the bottom of page 5, says:\r\n\r\n \"... But when\r\n accessing the rohcInstanceTable (and the rohcContextTable that shares\r\n a part of its index with the rohcInstanceTable) there are many cases\r\n where either a compressor contexts or a decompressor contexts are of\r\n interest. ...\"\r\n\r\n It should say:\r\n\r\n \"... But when\r\n accessing the rohcInstanceTable (and the rohcContextTable that shares\r\n a part of its index with the rohcInstanceTable) there are many cases\r\n| where either a compressor context or a decompressor context are of\r\n interest. ...\"\r\n\r\n1b)\r\n Section 4.3.1., near the bottom of page 8, says:\r\n\r\n \"... For compressor contexts it optionally contains\r\n managed object containing the numbers of allowed and used packet\r\n sizes. ...\"\r\n\r\n It should say:\r\n\r\n \"... For compressor contexts it optionally contains\r\n| managed objects containing the numbers of allowed and used packet\r\n sizes. ...\"\r\n\r\n\r\n2) Textual issues in the ROHC-MIB definition\r\n\r\n2a)\r\n The DESCRIPTION clause of the `RohcChannelIdentifierOrZero'\r\n TEXTUAL-CONVENTION (near the bottom of page 10),\r\n\r\n \"A number identifying a channel.\r\n The value of 0 is indicates that\r\n no channel is identified.\"\r\n\r\n should be:\r\n\r\n \"A number identifying a channel.\r\n| The value of 0 indicates that\r\n no channel is identified.\"\r\n\r\n2b)\r\n The DESCRIPTION clause for `rohcChannelEntry' (extending from\r\n the last 2 lines on page 11 to page 12) contains inappropriate\r\n text -- obviously borrowed from the Script MIB (RFC 3165,\r\n page 18, last 3 lines) and unintentionally left un-edited:\r\n\r\n \"An entry describing a particular script. Every script that\r\n is stored in non-volatile memory is required to appear in\r\n this script table.\r\n\r\n Note ...\"\r\n\r\n This should be replaced by appropriate text, e.g.,\r\n\r\n| \"An entry describing a particular ROHC channel.\r\n\r\n Note ...\"\r\n\r\n [ Please add whatever you consider appropriate here! ]\r\n\r\n2c)\r\n The DESCRIPTION clause for `rohcChannelFeedbackFor', on page 13,\r\n seems to me to be not strict enough. Perhaps,\r\n\r\n \"If no feedback information is transferred on this channel,\r\n then the value of this ID is 0. If the channel type is set\r\n to notInUse(1), then the value of this object must be 0.\r\n If the channel type is rohc(2) and the value of this object\r\n is a valid channel ID, then feedback information is\r\n piggy-backed on the ROHC channel. If the channel type is\r\n\r\n should be replaced by:\r\n\r\n \"If no feedback information is transferred on this channel,\r\n then the value of this ID is 0. If the channel type is set\r\n to notInUse(1), then the value of this object must be 0.\r\n If the channel type is rohc(2) and the value of this object\r\n| is non-zero, then feedback information for this channel is\r\n| piggy-backed and/or interspersed on the same ROHC channel;\r\n| hence the value of this object must be equal to the value\r\n| of the indexing rohcChannelID. If the channel type is\r\n dedicatedFeedback(3), ...\"\r\n\r\n [or similar].\r\n\r\n Rationale:\r\n As far as I understand RFC 3095 (Section 5.2.2 et al.),\r\n it is not possible to intersperse or/and piggyback feedback\r\n information of another channel on a ROHC channel carrying\r\n payload packets.\r\n\r\n2d)\r\n The DESCRIPTION clause for `rohcInstanceVendor', on page 15,\r\n contains two issues. Its first sentence contains the word\r\n \"description\" instead of \"compression\", and the second sentence\r\n is subject to mis-interpretation due to unfortunate placement of\r\n the words \"allocated for the vendor\".\r\n I propose to change the text:\r\n\r\n \"An object identifier that identifies the vendor who\r\n provides the implementation of robust header description.\r\n This object identifier SHALL point to the object identifier\r\n directly below the enterprise object identifier\r\n {1 3 6 1 4 1} allocated for the vendor. ...\r\n\r\n to better read:\r\n\r\n \"An object identifier that identifies the vendor who\r\n| provides the implementation of robust header compression.\r\n This object identifier SHALL point to the object identifier\r\n| allocated for the vendor directly below the `enterprise'\r\n| object identifier {1 3 6 1 4 1}. ...\r\n\r\n\r\n2e)\r\n The DESCRIPTION clause for `rohcInstanceContextStorageTime',\r\n on page 17, says:\r\n\r\n ... . The value of this object is used\r\n to initialize rohcContexStorageTime object when a new\r\n context is created.\r\n Changing ...\r\n\r\n where it should better say:\r\n\r\n ... . The value of this object is used\r\n| to initialize the rohcContexStorageTime object when a new\r\n context is created.\r\n Changing ...\r\n\r\n2f)\r\n To better distinguish the counters for payload (i. e. IP) packets\r\n from the counters IR packets, I recommend to enhance the sentence:\r\n\r\n \"Counter of all packets passing this instance.\"\r\n\r\n to read:\r\n\r\n| \"Counter of all IP packets passing this instance.\"\r\n\r\n in the DESCRIPTION clauses of following two objects:\r\n\r\n o `rohcInstancePackets' (page 18),\r\n o `rohcContextPackets' (page 25).\r\n\r\n2g)\r\n The DESCRIPTION clause for `rohcProfileVendor', on page 21,\r\n contains the same two issues as the DESCRIPTION clause for\r\n `rohcInstanceVendor'. Hence, the modification given above,\r\n under 2d), should be applied here as well.\r\n\r\n2h)\r\n The DESCRIPTION clause for `rohcProfileNegotiated', on page 21,\r\n contains a small typo. It says:\r\n\r\n \"When retrieved, this boolean object returns true\r\n if the profile has been negotiated to be used at\r\n the instance, i.e., is supported also be the\r\n corresponding compressor/decompressor.\"\r\n\r\n It should say:\r\n\r\n \"When retrieved, this boolean object returns true\r\n if the profile has been negotiated to be used at\r\n| the instance, i.e., is supported also by the\r\n corresponding compressor/decompressor.\"\r\n\r\n2i)\r\n The DESCRIPTION clause for `rohcContextStorageTime', on page 24,\r\n contains an improper self-reference. Therefore, replace the text:\r\n\r\n ... . This object returns the remaining time\r\n that the row may exist before it is aged out. The object\r\n is initialized with the value of the associated\r\n rohcContextStorageTime object. After expiration ...\r\n\r\n by:\r\n\r\n ... . This object returns the remaining time\r\n that the row may exist before it is aged out. The object\r\n is initialized with the value of the associated\r\n| rohcInstanceContextStorageTime object. After expiration ...\r\n\r\n ^^^^^^^^\r\n\r\n2j)\r\n The DESCRIPTION clauses for `ContextAllPacketsMeanSize' and\r\n `rohcContextAllHeadersMeanSize', on page 28, are concluded with\r\n the sentence:\r\n\r\n The mean value is given in byte rounded to the next\r\n integer value.\"\r\n\r\n This should be:\r\n\r\n The mean value is given in bytes rounded to the next\r\n integer value.\"\r\n\r\n [ Note: I wished this RFC (and many other MIB RFCs, too) would\r\n make frequent use of the UNITS clause specified in STD 58 ! ]\r\n\r\n\r\n3) Textual issues in the ROHC-RTP-MIB definition\r\n\r\n3a)\r\n The DESCRIPTION clause for `rohcRtpContextNACKs', on page 42,\r\n says:\r\n\r\n \"The number of all dynamic negative feedbacks (ACK) sent\r\n or received in this context, respectively.\r\n ...\"\r\n\r\n It should say:\r\n\r\n| \"The number of all dynamic negative feedbacks (NACK) sent\r\n or received in this context, respectively.\r\n ...\"\r\n\r\n3b)\r\n The DESCRIPTION clause for `rohcRtpContextSNACKs', on page 42,\r\n says:\r\n\r\n \"The number of all static negative feedbacks (ACK) sent\r\n or received in this context, respectively.\r\n ...\"\r\n\r\n It should say:\r\n\r\n| \"The number of all static negative feedbacks (STATIC-NACK)\r\n| sent or received in this context, respectively.\r\n ...\"", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2005-02-23", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "738", "doc-id": "RFC4595", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7.1", "orig_text": " [NIST.180-1.1995]\r\n National Institute of Standards and Technology, \"Secure\r\n Hash Standard\", NIST 180-1, April 1995.", "correct_text": " [NIST.180-2.2002]\r\n National Institute of Standards and Technology, \"Secure\r\n Hash Standard\", NIST 180-2, August 2002.", "notes": "The current revision of the NIST's Secure Hash Standard is\r\n \"FIPS-PUB 180-2 + Change Notice 1\",\r\nissued \"2004 Feb 25\", which has added SHA-224 to the repertoire.\r\n\r\nIf NIST publications are used as References in IETF publications,\r\ncurrent revisions should be used.\r\n\r\nIn the case of SHA-1, perhaps preferrably, RFC 3174 is available\r\nas a (secondary) dedicated reference that will not change.", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "745", "doc-id": "RFC4427", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.3", "orig_text": " At the egress node, the normal traffic is selected\r\n| from either its working or one of the protection LSP/span.\r\n\r\n Unprotected extra traffic can be transported over the M protection\r\n| LSP/span whenever the protection LSPs/spans is not used to carry a\r\n normal traffic.\r\n", "correct_text": " At the egress node, the normal traffic is selected\r\n| from either its working or one of the protection LSPs/spans.\r\n\r\n Unprotected extra traffic can be transported over the M protection\r\n| LSPs/spans whenever the protection LSPs/spans is not used to carry a\r\n normal traffic.\r\n", "notes": "singular-->plural\r\n\r\nfrom pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dimitri Papadimitriou", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "747", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "The Description of SHA224_256ProcessMessageBlock, on top of page 42,\r\nsays:\r\n\r\n * Description:\r\n * This function will process the next 512 bits of the message\r\n * stored in the Message_Block array.\r\n\r\nConsistently with the remainder of the test, it should say:\r\n\r\n * Description:\r\n|* This helper function will process the next 512 bits of the\r\n * message stored in the Message_Block array.\r\n", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "1061", "doc-id": "RFC4646", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1", "orig_text": "ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26\r\nUNICHAR = \"&#x\" 2*6HEXDIG \";\"", "correct_text": "ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26\r\nUNICHAR = %x26.23.78 2*6HEXDIG \";\" ; starts with \"&#x\" ", "notes": "It has to be a lower case \"x\", i.e. %x78 in RFC 5234 ABNF.\r\n(All quoted strings in ABNF are case-insensitive.)", "submit_date": "2007-11-09", "submitter_name": "Frank Ellermann", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "1102", "doc-id": "RFC4601", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "List of Figu", "orig_text": "Figure 10. Per-interface (S,G) Assert State machine ...............84", "correct_text": "Figure 10. Per-interface (S,G) Assert State machine ............84-85", "notes": "Figure 1 occurs on pages 84-85, is listed as occurring on page 84.\n --VERIFIER NOTES-- \nList of figures is like a table of contents and only needs to point to the first page on which the figure can be found.", "submit_date": "2007-12-21", "submitter_name": "Maren Peasley", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "739", "doc-id": "RFC4584", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "All instances of", "orig_text": "IPV6 and ICMPV6\r\n\r\nFor example, in section 5:\r\n\r\n Legacy IPv6 applications/implementations using the Advanced Socket\r\n API [1] mechanisms, upon receiving Home Address destination options\r\n or Routing headers(Type 2), will discard the packet as per Sections\r\n 4.2 and 4.4 of IPV6 Protocol [3] specification, respectively;\r\n otherwise, they should properly handle the Home Address destination\r\n option and the Routing Header Type 2 specified in this document.", "correct_text": "IPv6 and ICMPv6\r\n\r\nFor example, should say (also incorporating other corrections):\r\n\r\n Legacy IPv6 applications/implementations using the Advanced Socket\r\n API [1] mechanisms, upon receiving Home Address destination options\r\n or Routing headers (Type 2), will discard the packet as per Sections\r\n 4.2 and 4.4 of the IPv6 Protocol [3] specification, respectively;\r\n otherwise, they should properly handle the Home Address destination\r\n option and the Routing Header Type 2 specified in this document.\r\n", "notes": "unusual capitalization\r\n\r\nOther places affected are:\r\n Section 5.1, 1st paragraph (page 17);\r\n Section 5.3, 1st paragraph (page 19);\r\n Section 6.1, 1st paragraph (page 21)\r\n\r\nfrom pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Samita Chakrabarti", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "740", "doc-id": "RFC4584", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.3", "orig_text": " Any user-level implementation or application that sends the Home\r\n address destination option through ancillary data objects should\r\n follow the order extension header defined in this document when using\r\n IPV6_MIPDSTOPTS socket options.", "correct_text": " Any user-level implementation or application that sends the Home\r\n address destination option through ancillary data objects should\r\n| follow the order of extension headers defined in this document when\r\n| using the IPV6_MIPDSTOPTS socket options.", "notes": "from pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Samita Chakrabarti", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "741", "doc-id": "RFC4584", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.1", "orig_text": " This specification recommends that the IPv6 RAW sockets mechanism\r\n send and receive Mobility Header (MH) packets. The behavior is\r\n| similar to ICMPV6 processing, where the kernel passes a copy of the\r\n mobility header packet to the receiving socket. Depending on the\r\n implementation, the kernel may process the mobility header in\r\n addition to passing the mobility header to the application. In order\r\n to comply with the restriction in the Advanced Sockets API for IPv6\r\n [1], applications should set the IPV6_CHECKSUM socket option with\r\n IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that\r\n supports the Mobile IPv6 API must implement Mobility Header API\r\n checksum calculations by default at the kernel for both incoming and\r\n outbound paths. A Mobile IPv6 implementation must not return error\r\n on the IPV6_CHECKSUM socket option setting, even if the socket option\r\n is a NO-OP function for that implementation because it verifies the\r\n checksum at the kernel level. The Mobility Header checksum procedure\r\n is described in the Mobile IPv6 Protocol [2] specification. Again,\r\n for application portability it is recommended that the applications\r\n set the IPV6_CHECKSUM socket option along with the RAW sockets for\r\n IPPROTO_MH protocol.", "correct_text": " This specification recommends that the IPv6 RAW sockets mechanism\r\n send and receive Mobility Header (MH) packets. The behavior is\r\n| similar to ICMPv6 processing; the kernel passes a copy of the\r\n mobility header packet to the receiving socket. Depending on the\r\n implementation, the kernel may process the mobility header in\r\n addition to passing the mobility header to the application. In order\r\n to comply with the restriction in the Advanced Sockets API for IPv6\r\n [1], applications should set the IPV6_CHECKSUM socket option with\r\n IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that\r\n supports the Mobile IPv6 API must implement Mobility Header API\r\n| checksum calculations by default in the kernel for both incoming and\r\n outbound paths. A Mobile IPv6 implementation must not return an\r\n error on the IPV6_CHECKSUM socket option setting, even if the socket\r\n option is a NO-OP function for that implementation because it\r\n verifies the checksum at the kernel level. The Mobility Header\r\n checksum procedure is described in the Mobile IPv6 Protocol [2]\r\n specification. Again, for application portability it is recommended\r\n that the applications set the IPV6_CHECKSUM socket option along with\r\n| the RAW sockets for the IPPROTO_MH protocol.", "notes": "misleading wording\r\n\r\nfrom pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Samita Chakrabarti", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "742", "doc-id": "RFC4379", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) [[posted separately.]]\r\n\r\n(2) Section 3.3.1 -- formating error\r\n\r\nThe second encoding diagram on page 27,\r\n\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0\r\n 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1\r\n 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1\r\n 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1\r\n 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1\r\n 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\nshould say:\r\n\r\n 0 1 2 3\r\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0|\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n\r\n\r\n(3) Section 4.4 -- word omission\r\n\r\nOn page 35, the RFC text contains the bullet:\r\n\r\n Best-return-code: contains the return code for the echo reply packet\r\n as currently best known. As algorithm progresses,\r\n this code may change depending on the results of\r\n further checks that it performs.\r\n\r\nIt should say:\r\n\r\n Best-return-code: contains the return code for the echo reply packet\r\n| as currently best known. As the algorithm\r\n progresses, this code may change depending on the\r\n results of further checks that it performs.\r\n\r\n\r\n(4) Section 4.4 -- word omission in pseudo-code comment\r\n\r\nOn page 38, within the pseudocode comment, the RFC says:\r\n\r\n [...]\r\n may be greater than Label-stack-depth. To be consistent with\r\n the above stack-depths, the bottom is considered to entry 1.\r\n */\r\n\r\nIt should say:\r\n\r\n [...]\r\n may be greater than Label-stack-depth. To be consistent with\r\n| the above stack-depths, the bottom is considered to be entry 1.\r\n */\r\n\r\n\r\n(5) Section 4.4 -- wrong internal section reference\r\n\r\nThe last paragraph of section 4.4 (Step 7.), on page 40, says:\r\n\r\n Send an MPLS echo reply with a Return Code of Best-return-code,\r\n and a Return Subcode of Best-rtn-subcode. Include any TLVs\r\n created during the above process. The procedures for sending\r\n| the echo reply are found in subsection 4.4.1.\r\n ^^^^^\r\nIt should say:\r\n\r\n Send an MPLS echo reply with a Return Code of Best-return-code,\r\n and a Return Subcode of Best-rtn-subcode. Include any TLVs\r\n created during the above process. The procedures for sending\r\n| the echo reply are found in subsection 4.5.\r\n\r\n\r\n(6) Section 5.1 -- outdated Normative Reference\r\n\r\nOn page 43, the tag [NTP] points to RFC 2030.\r\nAt the time of publication of RFC 4377, RFC 2030 already had been\r\nobsoleted by RFC 4330.\r\nTherefore, the text after [NTP] should be replaced by the\r\nrfc-ref.txt entry for RFC 4330.\r\n\r\n\r\n(7) Section 6 -- typo\r\n\r\nAt the end of the second paragraph on page 4, the RFC says:\r\n\r\n [...]. However, to provide a\r\n stronger defense, an implementation MAY also validate the TimeStamp\r\n| Sent by requiring and exact match on this field.\r\n ^\r\n\r\nIt should say:\r\n\r\n [...]. However, to provide a\r\n stronger defense, an implementation MAY also validate the TimeStamp\r\n| Sent by requiring an exact match on this field.", "correct_text": "", "notes": "from pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "743", "doc-id": "RFC4427", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": " Failure notification phase is used 1) to inform intermediate nodes\r\n that LSP(s)/span(s) failure has occurred and has been detected and 2)\r\n to inform the recovery deciding entities (which can correspond to any\r\n intermediate or end-point of the failed LSP/span) that the\r\n corresponding LSP/span is not available.", "correct_text": "| The failure notification phase is used 1) to inform intermediate\r\n nodes that LSP(s)/span(s) failure has occurred and has been detected\r\n and 2) to inform the recovery deciding entities (which can correspond\r\n to any intermediate or end-point of the failed LSP/span) that the\r\n corresponding LSP/span is not available.\r\n", "notes": "missing article\r\n\r\nfrom pending", "submit_date": "2006-08-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dimitri Papadimitriou", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "744", "doc-id": "RFC4302", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(1)\r\n\r\nRFC 4301, in section 13, \"Differences from RFC 2401\", in the\r\nsecond bulleted item (near the top of page 73) states:\r\n\r\n o There is no longer a requirement to support nested SAs or \"SA\r\n bundles\". [...]\r\n\r\nAnd later on, on page 74:\r\n\r\n o Support for AH in both IPv4 and IPv6 is no longer required.\r\n\r\nTherefore, the paragraph on page 10 of RFC 4302,\r\n\r\n ESP and AH headers can be combined in a variety of modes. The IPsec\r\n Architecture document describes the combinations of security\r\n associations that must be supported.\r\n ^^^^^^^^^^^^^^^^^\r\nentails more or less a \"NOPE\". If something like the second\r\nsentence is still desired, it might better say, e.g.,\r\n\r\n ESP and AH headers can be combined in a variety of modes. The IPsec\r\n Architecture document briefly describes the methods to configure\r\n such combinations of security associations.\r\n\r\n\r\n(2)\r\n\r\nOn page 25, Appendix A1 presents a table classifying the IPv4 options.\r\nWithin that table, the second column is partially misaligned.\r\n\r\n\r\n(3)\r\n\r\nOn page 26, the table within Appendix A2 classifying the IPv6\r\nextension headers,\r\n\r\n Option/Extension Name Reference\r\n ----------------------------------- ---------\r\n MUTABLE BUT PREDICTABLE -- included in ICV calculation\r\n Routing (Type 0) [DH98]\r\n\r\n BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING\r\n TRANSIT)\r\n Hop-by-Hop options [DH98]\r\n Destination options [DH98]\r\n\r\n NOT APPLICABLE\r\n Fragmentation [DH98]\r\n\r\nperhaps would have better been formatted like:\r\n\r\n Option/Extension Name Reference\r\n ----------------------------------- ---------\r\n MUTABLE BUT PREDICTABLE\r\n -- included in ICV calculation\r\n Routing (Type 0) [DH98]\r\n\r\n BIT INDICATES IF OPTION IS MUTABLE\r\n (CHANGES UNPREDICTABLY DURING TRANSIT)\r\n Hop-by-Hop options [DH98]\r\n Destination options [DH98]\r\n\r\n NOT APPLICABLE\r\n Fragmentation [DH98]\r\n\r\nto avoid the overlap of the columns.\r\n\r\n\r\n(4)\r\n\r\nIn Appendix B2.1, at one place on page 30, the variable\r\n\"seqh\" is mis-spelled as \"seqH\" (this is in the 6th-to-last\r\nline of Appendix B2.1).\r\n\r\n\r\n(5)\r\n\r\nAppendix B, as a whole, is a [near] duplicate of Appendix A of\r\nRFC 4303; the latter does not contain the typo from item (4)\r\nabove, and it contains extended and improved explanations in\r\nthe third subsection -- corresponding to page 32 of RFC 4302.\r\n\r\nReaders and potential implementors need to read both Appendices\r\njust to detect that they are in fact essentially the same spec.\r\n\r\nIMHO, it would have been better to avoid this re-specification,\r\nand instead have pointers to the (better, and mandatory!) ESP\r\nAppendix placed into the AH RFC.\r\nHaving a single specification always avoids disagreement or\r\ninconsistency, and it facilitates the maintenance of the spec.\r\n\r\n\r\n(6)\r\n\r\nFinally:\r\nI would have appreciated the introduction of an explicit version\r\nnumbering for AH, e.g. rename:\r\n AH as per RFC 1826 to AHv1,\r\n AH as per RFC 2402 to AHv2 or AHv2.0, and\r\n AH as per RFC 4302 to AHv3 or AHv2.1\r\n(or similar).\r\n\r\nThis would make it easier to specify / identify versions and/or\r\nversion specific behaviour in implementations, without having\r\nto refer to the RFC numbers explicitely. (Similar numbering has\r\nproven very useful with protocols like BGP, SNMP, IMAP, POP, etc.)", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2006-03-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3722", "doc-id": "RFC2445", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.8.7.3", "orig_text": "Conformance: This property can be specified in the \"EVENT\", \"VTODO\",\r\n\"VJOURNAL\" or \"VTIMEZONE\" calendar components.", "correct_text": "Conformance: This property can be specified in the \"VEVENT\", \"VTODO\",\r\n\"VJOURNAL\" or \"VTIMEZONE\" calendar components.", "notes": "Verifier notes:\r\nI'm marking this \"hold for document update\", according to the IESG's policy on errata\r\nhandling... but note that this document has already been updated: it is obsoleted by\r\nRFC 5545, and this version (RFC 2445) should no longer be used. (And this typo was\r\ncorrected in RFC 5545, I'm happy to say.)", "submit_date": "2013-09-11", "submitter_name": "Alfie John", "verifier_id": "", "verifier_name": "Barry Leiba", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "1103", "doc-id": "RFC4601", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "List of Figu", "orig_text": "Figure 11. Per-interface (*,G) Assert State machine ...............92", "correct_text": "Figure 11. Per-interface (*,G) Assert State machine ............92-93", "notes": "Figure 1 occurs on pages 92-93, is listed as occurring on page 92.\n --VERIFIER NOTES-- \nList of figures is like a table of contents and only needs to point to the first page on which the figure can be found.", "submit_date": "2007-12-21", "submitter_name": "Maren Peasley", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2432", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "The initial Description in this file, on page 45, says:\r\n\r\n * Description:\r\n * This file implements the Secure Hash Signature Standard\r\n * algorithms as defined in the National Institute of Standards\r\n * and Technology Federal Information Processing Standards\r\n * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2\r\n * published on August 1, 2002, and the FIPS PUB 180-2 Change\r\n * Notice published on February 28, 2004.\r\n\r\nIt should say:\r\n\r\n * Description:\r\n * This file implements the Secure Hash Algorithms SHA-384 and\r\n * SHA-512, as defined in the National Institute of Standards\r\n * and Technology Federal Information Processing Standards\r\n * Publication (FIPS PUB) 180-2 published on August 1, 2002, and\r\n * the FIPS PUB 180-2 Change Notice published on February 28, 2004.\r\n\r\nRationale:\r\n\r\nFIPS-PUB 180-1 only specified SHA-1, neither SHA-384 nor SHA-512.\r\nFIPS-PUB 180-2 has introduced SHA-384 and SHA-512 (and SHA-256 as\r\nwell), and the \"Change Notice 1\" has introduced SHA-224.\r\nThus, citation of FIPS PUB 180-1 is void and inappropriate in the\r\ncontext of SHA-384 and SHA-512.\r\nAvoiding the term \"Signature\" also conforms to the above Standards\r\n-- cf. item (4), (5), and (12) above.\r\nRestricting the text to the scope of the file -- cf. item (5) and\r\n(12) above.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2436", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "Within the '#ifndef USE_32BIT_ONLY' macro definition branch of the\r\nfile, on mid-page 51 the RFC says:\r\n\r\n/*\r\n * add \"length\" to the length\r\n */\r\nstatic uint64_t addTemp;\r\n#define SHA384_512AddLength(context, length) \\\r\n (addTemp = context->Length_Low, context->Corrupted = \\\r\n ((context->Length_Low += length) < addTemp) && \\\r\n (++context->Length_High == 0) ? 1 : 0)\r\n\r\nIt should say:\r\n\r\n/*\r\n * add \"length\" to the length\r\n */\r\nstatic uint64_t addTemp;\r\n#define SHA384_512AddLength(context, length) \\\r\n (addTemp = (context)->Length_Low, (context)->Corrupted = \\\r\n (((context)->Length_Low += length) < addTemp) && \\\r\n (++(context)->Length_High == 0) ? shaInputTooLong : shaSuccess )\r\n\r\nRationale:\r\n\r\nSame as for item (7) and (14) above, cf. item (26) as well.\r\n\r\nAdditionally, parentheses have been added around all invocations of\r\nthe macro argument `context` to protect it against various artifacts,\r\nas has been done consistently in the remainder of the sample code.\r\n", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2438", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "Similar to item (9), (16), (17), and (22) above, the Description\r\nof SHA384Result contains improper wording and unpleasent formatting.\r\nAdditionally, counting 48 elements as ranging from the \"0th\" up to the\r\n\"48th\" is unpleasant and wrong -- indicating 49 elements (octets) !\r\n\r\nNear the bottom of page 53, the RFC says:\r\n\r\n * Description:\r\n * This function will return the 384-bit message\r\n * digest into the Message_Digest array provided by the caller.\r\n * NOTE: The first octet of hash is stored in the 0th element,\r\n * the last octet of hash in the 48th element.\r\n\r\nFor correctness and consistency, and for improved readability,\r\nit should say:\r\n\r\n * Description:\r\n * This function will return the 384-bit message digest\r\n * into the Message_Digest array provided by the caller.\r\n * NOTE:\r\n * The first octet of the hash is stored in the element with index 0,\r\n * the last octet of the hash in the element with index 47.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2445", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.3", "orig_text": "On mid-page 75, the comment within the function hmacReset says:\r\n\r\n * The HMAC transform looks like:\r\n *\r\n * SHA(K XOR opad, SHA(K XOR ipad, text))\r\n *\r\n * where K is an n byte key.\r\n * ipad is the byte 0x36 repeated blocksize times\r\n * opad is the byte 0x5c repeated blocksize times\r\n * and text is the data being protected.\r\n\r\nIt should say:\r\n\r\n * The HMAC transform looks like:\r\n *\r\n * SHA(K XOR opad, SHA(K XOR ipad, text))\r\n *\r\n| * where K is an n byte key, 0-padded to a total of blocksize bytes,\r\n| * ipad is the byte 0x36 repeated blocksize times,\r\n| * opad is the byte 0x5c repeated blocksize times,\r\n * and text is the data being protected.\r\n\r\nRationale:\r\n\r\nWithout the addition, the 'XOR' operations in the formula are\r\nundefined. Additionally, punctuation is made uniform.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2447", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.4", "orig_text": "The initial Description of the file, as presented on page 78,\r\ncontains in its first paragraph the lines:\r\n\r\n * the seven tests documented for each algorithm in\r\n * \"The Secure Hash Algorithm Validation System (SHAVS)\",\r\n * three of which are bit-level tests\r\n * (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf)\r\n\r\nFor clarity, it should better say:\r\n\r\n * the seven tests documented for each algorithm in\r\n|* \"The Secure Hash Algorithm Validation System (SHAVS)\"\r\n|* (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf),\r\n|* three of which are bit-level tests\r\n", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2449", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.4", "orig_text": "On mid-page 91, there is the comment:\r\n\r\n/*\r\n * Print the string, converting non-printable characters to hex \"## \".\r\n */\r\n\r\nIt should say:\r\n\r\n/*\r\n * Print the string, converting all characters to hex \"## \".\r\n */\r\n\r\nRationale:\r\n\r\nThere is a significant mismatch between the comment and the\r\nsubsequent code.\r\nThis is being resolved by the replacement text.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "892", "doc-id": "RFC2616", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.4", "orig_text": "4. If the message uses the media type \"multipart/byteranges\", and the\r\n ransfer-length is not otherwise specified, then this self-\r\n elimiting media type defines the transfer-length.", "correct_text": "4. If the message uses the media type \"multipart/byteranges\", and the\r\n transfer-length is not otherwise specified, then this self-\r\n elimiting media type defines the transfer-length.\r\n", "notes": "", "submit_date": "2006-10-31", "submitter_name": "WooJin Chung", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "893", "doc-id": "RFC4698", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4", "orig_text": "If there are exact\r\nmatch networks in the set from (1), they both must appear in the\r\nresult set. ", "correct_text": "If there are exact\r\nmatch networks in the set from (1), they all must appear in the\r\nresult set. ", "notes": "from pending", "submit_date": "2006-11-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "1104", "doc-id": "RFC4601", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1.6", "orig_text": "immediate_olist(*,G) =\r\n joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)\r\n", "correct_text": "immediate_olist(*,G) =\r\n ( joins(*,G) (+) pim_include(*,G) ) (-) lost_assert(*,G)\r\n\r\n-or-\r\n\r\nimmediate_olist(*,G) =\r\n joins(*,G) (+) ( pim_include(*,G) (-) lost_assert(*,G) )\r\n", "notes": "Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).", "submit_date": "2007-12-21", "submitter_name": "Maren Peasley", "verifier_id": "", "verifier_name": "David Ward", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2478", "doc-id": "RFC5938", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.2 and 3.4", "orig_text": "a) [[ second-to-last para of Section 3.2: ]]\r\n\r\n The Server MUST respond with one or more Start-N-Ack messages (which\r\n SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL\r\n| have the format defined in the next session.\r\n ^^\r\n\r\nb) [[ last para of Section 3.4: ]]\r\n\r\n The Server MUST respond with one or more Stop-N-Ack messages (which\r\n SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL\r\n| have the format defined in the next session.\r\n ^^", "correct_text": "a)\r\n\r\n The Server MUST respond with one or more Start-N-Ack messages (which\r\n SHOULD be sent as quickly as possible). Start-N-Ack messages SHALL\r\n| have the format defined in the next section.\r\n ^^\r\n\r\nb)\r\n\r\n The Server MUST respond with one or more Stop-N-Ack messages (which\r\n SHOULD be sent as quickly as possible). Stop-N-Ack messages SHALL\r\n| have the format defined in the next section.\r\n ^^", "notes": "Rationale: potentially confusing typo (iterated)!", "submit_date": "2010-08-19", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "748", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "Similar to item (9), (16), (17), (22), and (29) above, the Description\r\nof SHA512Result contains improper wording and unpleasent formatting.\r\nAdditionally, counting 64 elements as ranging from the \"0th\" up to the\r\n\"64th\" is unpleasant and wrong -- indicating 65 elements (octets) !\r\n\r\nNear the bottom of page 44, the RFC says:\r\n\r\n * Description:\r\n * This function will return the 512-bit message\r\n * digest into the Message_Digest array provided by the caller.\r\n * NOTE: The first octet of hash is stored in the 0th element,\r\n * the last octet of hash in the 64th element.\r\n\r\n\r\nFor correctness and consistency, and for improved readability,\r\nit should say:\r\n\r\n * Description:\r\n * This function will return the 512-bit message digest\r\n * into the Message_Digest array provided by the caller.\r\n * NOTE:\r\n * The first octet of the hash is stored in the element with index 0,\r\n * the last octet of the hash in the element with index 63.\r\n\r\n", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2439", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.2.3", "orig_text": "The Description of SHA384_512PadMessage, on page 58, says:\r\n\r\n * Description:\r\n * According to the standard, the message must be padded to an\r\n * even 1024 bits. The first padding bit must be a '1'. The\r\n * last 128 bits represent the length of the original message.\r\n * All bits in between should be 0. This helper function will\r\n * pad the message according to those rules by filling the\r\n * Message_Block array accordingly. When it returns, it can be\r\n * assumed that the message digest has been computed.\r\n\r\nFor clarity, it should say (cf. items (10) and (19) above):\r\n\r\n * Description:\r\n|* According to the standard, the message must be padded to the next\r\n|* proper multiple of 1024 bits. The first padding bit must be a '1'.\r\n * The last 128 bits represent the length of the original message.\r\n * All bits in between should be 0. This helper function will\r\n * pad the message according to those rules by filling the\r\n * Message_Block array accordingly. When it returns, it can be\r\n * assumed that the message digest has been computed.", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2443", "doc-id": "RFC4634", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8.3", "orig_text": "The code for (the message oriented) function hmac,\r\non page 73/74, reads:\r\n\r\nint hmac(SHAversion whichSha, const unsigned char *text, int text_len,\r\n const unsigned char *key, int key_len,\r\n uint8_t digest[USHAMaxHashSize])\r\n<< page break >>\r\n{\r\n HMACContext ctx;\r\n return hmacReset(&ctx, whichSha, key, key_len) ||\r\n hmacInput(&ctx, text, text_len) ||\r\n hmacResult(&ctx, digest);\r\n}\r\n\r\nIt should say:\r\n\r\nint hmac(SHAversion whichSha,\r\n const unsigned char *message_array, int length,\r\n const unsigned char *key, int key_len,\r\n uint8_t digest[USHAMaxHashSize])\r\n<< page break >>\r\n{\r\n HMACContext ctx;\r\n return hmacReset(&ctx, whichSha, key, key_len) ||\r\n hmacInput(&ctx, message_array, length) ||\r\n hmacResult(&ctx, digest);\r\n}\r\n\r\nRationale:\r\n\r\nThe argument names `message_array` and `length` are used\r\nthroughout the sample code, including the Description of the\r\nfunction hmac, on page 73.\r\nThe code shown above was not aligned with this practise and\r\nhence inconsistent with the Description.\r\nThis has been resolved by the proposed update, bay changing\r\nthe names of 'text' and 'text_len'.\r\n\r\n>>>>> NOTE / Caution :\r\n>>>>>\r\n>>>>> Similar (and additional) inconsistencies between the\r\n>>>>> argument names in the 'Parameters:' documentation\r\n>>>>> and the variable names used in the subsequent code\r\n>>>>> exist for all hmac* functions, on pages 74..77 ;\r\n>>>>> in particular, the described 'context' is always\r\n>>>>> named `ctx` in the code.\r\n>>>>> Also, capitalization of the leading \"HMAC\"/\"hmac\"\r\n>>>>> in the function names is totally inconsistent.\r\n>>>>>\r\n>>>>> Resolution of these issues is left as an exercise\r\n>>>>> to the reader of this note -- or the author of any\r\n>>>>> future update of the sample code.\r\n>>>>>\r\n>>>>> Furthermore, the use of \"characters\" as units of the\r\n>>>>> message_text in the descriptions is dangerous in the\r\n>>>>> days of Unicode and UTF-8; \"characters\" should better\r\n>>>>> be replaced by \"octets\" throughout hmac.c !\r\n", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2456", "doc-id": "RFC4322", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "11.2", "orig_text": "Within the details of step 5, the text on page 38, lacks of a\r\nsub-step label.\r\nThe text,\r\n\r\n (5J) DNS replies with public key of initiator.\r\n Upon successfully authenticating the peer, the connection\r\n instance makes a transition to authenticated OE peer on SG-B.\r\n The format of the TXT record returned is described in\r\n Section 5.2.\r\n Responder replies with ID and authentication.\r\n SG-B sends its ID along with authentication material, completing\r\n the phase 1 negotiation.\r\n (5L) IKE phase 2 negotiation.\r\n [...]\r\n\r\nshould say:\r\n\r\n (5J) DNS replies with public key of initiator.\r\n Upon successfully authenticating the peer, the connection\r\n instance makes a transition to authenticated OE peer on SG-B.\r\n The format of the TXT record returned is described in\r\n Section 5.2.\r\n| (5K) Responder replies with ID and authentication.\r\n SG-B sends its ID along with authentication material, completing\r\n the phase 1 negotiation.\r\n (5L) IKE phase 2 negotiation.\r\n [...]", "correct_text": "", "notes": "To facilitate the recognition of the text changes proposed,\r\nI have added change bars ('|') in column 1, and up/down pointing\r\nmarker lines ('^^^'/'vvv').", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2458", "doc-id": "RFC4322", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "12.3", "orig_text": "The second paragraph of Section 12.3 (on page 41) says:\r\n\r\n The design of ISAKMP/IKE, and its use of cookies, defend against many\r\n kinds of denial of service. [...]\r\n\r\nIt should say:\r\n v\r\n| The design of ISAKMP/IKE, and its use of cookies, defends against\r\n many kinds of denial of service. [...]", "correct_text": "", "notes": "To facilitate the recognition of the text changes proposed,\r\nI have added change bars ('|') in column 1, and up/down pointing\r\nmarker lines ('^^^'/'vvv').", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "8627", "doc-id": "RFC1939", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7", "orig_text": "TOP msg n\r\n\r\n Arguments:\r\n a message-number (required) which may NOT refer to to a\r\n message marked as deleted, and a non-negative number\r\n of lines (required)", "correct_text": "TOP msg n\r\n\r\n Arguments:\r\n a message-number (required) which may NOT refer to a\r\n message marked as deleted, and a non-negative number\r\n of lines (required)", "notes": "Double consecutive appearance of word \"to\" in TOP arguments explanation.", "submit_date": "2025-11-05", "submitter_name": "Mikel Bernal", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2025-11-05 21:13:51"}, {"errata_id": "2472", "doc-id": "RFC3315", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "17.2.2", "orig_text": "If the server will not assign any addresses to any IAs in a\r\nsubsequent Request from the client, the server MUST send an Advertise\r\nmessage to the client that includes only a Status Code option with\r\ncode NoAddrsAvail and a status message for the user, a Server\r\nIdentifier option with the server's DUID, and a Client Identifier\r\noption with the client's DUID.", "correct_text": "If the server will not assign any addresses to an IA in a\r\nsubsequent Request from the client, the server MUST send an Advertise\r\nmessage to the client that includes the IA containing a Status Code \r\noption with status code NoAddrsAvail and a status message for the \r\nuser, a Server Identifier option with the server's DUID, and a Client \r\nIdentifier option with the client's DUID. The server SHOULD include \r\nother stateful IA options (like IA_PD) and other configuration options \r\nin the Advertise message.", "notes": "", "submit_date": "2010-08-17", "submitter_name": "Ole Troan", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2473", "doc-id": "RFC5918", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3, last para", "orig_text": " This document specifies one FEC Element Type instance (e.g., Prefix\r\n FEC) for the 'Typed Wildcard FEC Element' in Section 6.\r\n", "correct_text": " This document specifies one FEC Element Type instance (i.e., Prefix\r\n FEC) for the 'Typed Wildcard FEC Element' in Section 6.\r\n", "notes": "Adjust the semantics: s!e.g.!i.e.!", "submit_date": "2010-08-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2474", "doc-id": "RFC5918", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6, pg.7", "orig_text": "[[ below Figure 3: ]]\r\n\r\n Len FEC Type Info: Two octets. It MUST be set to 0x0002.\r\n", "correct_text": " Len FEC Type Info: One octet. It MUST be set to 0x02.\r\n", "notes": "The 'FEC Element Type' field is specified as a single octet in\r\nSection 3 (Figure 1 and subsequent field description on pg.4/5);\r\nFigure 3 also matches Figure 1.", "submit_date": "2010-08-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2475", "doc-id": "RFC5919", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5.3,1st para", "orig_text": " When an LDP speaker receives a Label Request message for a Typed\r\n| Wildcard FEC (e.g., a particular FEC Element Type) from a peer, the\r\n LDP speaker determines the set of bindings (as per any local\r\n filtering policy) to advertise to the peer for the FEC type specified\r\n by the request. [...]", "correct_text": " When an LDP speaker receives a Label Request message for a Typed\r\n| Wildcard FEC (i.e., a particular FEC Element Type) from a peer, the\r\n LDP speaker determines the set of bindings (as per any local\r\n filtering policy) to advertise to the peer for the FEC type specified\r\n by the request. [...]", "notes": "The parenthetical clause does not give an example, it gives\r\nan explanation; therefore, to avoid confusion, s!e.g.!i.e.!\r\n\r\nNote: Same issue as addressed by EID=2473 for RFC 5918.", "submit_date": "2010-08-19", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2476", "doc-id": "RFC5905", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "7.3.", "orig_text": "For instance, a value of -18 \r\ncorresponds to a precision of about one microsecond.", "correct_text": "For instance, a value of -20 \r\ncorresponds to a precision of about one microsecond.", "notes": "2**-20 = 0.954 usec\r\n2**-18 = 3.815 usec", "submit_date": "2010-08-19", "submitter_name": "Joerg Weilbier", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "3583", "doc-id": "RFC5520", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.2.3", "orig_text": "The format of a PCReq message is as follows:\r\n\r\n ::= \r\n []\r\n \r\n\r\n where:\r\n\r\n ::=[]\r\n ::=[]\r\n", "correct_text": "The format of a PCReq message is as follows:\r\n\r\n ::= \r\n []\r\n \r\n\r\n where:\r\n\r\n ::=[]\r\n ::=[]\r\n", "notes": "The corrected text is as RFC5440 section 6.4, the editorial difference is in RFC5520 and in RFC5440 is .", "submit_date": "2013-04-07", "submitter_name": "Abdussalam Baryun", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "770", "doc-id": "RFC3376", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "5.2", "orig_text": "If new query is Group and Source Specific query and there is pending \r\nresponse for this group and recorded source list for the group is empty \r\n(i.e. previous query was Group Specific query)", "correct_text": "[see note]", "notes": "In section 5.2 of RFC 3376, 5 sequential steps are given to handle the \r\nreceived query from the multicast router.\r\nI feel the following case is not handled properly in these steps (see above)\r\n\r\nIn this case, source list will be cleared as per step 4 of section 5.2. \r\nBut I feel the source list should be recorded to generate the report \r\naccordingly.\r\n\r\nfrom pending\n --VERIFIER NOTES-- \nThe RFC is correct in saying that recorded source-list should be cleared if the newly received query is group-specific query.", "submit_date": "2006-03-21", "submitter_name": "Rajesh Garg", "verifier_id": "", "verifier_name": "Adrian Farrel", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "771", "doc-id": "RFC4235", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.2", "orig_text": "direction=\"receiver\">", "correct_text": "direction=\"recipient\">", "notes": "Occurs on pages 28, 29 (2 times), and 30.\r\n\r\nThe proposed version of text is consistent with the rest of the document,\r\nincluding the schema in section 4.4.\r\n\r\nfrom pending", "submit_date": "2007-01-14", "submitter_name": "Nicolas-Peter Pohland", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "772", "doc-id": "RFC4048", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Section 4", "orig_text": "IANA Considerations, of RFC 4048 omitted to request IANA\r\nto release IPv6 option type code 11-0-00011 = 195 decimal, C3 hexadecimal.\r\n", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2005-07-28", "submitter_name": "Brian E Carpenter", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "773", "doc-id": "RFC3588", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "", "orig_text": "AVP Format\r\n\r\n ::=3D < AVP Header: 260 >\r\n 1* [ Vendor-Id ]\r\n 0*1{ Auth-Application-Id }\r\n 0*1{ Acct-Application-Id }", "correct_text": "", "notes": "for 1* [ Vendor-Id ], is it required or optional?=20\r\nIn my understanding, [ ] represent \"optional\", which means allowing none =\r\nof=20\r\nthis type AVP appear, but 1* means at least one needed, Is it =\r\ninconsistent?\r\nThe same problem for 0*1{ Auth-Application-Id } and 0*1{ =\r\nAcct-Application-Id }.\r\n\r\nCan it is be issued as RFC bug for RFC errata?\r\n\r\nfrom pending", "submit_date": "2006-04-13", "submitter_name": "Alan McNamee", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "774", "doc-id": "RFC4235", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.4", "orig_text": " 0)\r\n err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :\r\n USHAFinalBits(&sha, bits, bitcount);\r\n if (err != shaSuccess) {\r\n fprintf(stderr, \"hashfile(): %s Error %d.\\n\",\r\n keyarray ? \"hmacResult\" : \"shaResult\", err);\r\n if (hashfp != stdin) fclose(hashfp);\r\n return err;\r\n }\r\n\r\nshould in fact say:\r\n\r\n if (bitcount > 0)\r\n err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :\r\n USHAFinalBits(&sha, bits, bitcount);\r\n if (err != shaSuccess) {\r\n fprintf(stderr, \"hashfile(): %s Error %d.\\n\",\r\n keyarray ? \"hmacFinalBits\" : \"shaFinalBits\", err);\r\n if (hashfp != stdin) fclose(hashfp);\r\n return err;\r\n }\r\n\r\nRationale:\r\n\r\nSelf-evident; perhaps cloning error.\r\n", "correct_text": "", "notes": "", "submit_date": "2006-08-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2450", "doc-id": "RFC4322", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "1.2", "orig_text": "The 2nd paragraph on page 3 says:\r\n\r\n [...]. A future document [IPSECKEY] will describe\r\n a variation that complies with RFC 3445. [...]\r\n\r\nThe reference [IPSECKEY] has been updated before publication of\r\nRFC 4322 to point to RFC 4025 (cf. the first entry in Section 14.2,\r\non page 42). Hence this wording in not appropriate and inconsistent.\r\nThe text should say:\r\n vvvvvvvv vvv v\r\n| [...]. Another document [IPSECKEY] describes\r\n a variation that complies with RFC 3445. [...]", "correct_text": "", "notes": "To facilitate the recognition of the text changes proposed,\r\nI have added change bars ('|') in column 1, and up/down pointing\r\nmarker lines ('^^^'/'vvv').", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2451", "doc-id": "RFC4322", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "1.2", "orig_text": "The last paragraph of that section, on page 4, says:\r\n\r\n [...]. The\r\n mechanism described here, however, does provides an additional way to\r\n distribute the authentication materials; it is a public key method\r\n that does not require deployment of an X.509 based infrastructure.\r\n\r\nIt should say:\r\n vvv\r\n [...]. The\r\n| mechanism described here, however, does provide an additional way to\r\n distribute the authentication materials; it is a public key method\r\n that does not require deployment of an X.509 based infrastructure.", "correct_text": "", "notes": "To facilitate the recognition of the text changes proposed,\r\nI have added change bars ('|') in column 1, and up/down pointing\r\nmarker lines ('^^^'/'vvv').", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2457", "doc-id": "RFC4322", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "11.2", "orig_text": "The final paragraph of Section 11.2, on page 39, says:\r\n\r\n SG-A sends the datagram saved at step (5) through the newly\r\n created tunnel to SG-B, where it gets decrypted and forwarded.\r\n Bob receives it at (7) and replies at (8). SG-B already has a\r\n| tunnel up with G1 and uses it. [...]\r\n ^^\r\n\"G1\" is undefined; apparently, it should be \"SG-A\".\r\nHence, this snippit should say:\r\n\r\n SG-A sends the datagram saved at step (5) through the newly\r\n created tunnel to SG-B, where it gets decrypted and forwarded.\r\n Bob receives it at (7) and replies at (8). SG-B already has a\r\n| tunnel up with SG-A and uses it. [...]\r\n ^^^^", "correct_text": "", "notes": "To facilitate the recognition of the text changes proposed,\r\nI have added change bars ('|') in column 1, and up/down pointing\r\nmarker lines ('^^^'/'vvv').", "submit_date": "2006-03-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2465", "doc-id": "RFC3627", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.2", "orig_text": " [ICMPv3] Conta, A., Deering, S., \"Internet Control Message\r\n Protocol (ICMPv6)\", Work in Progress.\r\n", "correct_text": " [ICMPv6] Conta, A., Deering, S., \"Internet Control Message\r\n Protocol (ICMPv6)\", Work in Progress.\r\n", "notes": "Pointer to this reference should be fixed accordingly (i.e., s/ICMPv3/ICMPv6/ across the document)", "submit_date": "2010-08-15", "submitter_name": "Fernando Gont", "verifier_id": "", "verifier_name": "Nevil Brownlee", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2466", "doc-id": "RFC4291", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "2.2.2", "orig_text": "In order to make writing addresses containing zero\r\n bits easier, a special syntax is available to compress the zeros.\r\n The use of \"::\" indicates one or more groups of 16 bits of zeros.\r\n The \"::\" can only appear once in an address.", "correct_text": "In order to make writing addresses containing zero\r\n bits easier, a special syntax is available to compress the zeros.\r\n The use of \"::\" indicates two or more groups of 16 bits of zeros.\r\n The \"::\" can only appear once in an address.", "notes": " --VERIFIER NOTES-- \r\nBob Hinden evaluated this errata:\r\n\r\nI believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded: \r\n\r\n http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html\r\n\r\nThe thread starts at:\r\n\r\n http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html\r\n\r\nAlso, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.\r\n ", "submit_date": "2010-08-16", "submitter_name": "Michael Rushton", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2467", "doc-id": "RFC5321", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "4.1.3", "orig_text": " IPv6-comp = [IPv6-hex *5(\":\" IPv6-hex)] \"::\"\r\n [IPv6-hex *5(\":\" IPv6-hex)]\r\n ; The \"::\" represents at least 2 16-bit groups of\r\n ; zeros. No more than 6 groups in addition to the\r\n ; \"::\" may be present.\r\n\r\n IPv6v4-full = IPv6-hex 5(\":\" IPv6-hex) \":\" IPv4-address-literal\r\n\r\n IPv6v4-comp = [IPv6-hex *3(\":\" IPv6-hex)] \"::\"\r\n [IPv6-hex *3(\":\" IPv6-hex) \":\"]\r\n IPv4-address-literal\r\n ; The \"::\" represents at least 2 16-bit groups of\r\n ; zeros. No more than 4 groups in addition to the\r\n ; \"::\" and IPv4-address-literal may be present.", "correct_text": " IPv6-comp = [IPv6-hex *6(\":\" IPv6-hex)] \"::\"\r\n [IPv6-hex *6(\":\" IPv6-hex)]\r\n ; The \"::\" represents at least 1 16-bit groups of\r\n ; zeros. No more than 7 groups in addition to the\r\n ; \"::\" may be present.\r\n\r\n IPv6v4-full = IPv6-hex 5(\":\" IPv6-hex) \":\" IPv4-address-literal\r\n\r\n IPv6v4-comp = [IPv6-hex *4(\":\" IPv6-hex)] \"::\"\r\n [IPv6-hex *4(\":\" IPv6-hex) \":\"]\r\n IPv4-address-literal\r\n ; The \"::\" represents at least 1 16-bit groups of\r\n ; zeros. No more than 5 groups in addition to the\r\n ; \"::\" and IPv4-address-literal may be present.", "notes": "As per RFC 4291 and RFC 3986, \"::\" can represent a single 16-bit group of zeroes.\n --VERIFIER NOTES-- \nAs per RFC 5952:\r\n\r\n4.2.2. Handling One 16-Bit 0 Field\r\n\r\n The symbol \"::\" MUST NOT be used to shorten just one 16-bit 0 field.\r\n For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but\r\n 2001:db8::1:1:1:1:1 is not correct.", "submit_date": "2010-08-16", "submitter_name": "Michael Rushton", "verifier_id": "", "verifier_name": "Pete Resnick", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2468", "doc-id": "RFC3633", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "12.1 / 12.2", "orig_text": " Section 12.1:\r\n Upon the receipt of a valid Reply message, for each IA_PD the\r\n requesting router assigns a subnet from each of the delegated\r\n prefixes to each of the links to which the associated interfaces are\r\n attached, with the following exception: the requesting router MUST\r\n NOT assign any delegated prefixes or subnets from the delegated\r\n prefix(es) to the link through which it received the DHCP message\r\n from the delegating router.", "correct_text": " Section 12.1:\r\n Upon the receipt of a valid Reply message, for each IA_PD the\r\n requesting router assigns a subnet from each of the delegated\r\n prefixes to each of the links to which the associated interfaces are\r\n attached.\r\n\r\nNew last paragraph of 12.2:\r\n When the DR delegates prefixes to a Requesting Router, the\r\n Requesting Router has sole authority for assignment of those\r\n prefixes, and the Delegating Router MUST NOT assign any prefixes\r\n from that delegated prefix to any of its own links.", "notes": "This change clarifies that the authority over the address space is delegated to the RR (Requesting Router). Moving the use restriction for the address space from the DR (Delegating Router) to the RR (Requesting Router).\r\n\r\n2011-08-02: Notes updated per request from Ole Troan and Leaf Yeh.", "submit_date": "2010-08-17", "submitter_name": "Ole Troan", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2469", "doc-id": "RFC3633", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "11.1", "orig_text": "The requesting router MUST ignore any Advertise message that includes\r\na Status Code option containing the value NoPrefixAvail, with the\r\nexception that the requesting router MAY display the associated\r\nstatus message to the user.", "correct_text": "The requesting router MUST ignore any IA_PDs in an Advertise message\r\nthat includes a Status Code option containing the value NoPrefixAvail, \r\nwith the exception that the requesting router MAY display the \r\nassociated status message to the user.", "notes": "", "submit_date": "2010-08-17", "submitter_name": "Ole Troan", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "806", "doc-id": "RFC3454", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "Appendix C", "orig_text": "C. Prohibition tables\r\n\r\n The tables in this appendix consist of lines with one prohibited code\r\n point per line. The format of the lines are the value of the code\r\n point, a semicolon, and a comment which is the name of the code\r\n point.", "correct_text": "[see Notes]", "notes": "This is not true as the tables in this appendix consist of lines with\r\none prohibited code point _range_ per line. The format of the lines\r\nare the value of the starting code point of the range, a hyphen,\r\nthe value of the ending code point of the range, a semicolon,\r\nand a comment which is the informal name of the range in square brackets.\r\nIf the range contains only one code point, then the hyphen and the ending\r\ncode point value are omitted, and the comment contains the name of\r\nthe code point without brackets.\r\n\r\nfrom pending", "submit_date": "2006-04-27", "submitter_name": "Sergiusz Wolicki", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "807", "doc-id": "RFC4319", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": "[[Page 16, Hdsl2ShdslPerfCurrDayCount, second paragraph in the description]]\r\n\r\n Hdsl2Shdsl1DayIntevalCount, and the current interval gauge", "correct_text": " Hdsl2Shdsl1DayIntervalCount, and the current interval gauge", "notes": "from pending", "submit_date": "2007-01-07", "submitter_name": "Clay Sikes", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "808", "doc-id": "RFC4319", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": "[[Page 17, Hdsl2ShdslPerfIntervalThreshold , description]]\r\n\r\n a 15-minute interval numbers at most 900, objects of this", "correct_text": " a 15-minute interval numbers is at most 900, objects of this", "notes": "from pending", "submit_date": "2007-01-07", "submitter_name": "Clay Sikes", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "809", "doc-id": "RFC4567", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) [[posted separately.]]\r\n \r\n(2) inappropriate text (cut&paste error?)\r\n\r\nOn page 6, the explanation below the ABNF in Section 3.2 says:\r\n\r\n where KMPID is as defined in Section 3 of this memo, \"base64\" as\r\n defined in [SDPnew], and \"URI\" as defined in Section 3 of [RFC3986].\r\n\r\nIt should say:\r\n\r\n where KMPID is as defined in Section 3 of this memo and \"URI\" as\r\n defined in Section 3 of [RFC3986].\r\n\r\nRationale: \"base64\" does not appear in the ABNF of Section 3.2 !\r\n\r\n\r\n(3) incomplete sentence\r\n\r\nThe first paragraph of Section 4.1.1, on page 8, says:\r\n\r\n The processing when SDP is used is slightly different according to\r\n the way SDP is transported, and if it uses an offer/answer or\r\n announcement. The processing can be divided into four different\r\n steps:\r\n\r\nIt should say:\r\n\r\n The processing when SDP is used is slightly different according to\r\n the way SDP is transported, and if it uses an offer/answer or\r\n| announcement model. The processing can be divided into four\r\n different steps:\r\n\r\n\r\n(4) misleading word omission\r\n\r\nWithin Section 5.4, the explanation at top of page 21,\r\n\r\n Each RTSP header is inserted in the SETUP related to the audio and\r\n video separately:\r\n\r\nshould be clarified to say:\r\n\r\n| A key management RTSP header is inserted in the SETUP related to the\r\n audio and video separately:\r\n\r\n\r\n(5) suspected inconsistency\r\n\r\nThe last paragraph of Section 7, on page 22, says:\r\n\r\n The server will need to be able to know the identity of the client\r\n before creating and sending a MIKEY message. [...]\r\n\r\nIMHO, it is not clear how this fits with the text on page 14.\r\nPerhaps, a 3-way handshake with client auth in DESCRIBE could\r\nbe considered.\r\n\r\n\r\n(6) inconsistency between ABNF and IANA registrations\r\n\r\nPerhaps, a late change to the ABNF in the body of the RFC has lead\r\nto inconsistencies in the filled out IANA registration templates\r\nas presented in Section 9.1 and 9.3; in particular, the hypothetical\r\nattribute name \"key-mgmt-att-field\" referred to in fact should be just\r\n\"key-mgmt\"; \"key-mgmt-att-field\" is the name of the ABNF production\r\nrule (introduced in Section 3.1) for this literal; in the template\r\nthe literal name of the attribute is needed.\r\n\r\nTherefore:\r\n\r\nIn Section 9.1, near the bottom of page 25, change\r\n\r\n SDP Attribute Field (\"att-field\"):\r\n\r\n Name: key-mgmt-att-field\r\n\r\nto say:\r\n\r\n SDP Attribute Field (\"att-field\"):\r\n\r\n Name: key-mgmt\r\n\r\nand in Section 9.3, on page 26, change\r\n\r\n Purpose: Usage of MIKEY with the key-mgmt-att-field\r\n attribute and the keymgmt RTSP header\r\n\r\nto say:\r\n\r\n| Purpose: Usage of MIKEY with the key-mgmt SDP attribute\r\n and the keymgmt RTSP header\r\n\r\n[ I also have added \"SDP\" for additional clarification. ]\r\n\r\n\r\n(7) missing articles\r\n\r\nThe first paragraph of the Abstract, on page 1 of RFC 4567, says:\r\n\r\n This document defines general extensions for Session Description\r\n Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry\r\n messages, as specified by a key management protocol, in order to\r\n secure the media. [...]\r\n\r\nIt should say:\r\n\r\n| This document defines general extensions for the Session Description\r\n| Protocol (SDP) and the Real Time Streaming Protocol (RTSP) to carry\r\n messages, as specified by a key management protocol, in order to\r\n secure the media. [...]\r\n\r\n\r\n(8) missing article\r\n\r\nNear the top of page 7, the paragraph,\r\n\r\n We define one new RTSP status code to report error due to any failure\r\n during the key management processing (Section 4.2):\r\n\r\nshould say:\r\n\r\n| We define one new RTSP status code to report an error due to any\r\n failure during the key management processing (Section 4.2):\r\n\r\n\r\n(9) missing article\r\n\r\nWithin Section 4.2, the last bullet on page 15 says:\r\n\r\n * Key management responses for the initial establishment of security\r\n parameters for an individual media SHALL only be included in SETUP\r\n for the corresponding media stream.\r\n\r\nIt should say:\r\n\r\n * Key management responses for the initial establishment of security\r\n| parameters for an individual media SHALL only be included in the\r\n SETUP for the corresponding media stream.\r\n\r\n\r\n(10) typo (singular/plural mismatch)\r\n\r\nWithin Section 5.2, the explanation of the example, in the lower\r\nhalf of page 19,\r\n\r\n The client checks the validity of the received MIKEY message, and, in\r\n case of successful verification, it accept the message. [...]\r\n\r\nshould say:\r\n\r\n The client checks the validity of the received MIKEY message, and, in\r\n| case of successful verification, it accepts the message. [...]", "correct_text": "", "notes": "from pending", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "1259", "doc-id": "RFC5012", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "8, pg.19", "orig_text": " Ma14. Resilience to mapping server failure: The mapping protocol\r\n MUST support a mechanism that enables the client to fail over to\r\n different (replica) mapping server.\r\n", "correct_text": " Ma14. Resilience to mapping server failure: The mapping protocol\r\n| MUST support a mechanism that enables the client to fail over to a\r\n different (replica) mapping server.\r\n", "notes": "insert missing \"a\"", "submit_date": "2008-01-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "2470", "doc-id": "RFC3633", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "11.2", "orig_text": "If the delegating router will not assign any prefixes to any IA_PDs\r\nin a subsequent Request from the requesting router, the delegating\r\nrouter MUST send an Advertise message to the requesting router that\r\nincludes the IA_PD with no prefixes in the IA_PD and a Status Code\r\noption in the IA_PD containing status code NoPrefixAvail and a status\r\nmessage for the user, a Server Identifier option with the delegating\r\nrouter's DUID and a Client Identifier option with the requesting\r\nrouter's DUID.", "correct_text": "If the delegating router will not assign any prefixes to an IA_PD\r\nin a subsequent Request from the requesting router, the delegating\r\nrouter MUST send an Advertise message to the requesting router that\r\nincludes the IA_PD with no prefixes in the IA_PD and a Status Code\r\noption in the IA_PD containing status code NoPrefixAvail and a status\r\nmessage for the user, a Server Identifier option with the delegating\r\nrouter's DUID and a Client Identifier option with the requesting\r\nrouter's DUID. The server SHOULD include other stateful IA options\r\n(like IA_NA) and other configuration options in the Advertise message.", "notes": "Edited by Ralph Droms on 2010-08-20 to correct reference to IA_NA (was IA_PD) in last line.", "submit_date": "2010-08-17", "submitter_name": "Ole Troan", "verifier_id": "", "verifier_name": "Ralph Droms", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "751", "doc-id": "RFC4009", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(A)\r\n>\r\n> Unfortunately, within a few lines in the RFC text, the variable name 'X'\r\n> gets used for two very distinct purposes and contexts:\r\n>\r\n> o X = X0 || X1 || X2 || X3 (2)\r\n> ... the 32 bit wide input to the function G\r\n>\r\n> o X used as formal argument in the defining equations for\r\n> the 'SS-boxes' SS0 ... SS3\r\n> ... a single octet (8 bit wide entity),\r\n> [application of the formulas - see (3) below - will\r\n> substitute X0, ..., X3 in turn for the arguments]\r\n>\r\n> Perhaps, it would have been better to use another symbol, e.g. 'x', for the\r\n> latter purpose.\r\n>\r\n>\r\n> (B)\r\n>\r\n> As far as I can see, feeding the definition of the SS-boxes given in the\r\n> last 4 text/formule lines on page 3 into the formula on top of page 4,\r\n>\r\n> Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3)\r\n>\r\n> does ***NOT*** yield the same result as using the primary defining formulas\r\n> given for Z0 ... Z3 in the first formula block of section 2.2., together\r\n> with\r\n>\r\n> Z = Z0 || Z1 || Z2 || Z3 (1).\r\n>\r\n> I suspect a mis-ordering in the use of m0 ... m3 in the equations defining\r\n> SS0 ... SS3 :\r\n>\r\n> With regard to the formulas (1), (2), and (3) (as numbered above), the\r\n> 'matrix' pattern of the 4x4 terms in braces { ... } , obtained from the\r\n> formula block defining SS0 ... SS3 by substitution of Xi for the argument of\r\n> SSi (i=0,1,2,3) - as required in (3) -, should be the matrix transpose of\r\n> the pattern of the same terms in braces appearing in the formula block\r\n> defining Z0 ... Z3 , e. g. the first 'column' of {...} terms for SSi()\r\n> should contain the {...} terms appearing in the formula for Z0.\r\n> But this is not the case.\r\n>\r\n> Therefore, I suspect that the last 6 text/formula lines on page 3 of RFC\r\n> 4009 should in fact read (including the enhancement from (A)\r\n> above):\r\n>\r\n> \"\r\n> To increase the efficiency of the G function, four extended S-boxes\r\n> 'SS-box' (See Appendix A.2) are defined as follows:\r\n>\r\n> SS0(x)= {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3}\r\n> SS1(x)= {S2(x) & m1} || {S2(x) & m2} || {S2(x) & m3} || {S2(x) & m0}\r\n> SS2(x)= {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1}\r\n> SS3(x)= {S2(x) & m3} || {S2(x) & m0} || {S2(x) & m1} || {S2(x) & m2}\r\n> \"\r\n>\r\n>\r\n\r\n> In this case, I also recommend to include a textual enhancement for the\r\n> first sentence of section 2.3., replacing:\r\n>\r\n> \"The key schedule generates each round subkeys.\"\r\n> by:\r\n> \"The key schedule generates subkeys for each round.\"\r\n>\r\n> And finally, for completeness, it would have been useful as well to give\r\n> additional Informational Reference(s) for the seedMAC (and the\r\n> [seed]CBC) algorithm(s)/construct(s) mentioned in section 2.5. - e.g. RFC\r\n> 3610 (and RFC 2451 / NIST SP 800-38A) [?].", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2005-02-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "752", "doc-id": "RFC4009", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "(C)\r\n\r\nFirst, a formal issue with the ASN.1 given in the RFC text:\r\n\r\nIn the ASN.1 definitions in section 2.5., it would perhaps be more\r\nnatural and consistent with the requirements from the text (and the\r\nASN.1 comment already present there!) to give an explicit SIZE\r\nrestriction in the definition of the syntax of the initialization\r\nvector for SEED in CBC mode (which indeed *MUST* be 16 octets long).\r\nTo this end, I recommend to replace the 7th text line of section 2.5.,\r\n\r\n \"seedCDCParameter ::= OCTET STRING -- 128-bit Initialization Vector\"\r\n\r\nby:\r\n\r\n| \"seedCDCParameter ::= OCTET STRING (SIZE(16))\r\n| -- 128-bit Initialization Vector\"\r\n\r\n\r\n(D)\r\n\r\nThe text in section 2.2. talks about two basic 8x8 S-boxes, named\r\n\"S1\" and \"S2\". Contrary to that, Appendix A.1. (on page 7) gives\r\ntables for \"S-Box S0\" and \"S-Box S1\".\r\n\r\nIt would be easier to change the headlines in Appendix A.1.,\r\nbut, given the numbering style of all other formula elements,\r\nit is certainly be more appropriate and consistent to modify the\r\nequations in section 2.2., replacing \"S1\" by \"S0\", and \"S2\" by \"S1\".\r\n\r\nI'll give a full replacement text for section 2.2. below, covering\r\nthis issue as well.\r\n\r\n\r\n[ Now, returning to the open issue ... ]\r\n(B)\r\n\r\nIn short, sorry, I do NOT agree with your definition of the SS-boxes.\r\nIt does not conform with the primary definition of the function G.\r\n\r\nBelow, I'll give you a detailed step-by-step explanation, using a\r\nconcrete example, for the reasoning already presented in my first\r\nmail.\r\n\r\nNote: For brevity and due to the email line length restriction,\r\n in the subsequent reasoning, I will omit the braces '{ ... }'\r\n around the ANDed terms, making use of the usual precedence rule\r\n for multiplication over addition and the facts that\r\n - the '^' operation is the normal addition in the 8 / 32 dimensional\r\n vector spaces over GF(2) we are working on,\r\n - '&' representing the 8 / 32 fold tensor product of the scalar\r\n multiplication over GF(2) .\r\n\r\nI repeat and extend the numeration of the formulas from my first\r\nemail, already applying item (D).\r\n\r\n X = X0 || X1 || X2 || X3 (2)\r\n\r\n ... the 32 bit wide input to the function G;\r\n\r\n Z = Z0 || Z1 || Z2 || Z3 (1)\r\n\r\n ... the 32 bit wide output of the function G applied to X;\r\n with the 8-bit wide components computed by the application\r\n of the two S-Boxes S0 and S1 via the equations:\r\n\r\n Z0 = S0(X0) & m0 ^ S1(X1) & m1 ^ S0(X2) & m2 ^ S1(X3) & m3 (1.0)\r\n Z1 = S0(X0) & m1 ^ S1(X1) & m2 ^ S0(X2) & m3 ^ S1(X3) & m0 (1.1)\r\n Z2 = S0(X0) & m2 ^ S1(X1) & m3 ^ S0(X2) & m0 ^ S1(X3) & m1 (1.2)\r\n Z3 = S0(X0) & m3 ^ S1(X1) & m0 ^ S0(X2) & m1 ^ S1(X3) & m2 (1.3)\r\n\r\n with m0 = 0xFC , m1 = 0xF3 , m2 = 0xCF , and m3 = 0x3F (1.4)\r\n\r\n\r\nThe alternate description of the Function G is to be\r\n\r\n Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3)\r\n\r\nwhere, below, I'll try \"my\" version of the SS-Box definition ...\r\n\r\n SS0(x) = S0(x) & m0 || S0(x) & m1 || S0(x) & m2 || S0(x) & m3 (4.0)\r\n SS1(x) = S1(x) & m1 || S1(x) & m2 || S1(x) & m3 || S1(x) & m0 (4.1)\r\n SS2(x) = S0(x) & m2 || S0(x) & m3 || S0(x) & m0 || S0(x) & m1 (4.2)\r\n SS3(x) = S1(x) & m3 || S1(x) & m0 || S1(x) & m1 || S1(x) & m2 (4.3)\r\n\r\n... and the version from the text (with the formal changes already\r\n discussed properly applied) ...\r\n\r\n SS0(x) = S0(x) & m3 || S0(x) & m2 || S0(x) & m1 || S0(x) & m0 (5.0)\r\n SS1(x) = S1(x) & m0 || S1(x) & m3 || S1(x) & m2 || S1(x) & m1 (5.1)\r\n SS2(x) = S0(x) & m1 || S0(x) & m0 || S0(x) & m3 || S0(x) & m2 (5.2)\r\n SS3(x) = S1(x) & m2 || S1(x) & m1 || S1(x) & m0 || S1(x) & m3 (5.3)\r\n\r\n\r\nWith these notations, let's challenge the example octet sequence\r\n\r\n X0 = 0x09 , X1 = 0x11 , X2 = 0xE1 , X3 = 0xF9 (6a)\r\n\r\ni.e., by (2) : X = (0x) 09 11 E1 F9 (6b)\r\n\r\nApplying the tables from Appendix A.1., we obtain (*) :\r\n\r\n S0(X0) = 0x43 ,\r\n S1(X1) = 0x62 ,\r\n S0(X2) = 0xB9 ,\r\n S1(X3) = 0x4C .\r\n\r\n\r\nTo first compute Z with the original definition of G, substituting\r\n(*) and (1.4) into (1.0) .. (1.3), we obtain, step by step:\r\n\r\n Z0 = S0(X0) & m0 ^ S1(X1) & m1 ^ S0(X2) & m2 ^ S1(X3) & m3 (1.0)\r\n = 0x43 & 0xFC ^ 0x62 & 0xF3 ^ 0xB9 & 0xCF ^ 0x4C & 0x3F\r\n = 0x40 ^ 0x62 ^ 0x89 ^ 0x0C\r\n==>\r\n Z0 = 0xA7 (7.0)\r\n\r\n Z1 = S0(X0) & m1 ^ S1(X1) & m2 ^ S0(X2) & m3 ^ S1(X3) & m0 (1.1)\r\n = 0x43 & 0xF3 ^ 0x62 & 0xCF ^ 0xB9 & 0x3F ^ 0x4C & 0xFC\r\n = 0x43 ^ 0x42 ^ 0x39 ^ 0x4C\r\n==>\r\n Z1 = 0x74 (7.1)\r\n\r\n Z2 = S0(X0) & m2 ^ S1(X1) & m3 ^ S0(X2) & m0 ^ S1(X3) & m1 (1.2)\r\n = 0x43 & 0xCF ^ 0x62 & 0x3F ^ 0xB9 & 0xFC ^ 0x4C & 0xF3\r\n = 0x43 ^ 0x22 ^ 0xB8 ^ 0x40\r\n==>\r\n Z2 = 0x99 (7.2)\r\n\r\n Z3 = S0(X0) & m3 ^ S1(X1) & m0 ^ S0(X2) & m1 ^ S1(X3) & m2 (1.3)\r\n = 0x43 & 0x3F ^ 0x62 & 0xFC ^ 0xB9 & 0xF3 ^ 0x4C & 0xCF\r\n = 0x03 ^ 0x60 ^ 0xB1 ^ 0x4C\r\n==>\r\n Z3 = 0x9E (7.3)\r\n\r\nPutting (7.0) .. (7.3) together using (1), we get the byte sequence\r\n\r\n Z = Z0 || Z1 || Z2 || Z3 (1)\r\n==>\r\n Z = (0x) A7 74 99 9E (7)\r\n\r\n\r\nNow let's see what happens when we apply \"my\" definition of the\r\nSS-Boxes, substituting (6a), (*), and (1.4) into (4.0) .. (4.3) :\r\n\r\n SS0(X0) = S0(X0) & m0 || S0(X0) & m1 || S0(X0) & m2 || S0(X0) & m3\r\n = 0x43 & 0xFC || 0x43 & 0xF3 || 0x43 & 0xCF || 0x43 & 0x3F\r\n = 0x40 || 0x43 || 0x43 || 0x03\r\n==>\r\n SS0(X0) = (0x) 40 43 43 03 (8.0)\r\n\r\n SS1(X1) = S1(X1) & m1 || S1(X1) & m2 || S1(X1) & m3 || S1(X1) & m0\r\n = 0x62 & 0xF3 || 0x62 & 0xCF || 0x62 & 0x3F || 0x62 & 0xFC\r\n = 0x62 || 0x42 || 0x22 || 0x60\r\n==>\r\n SS1(X1) = (0x) 62 42 22 60 (8.1)\r\n\r\n SS2(X2) = S0(X2) & m2 || S0(X2) & m3 || S0(X2) & m0 || S0(X2) & m1\r\n = 0xB9 & 0xCF || 0xB9 & 0x3F || 0xB9 & 0xFC || 0xB9 & 0xF3\r\n = 0x89 || 0x39 || 0xB8 || 0xB1\r\n==>\r\n SS2(X2) = (0x) 89 39 B8 B1 (8.2)\r\n\r\n SS3(X3) = S1(X3) & m3 || S1(X3) & m0 || S1(X3) & m1 || S1(X3) & m2\r\n = 0x4C & 0x3F || 0x4C & 0xFC || 0x4C & 0xF3 || 0x4C & 0xCF\r\n = 0x0C || 0x4C || 0x40 || 0x4C\r\n==>\r\n SS3(X3) = (0x) 0C 4C 40 4C (8.3)\r\n\r\nNote: Please observe that the terms in (8.0) .. (8.3) are indeed\r\n the same terms as in (7.0) .. (7.3), but in 4x4 matrix transposed\r\n order -- as stated abstractly in my first email.\r\n\r\nSumming up (8.0) .. (8.3) according to (3), we get what should be\r\nthe alternate definition of G(X) :\r\n\r\n Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3)\r\n = (0x) 40 43 43 03 ^ -- from (8.0)\r\n (0x) 62 42 22 60 ^ -- from (8.1)\r\n (0x) 89 39 B8 B1 ^ -- from (8.2)\r\n (0x) 0C 4C 40 4C -- from (8.3)\r\n==> -----------\r\n Z = (0x) A7 74 99 9E (8)\r\n\r\nObviously, (8) indeed is identical to (7).\r\n\r\n\r\nFinally, let's look for what we get with your definition of the\r\nSS-Boxes, substituting (6a), (*), and (1.4) into (5.0) .. (5.3) :\r\n\r\n SS0(X0) = S0(X0) & m3 || S0(X0) & m2 || S0(X0) & m1 || S0(X0) & m0\r\n = 0x43 & 0x3F || 0x43 & 0xCF || 0x43 & 0xF3 || 0x43 & 0xFC\r\n = 0x03 || 0x43 || 0x43 || 0x40\r\n==>\r\n SS0(X0) = (0x) 03 43 43 40 (9.0)\r\n\r\n SS1(X1) = S1(X1) & m0 || S1(X1) & m3 || S1(X1) & m2 || S1(X1) & m1\r\n = 0x62 & 0xFC || 0x62 & 0x3F || 0x62 & 0xCF || 0x62 & 0xF3\r\n = 0x60 || 0x22 || 0x42 || 0x62\r\n==>\r\n SS1(X1) = (0x) 60 22 42 62 (9.1)\r\n\r\n SS2(X2) = S0(X2) & m1 || S0(X2) & m0 || S0(X2) & m3 || S0(X2) & m2\r\n = 0xB9 & 0xF3 || 0xB9 & 0xFC || 0xB9 & 0x3F || 0xB9 & 0xCF\r\n = 0xB1 || 0xB8 || 0x39 || 0x89\r\n==>\r\n SS2(X2) = (0x) B1 B8 39 89 (9.2)\r\n\r\n SS3(X3) = S1(X3) & m2 || S1(X3) & m1 || S1(X3) & m0 || S1(X3) & m3\r\n = 0x4C & 0xCF || 0x4C & 0xF3 || 0x4C & 0xFC || 0x4C & 0x3F\r\n = 0x4C || 0x40 || 0x4C || 0x0C\r\n==>\r\n SS3(X3) = (0x) 4C 40 4C 0C (8.3)\r\n\r\nSumming up (9.0) .. (9.3) according to (3), we get\r\n\r\n Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) (3)\r\n = (0x) 03 43 43 40 ^ -- from (9.0)\r\n (0x) 60 22 42 62 ^ -- from (9.1)\r\n (0x) B1 B8 39 89 ^ -- from (9.2)\r\n (0x) 4C 40 4C 0C -- from (9.3)\r\n==> -----------\r\n Z = (0x) 9E 99 74 A7 (9)\r\n\r\nThis is NOT the same as (7).\r\n\r\n\r\nIn fact, it is the byte-reversed sequence from (7) .\r\n\r\n-- Bingo!\r\nTaking a closer look at (5.0) .. (5.3), I now see that indeed the\r\nterms in these equations are in the reverse concatenation sequence\r\ncompared to (4.0) .. (4.3) !\r\n\r\nAfter a detailed inspection of the tables given in Appendix A.2.\r\nof RFC 4009, it now becomes clear that -- disregarding the IETF\r\nconventions to represent all binary data in network byte order,\r\nand without any further notice of this fact -- these tables do NOT\r\nrepresent octect sequences (as expected from the presentation of\r\nabove formula using octet concatenation, not arithmetic left-shift\r\nor multiply-by-256 operations), BUT the hexadecimal representation\r\nof the proper 4-octet sequences improperly cast into 32 bit numbers\r\non a 'little endian' processor, i.e., without using the ntohl()\r\nintrinsic!\r\n\r\nI suspect that your definition of the SS-boxes (5.0) .. (5.3) has\r\nbeen inadvertently retrofitted to match the values given in the\r\ntables in Appendix A.2., again re-formulating the printed byte\r\norder (which is NOT the storage byte order [= octet concatenation\r\norder] in a little endian processor) using the octet concatenation\r\nnotation / formalism.\r\n\r\nBecause definition of the function G according to section 2.2. does\r\nnot make use of 32-bit integer arithmetic operations, I recommend\r\nto clarify the situation by\r\no giving formula (4.0) .. (4.3) for the SS-Boxes, consistent\r\n with the other formulas, and\r\no stating explicitely in Appendix A.2. that these tables give\r\n byte reversed presentations of the octet sequences to be\r\n used as the output of the SS-boxes.\r\n\r\n\r\nTo catch up, here's my proposed replacement text for the whole\r\nsection 2.2. of RFC 4009, covering the issues (A), (B), and (D)\r\nmentioned so far:\r\n\r\n---------------- cut here -------------------------------\r\n\r\n2.2. The Function G\r\n\r\n The function G has two layers: a layer of two 8x8 S-boxes, S0 and\r\n S1, and a layer of block permutation of sixteen 8-bit sub-blocks.\r\n The output octet sequence Z (= Z0 || Z1 || Z2 || Z3) of the\r\n function G with the four-octet input X (= X0 || X1 || X2 || X3)\r\n is as follows:\r\n\r\n Z0 = {S0(X0) & m0} ^ {S1(X1) & m1} ^ {S0(X2) & m2} ^ {S1(X3) & m3}\r\n Z1 = {S0(X0) & m1} ^ {S1(X1) & m2} ^ {S0(X2) & m3} ^ {S1(X3) & m0}\r\n Z2 = {S0(X0) & m2} ^ {S1(X1) & m3} ^ {S0(X2) & m0} ^ {S1(X3) & m1}\r\n Z3 = {S0(X0) & m3} ^ {S1(X1) & m0} ^ {S0(X2) & m1} ^ {S1(X3) & m2}\r\n\r\n where m0 = 0xFC , m1 = 0xF3 , m2 = 0xCF , and m3 = 0x3F .\r\n\r\n To increase the efficiency of the calculation of the function G, four\r\n extended S-boxes with 4-octet output ('SS-boxes', see Appendix A.2.)\r\n are defined as follows:\r\n\r\n SS0(x) = {S0(x) & m0} || {S0(x) & m1} || {S0(x) & m2} || {S0(x) & m3}\r\n SS1(x) = {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0}\r\n SS2(x) = {S0(x) & m2} || {S0(x) & m3} || {S0(x) & m0} || {S0(x) & m1}\r\n SS3(x) = {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2}\r\n\r\n Hereby, the function G can be defined as follows:\r\n\r\n Z = G(X) = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3) .\r\n\r\n This alternate definition of the function G is faster than the\r\n original definition but it takes 16 times the memory to store\r\n the four SS-boxes compared to the two original S-boxes.\r\n\r\n---------------- cut here -------------------------------\r\n\r\n\r\nImmediately below the headline of Appendix A.2., on page 8,\r\nI propose to insert the following text (or similar):\r\n\r\n \"The following tables specify the byte-reversed SS-box values,\r\n i.e., the first octet to be returned from the function G\r\n (named Z0 in section 2.2.), is obtained by XORing together\r\n the rightmost bytes from the appropriate entries looked up\r\n in the following four tables, etc.\"\r\n\r\n\r\n(E)\r\n\r\nThe above discussion, and the observed deviation from the IETF\r\nstandard ('network') byte ordering convention, immediately raises\r\nadditional byte ordering concerns for\r\n- the definition of the round function F in section 2.1., and\r\n- the Key Schedule definition given in section 2.3.\r\n\r\nThe function G -- as defined in section 2.2. -- operates on a four-\r\noctet sequence and returns a four-octet sequence, according to the\r\nformulae labelled (1) and (2) above.\r\n\r\nThe definition of the round function F and the key schedule make use of\r\nseveral multi-byte INTEGER arithmetic operations, in particular 32-bit\r\n(mod 2^32) addition and subtraction, on input and output values of the\r\nfunction G, and the key schedule uses circular shift operations on\r\nconcatenated (64 bit) intermediate key blocks.\r\n\r\nWith regard to the observations made above, I now suspect that some\r\nof the implicit 'cast' operations (between octet sequences and multi-\r\nbyte integers) involved in the round functions and the key schedule\r\nmight also be formulated in a little-endian centric way, omitting the\r\nnecessary application of the htonl() and ntohl() intrinsics when\r\nproducing the test cases in Appendix B. (I did not have the time\r\nto verify that.)\r\n\r\nFor the sake of interoperability, it SHOULD be clarified whether the\r\nformulae given for R0' and R1' in section 2.1., and for Ki0 and Ki1\r\nin section 2.3., as well as the constant's values tabulated in the\r\nlatter section, are specified according to IEFT standard byte ordering\r\nrules, or with implicit little-endian byte order in mind.\r\n\r\n", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2005-02-28", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "810", "doc-id": "RFC4237", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "", "orig_text": "I suspect that the OID value given in Section 2 is not correct.\r\nIt does not match the one listed in section 4.2, on page 10,\r\n4th text line.\r\n\r\nTherefore I propose the following erratum:\r\n\r\nRFC 4237, at the beginning of Section 2, on page 3, says:\r\n\r\n (IANA-ASSIGNED-OID.1 NAME 'vPIMUser'\r\n SUP 'top'\r\n ... )\r\n\r\nit should say:\r\n vv\r\n (IANA-ASSIGNED-OID.1.1 NAME 'vPIMUser'\r\n SUP 'top'\r\n ... )", "correct_text": "[see above]", "notes": "from pending\n --VERIFIER NOTES-- \nDuplicate of the erratum # 157.\r\n", "submit_date": "2005-11-30", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "811", "doc-id": "RFC4640", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "\r\n(1) typo/grammar\r\n\r\nOn page 3 of RFC 4640, the seconf paragraph of Section 1.2 says:\r\n\r\n Typically, bootstrapping happens when a mobile node does not have all\r\n the information it needs to set up the Mobile IPv6 service. This\r\n includes, but is not limited to, situations in which the mobile node\r\n does not having any information when it boots up for the first time\r\n (out of the box), or does not retain any information during reboots.\r\n\r\nIt should say:\r\n\r\n Typically, bootstrapping happens when a mobile node does not have all\r\n the information it needs to set up the Mobile IPv6 service. This\r\n includes, but is not limited to, situations in which the mobile node\r\n| does not have any information when it boots up for the first time\r\n (out of the box), or does not retain any information during reboots.\r\n\r\n\r\n(2) missing line break\r\n\r\nNear the end of Section 1.3, on page 5, there should be an additional\r\nblank line above the term \"Home Mobility Service Provider\".\r\n\r\n\r\n(3) typo\r\n\r\nOn page 6, the last sub-bullet of the first bulleted list in Section 3\r\nsays:\r\n\r\n * IPsec Security Association (SA) between MN and HA, Intenet Key\r\n Exchange Protocol (IKE) pre-shared secret between MN and HA\r\n\r\nIt should say:\r\n v\r\n| * IPsec Security Association (SA) between MN and HA, Internet Key\r\n Exchange Protocol (IKE) pre-shared secret between MN and HA\r\n\r\n\r\n(4) grammar (singluar/plural mismatch)\r\n\r\nThe first sentence of Section 5.1.3, on page 9, says:\r\n vv\r\n| The home agent discovery protocol does not support an \"opportunistic\"\r\n| or local discovery mechanisms in an ASP's local access network. [..]\r\n ^\r\nIt either should say:\r\n\r\n The home agent discovery protocol does not support an \"opportunistic\"\r\n| or local discovery mechanism in an ASP's local access network. [..]\r\n\r\nor it should say:\r\n\r\n| The home agent discovery protocol does not support \"opportunistic\" or\r\n local discovery mechanisms in an ASP's local access network. [..]\r\n\r\nPlease decide what was intended.\r\n\r\n\r\n(5) missing articles\r\n\r\nThe last paragraph of Section 5.3.1, on page 11, says:\r\n\r\n Bootstrapping does not explicitly try to solve this problem of home\r\n network renumbering when MN is in dormant mode. If the MN can\r\n configure itself after it 'comes back on' by reinitiating the\r\n bootstrapping process, then network renumbering problem is fixed as a\r\n side effect.\r\n\r\nIt should better say:\r\n\r\n Bootstrapping does not explicitly try to solve this problem of home\r\n| network renumbering when the MN is in dormant mode. If the MN can\r\n configure itself after it 'comes back on' by reinitiating the\r\n| bootstrapping process, then the network renumbering problem is fixed\r\n as a side effect.\r\n\r\n\r\n(6) missing article\r\n\r\nThe second paragraph of Section 7, on page 13, says:\r\n\r\n For each scenario, the underlying assumptions are described. The\r\n basic assumption is that there is a trust relationship between mobile\r\n user and the MSA. Typically, [...]\r\n\r\nIt should better say:\r\n\r\n For each scenario, the underlying assumptions are described. The\r\n| basic assumption is that there is a trust relationship between the\r\n mobile user and the MSA. Typically, [...]\r\n\r\n\r\n(7) missing article\r\n\r\nThe second paragraph of Section 7.2, on page 14, says:\r\n\r\n Figure 1 describes an AAA design example for integrated ASP scenario.\r\n\r\nIt should better say:\r\n\r\n Figure 1 describes an AAA design example for the integrated ASP\r\n scenario.\r\n\r\n\r\n(8) flawed artwork\r\n\r\nFigure 2, on page 15,\r\n\r\n +--------------+ +--------+\r\n | | |Serving |\r\n | ASP | | MSP |\r\n +----+ +-----+ | | +----+ |\r\n | MN |--- | NAS | | | | HA | | +-------------------+\r\n +----+ +-----+ |===| +----+ | | MSA |\r\n | \\ | | \\ || (e.g., corporate NW)|\r\n | \\ +------+ | | \\ | +-------+ |\r\n | -|AAA-NA| | | -------|AAA-MIP| |\r\n | +------+ | | | | +-------+ |\r\n +------------ + +--------+ +-------------------+\r\n\r\nshould perhaps be corrected/improved to:\r\n\r\n +--------------+ +--------+\r\n | | |Serving |\r\n | ASP | | MSP |\r\n +----+ +-----+ | | +----+ |\r\n | MN |--- | NAS | | | | HA | | +-------------------+\r\n +----+ +-----+ |===| +----+ | | MSA (e.g., |\r\n | \\ | | \\ | | corporate NW)|\r\n | \\ +------+ | | \\ | | +-------+ |\r\n | -|AAA-NA| | | -------|AAA-MIP| |\r\n | +------+ | | | | +-------+ |\r\n +------------ + +--------+ +-------------------+\r\n\r\n[ Note: I intentionally have refrained from horizontally extending\r\n the box on the rigth side of the figure, which would have been\r\n possible while still conforming to RFC formatting rules. ]\r\n\r\n\r\n\r\n(9) word omissions\r\n\r\nWithin the large first paragraph of Section 9.1, at the bottom of\r\npage 17, there are two word omissions:\r\n\r\nIn the 2nd line of the paragraph, replace\r\n\r\n\t ... between the home agent and mobile node\r\nby:\r\n ... between the home agent and the mobile node\r\n\r\nand in the 5th line from the bottom of the page, insert \"be\", changing\r\n\r\n [...]. The best way to minimize the\r\n probability of such a compromise is to have the cryptographic\r\n material only known or calculable by the two end nodes that share the\r\n SA -- in this case, the home agent and mobile node. [...]\r\n\r\nto:\r\n [...]. The best way to minimize the\r\n probability of such a compromise is to have the cryptographic\r\n| material only be known or calculable by the two end nodes that share\r\n the SA -- in this case, the home agent and mobile node. [...]\r\n\r\n\r\n(10) [[posted separately.]]", "correct_text": "", "notes": "from pending", "submit_date": "2006-11-01", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "812", "doc-id": "RFC4319", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3", "orig_text": "[[Page 18, Hdsl2ShdslWirePair , description]]\r\n\r\n wire), and G.shdsl.bis support an optional third pair", "correct_text": " wire), and G.shdsl.bis lines support an optional third pair", "notes": "from pending", "submit_date": "2007-01-07", "submitter_name": "Clay Sikes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "813", "doc-id": "RFC4319", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": "[[Page 45, hdsl2ShdslSpanConfMinLineRate, description]]\r\n\r\n If the minimum line rate equals the maximum line rate\r\n (hdsl2ShdslSpanMaxLineRate), the line rate is considered\r\n 'fixed'.", "correct_text": " If the minimum line rate equals the maximum line rate\r\n (hdsl2ShdslSpanConfMaxLineRate), the line rate is considered\r\n 'fixed'.", "notes": "from pending", "submit_date": "2007-01-07", "submitter_name": "Clay Sikes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "814", "doc-id": "RFC4641", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7.1", "orig_text": " [3] Kolkman, O., Schlyter, J., and E. Lewis, \"Domain Name System\r\n KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)\r\n Flag\", RFC 3757, May 2004.\r\n", "correct_text": "[should be omitted.]", "notes": "RFC 3757 has been formally obsoleted by (and incorporated into)\r\nthe new DNSSEC RFCs, RFC 4033..4035.\r\nTherefore, RFC 3757 should not appear as a Normative Reference\r\nin new RFCs any more.\r\n\r\nThe two instances where [3] is cited in the text,\r\n - page 6, Section 3.1, first paragraph, and\r\n - page 24, Section 4.1.1, second paragraph\r\nshould have been changed to refer to [5], RFC 4034, instead.\r\n\r\n\r\nfrom pending", "submit_date": "2006-10-13", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Ron Bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "815", "doc-id": "RFC4319", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3", "orig_text": "[[Page 46, hdsl2ShdslSpanConfMaxLineRate, description]]\r\n\r\n If the minimum line rate equals the maximum line rate\r\n (hdsl2ShdslSpanMaxLineRate), the line rate is considered\r\n 'fixed'.", "correct_text": " If the minimum line rate (hdsl2ShdslSpanConfMinLineRate) equals\r\n the maximum line rate, the line rate is considered\r\n 'fixed'.", "notes": "from pending", "submit_date": "2007-01-07", "submitter_name": "Clay Sikes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "816", "doc-id": "RFC4282", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "Unfortunately, the text of that RFC does not fully reflect the\r\nestablished state of the IETF standards, by referring to obsolete\r\ndocuments (e.g., ex STD 10, RFC 821) and ignoring effective updates,\r\ne.g., STD 3, RFC 1123, and RFC 2821.\r\n\r\nIn particular, the text of RFC 4282 repeatedly (e.g. in Section\r\n2.6.) emphasizes making a deviation from established standards\r\nfor host / domain names.\r\n\r\nThis is not true!\r\nThe pretended deviation in fact reflects the current standards.\r\n\r\nThe modification to RFC 952, RFC 821, et al. has already been\r\nintroduced into the IETF Standards by STD 3, RFC 1123 (Host\r\nRequirements, Part II), published 16 years ago, in October 1989.\r\nSection 2.1 of that RFC, on page 13, says:\r\n\r\n \"One aspect of host name syntax is hereby changed: the\r\n restriction on the first character is relaxed to allow\r\n either a letter or a digit. Host software MUST support\r\n this more liberal syntax.\"\r\n\r\nand continues saying:\r\n\r\n \"Host software MUST handle host names of up to 63 characters\r\n and SHOULD handle host names of up to 255 characters.\"\r\n\r\nTherefore, it would have been strongly advisable to point out\r\non page 6 of RFC 4282, in Section 2.2, first bullet, that the\r\nnamed rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!\r\n\r\nNote: IMHO, it is a fundamental design flaw of RADIUS and certain\r\nother protocols using TLVs, AVPs, -- or however similar protocol\r\nobjects are named -- to specify that the 'length' information\r\n(being stored in a single octet) is to comprise the cumulative\r\nsize of the Type, Length and Value fields, instead of just giving\r\nthe size of the Value (payload) field; the latter solution would\r\nalways allow to fully exhaust the total range of an 8-bit unsigned\r\nLength and thereby allow payload octet strings of size 0..255 !\r\n\r\n\r\nSimilarly, RFC 4282 ignores the standardization state of the\r\nproprietary historic tunnelling protocols that have served as\r\n'precursors with major deficiencies to learn from' for the\r\ndevelopment of L2TP, the only comparable protocol named in \r\nRFC 4282 that is on the IETF Standards Track.\r\n\r\n o L2F [RFC2341] has been published for information only\r\n as a Historic RFC 'ab initio'.\r\n\r\n o PPTP [RFC2637] has purposely been rejected by the IETF --\r\n because of its well known significant security flaws, among\r\n other issues, and the Informational RFC 2637 has been\r\n published with a very clear IESG Note to this end.\r\n\r\nI am surprised that a new Standards Track RFC is getting published\r\nthat repeatedly refers to obsolete protocols equally as to official\r\nprotocols, in a manner that does not make clear the distinction.\r\nThe continued unreflected use of PPTP, in particular, is seen by\r\nmajor security consultants as 'one of the most widespread trojan\r\nhorses' in the current Internet. We should do everything to\r\ncommunicate and emphasize the 1998/1999 decisions of the IETF and\r\nIESG and the reasons behind it, and push the evolved standards!\r\n\r\n", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2005-12-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "835", "doc-id": "RFC4778", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.2.3", "orig_text": " SSH may not be supported on legacy equipment. In some cases,\r\n changing the host name of a device requires an SSH rekey event since\r\n the key is based on some combination of host name, Message\r\n Authentication Code (MAC) address, and time.", "correct_text": " SSH may not be supported on legacy equipment. In some cases,\r\n changing the host name of a device requires an SSH rekey event since\r\n the key is based on some combination of host name, Media Access\r\n Control (MAC) address, and time.\r\n\r\n(Or perhaps simply, and more generally, use \"link layer address\"\r\n in place of \"Media Access Control (MAC) address\".)\r\n\r\n\r\n", "notes": "wrong acronym expansion", "submit_date": "2007-02-15", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Merike Kaeo", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "753", "doc-id": "RFC4282", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "2.1", "orig_text": " c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)\r\n ; Where UTF-8-octet is any octet in the\r\n ; multi-octet UTF-8 representation of a\r\n ; unicode codepoint above %x7F.\r\n ; Note that c must also satisfy rules in\r\n ; Section 2.4, including, for instance,\r\n ; checking that no prohibited output is\r\n ; used (see also Section 2.3 of\r\n ; [RFC4013]).\r\n x = %x00-FF ; all 128 ASCII characters, no exception;\r\n ; as well as all UTF-8-octets as defined\r\n ; above (this was not allowed in\r\n ; RFC 2486). Note that x must nevertheless\r\n ; again satisfy the Section 2.4 rules.", "correct_text": "[see below]", "notes": "Shouldn't that be s/FF/F4/ as in STD 63, or maybe s/FF/FD/ ?\n --VERIFIER NOTES-- \nThere is no clear suggested change. The chairs are aware about issues with RFC 4282, and believe that a new document is probably required to address them. \r\n ", "submit_date": "2006-08-14", "submitter_name": "Frank Ellermann", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "755", "doc-id": "RFC1034", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "Section 6.1. ends this way:\r\n\r\n Relative and absolute domain names may be freely intermixed in a\r\n master\r\n\r\nwhich is incomplete. It's unclear exactly how that sentence may have\r\nbeen intended to end, but minimally I would suggeste it at least\r\nterminated with 'file.'.\r\n\r\nSection 6.2.8. in the diagram shows 'QTYPE=A', but should be of\r\ntype 'CNAME' based on the context of the example.", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2006-03-13", "submitter_name": "John Kristoff", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "756", "doc-id": "RFC3189", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.2", "orig_text": " a=fmtp: 112 encode=SD-VCR/525-60\r\n a=fmtp: 112 audio=bundled\r\n a=fmtp: 113 encode=306M/525-60\r\n a=fmtp: 113 audio=bundled", "correct_text": " a=fmtp:112 encode=SD-VCR/525-60 audio=bundled\r\n a=fmtp:113 encode=306M/525-60 audio=bundled", "notes": "from pending", "submit_date": "2005-03-10", "submitter_name": "Stephen Casner", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "757", "doc-id": "RFC4282", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.6", "orig_text": " The BNF of the realm portion allows the realm to begin with a digit,\r\n which is not permitted by the BNF described in [RFC1035]. This\r\n change was made to reflect current practice; although not permitted\r\n by the BNF described in [RFC1035], Fully Qualified Domain Names\r\n (FQDNs) such as 3com.com are commonly used and accepted by current\r\n software.", "correct_text": "[not supplied]", "notes": "section 2.6 missed the update of the hostname syntax in\r\nRFC 1123, section 2.1.\r\n\r\nRFC 1123 (STD 3) 2.1 allows labels starting with a \r\nin fully qualified domain names of a host, RFC 1035 (STD 13)\r\n2.3.1 still wants labels starting with a .", "submit_date": "2005-12-13", "submitter_name": "Peter Koch", "verifier_id": "", "verifier_name": "Dan Romascanu", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "836", "doc-id": "RFC3779", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.2.3.1", "orig_text": "The ASIdentifiers type is a SEQUENCE containing one or more forms of\r\nautonomous system identifiers -- AS numbers (in the asnum element) or\r\nrouting domain identifiers (in the rdi element). When the ASIdentifiers type\r\ncontains multiple forms of identifiers, the asnum\r\nentry MUST precede the rdi entry. AS numbers are used by BGP, and\r\nrouting domain identifiers are specified in the IDRP [RFC1142].", "correct_text": "[see Notes]", "notes": "IDRP was never defined in an RFC, only by ISO 10747.\r\n\r\nfrom pending", "submit_date": "2006-06-21", "submitter_name": "Randy Bush", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "843", "doc-id": "RFC4778", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "Studying the recently published RFC 4788 (EVRCB)\r\nauthored by you, and comparing it with similar recent\r\npublications, I'm surprised to find a quite unusual\r\nsyntax used in the 'a=fmtp' SDP lines there.\r\n\r\nUsually, media type parameters included into 'a=fmtp' SDP lines\r\nare separated by semicolons as in the MIME type declaration.\r\n\r\nThe most recent RFC formally specifying this behaviour was\r\nRFC 4749, Section 6.2 of which says:\r\n\r\n o Any remaining parameters go in the SDP \"a=fmtp\" attribute by\r\n copying them directly from the media type string as a semicolon\r\n separated list of parameter=value pairs.\r\n\r\nAs another example, RFC 4396, in section 9.1, explicitely specifies\r\nthe syntax as:\r\n a=fmtp:\r\n =[,]\r\n [; =]\r\n\r\nNote: This is *not* ABNF, as can be ssen from the context there.\r\n Matching RFC-4234 ABNF should have been stated there as:\r\n a=fmtp:\r\n \"=\" *(\",\" )\r\n *(\";\" \"=\" *(\",\" ))\r\n\r\nThis was common practice over many years.\r\n\r\nSection 6.7 of RFC 4788 deviates from this practice, omitting\r\nthe semicolon in the examples. From the prose description,\r\nit is not quite clear whether the phrase,\r\n \"... copying it directly from the MIME media type string\"\r\nwas meant to comprise the separating semicolons often considered\r\npart of MIME type parameters as well, or not.\r\nUnfortunately, no precise formal description (ABNF) is given.\r\nThe examples given all omit the usual semicolons, e.g.:\r\n\r\n a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1\r\n ^ ^ ^\r\n\r\nHas this omission been done intentionally?\r\n\r\nIf yes, what have been the reasons to do so?\r\n I fear that the unusual definition might cause\r\n interoperability problems; at least it makes the use\r\n of uniform parsing of 'a=fmtp' SDP lines impossible.", "correct_text": "[not submitted]", "notes": "from pending", "submit_date": "2007-01-22", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Ron Bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "844", "doc-id": "RFC3161", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2.4.2", "orig_text": " unacceptedExtension (16),\r\n -- the requested extension is not supported by the TSA\r\n addInfoNotAvailable (17)\r\n -- the additional information requested could not be understood\r\n -- or is not available\r\n systemFailure (25)\r\n -- the request cannot be handled due to system failure }", "correct_text": " unacceptedExtension (16),\r\n -- the requested extension is not supported by the TSA\r\n addInfoNotAvailable (17),\r\n -- the additional information requested could not be understood\r\n -- or is not available\r\n systemFailure (25)\r\n -- the request cannot be handled due to system failure }", "notes": "Missing comma after the descriptor of the OID of PKIFailureInfo,\r\nat the end of line \"addInfoNotAvailable (17).\r\n\r\nfrom pending", "submit_date": "2007-01-31", "submitter_name": "Stefan Doerpinghaus", "verifier_id": "", "verifier_name": "Tim Polk", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "845", "doc-id": "RFC4763", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1", "orig_text": " o It is based on well-established Bellare-Rogaway mutual\r\n authentication protocol.", "correct_text": " o It is based on the well-established Bellare-Rogaway mutual\r\n authentication protocol.\r\n", "notes": "", "submit_date": "2007-02-12", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Bob Braden", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "894", "doc-id": "RFC4698", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7.2", "orig_text": " Using reverse\r\n DNS tree presents problems for IP address delegation (for example,\r\n delegations do not fall into byte boundaries, unlike reverse DNS),\r\n and DNS does not currently contain any information regarding\r\n autonomous system delegation.", "correct_text": " Using the reverse\r\n DNS tree presents problems for IP address delegation (for example,\r\n delegations do not fall into byte boundaries, unlike reverse DNS),\r\n and DNS does not currently contain any information regarding\r\n autonomous system delegation.", "notes": "missing article\r\n\r\nSource: apps", "submit_date": "2006-11-07", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "758", "doc-id": "RFC4256", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "3.2", "orig_text": "\"Information Requests\", on page 5, RFC 4256 says:\r\n\r\n The language tag is deprecated and SHOULD be the empty string. It\r\n may be removed in a future revision of this specification. Instead,\r\n the server SHOULD select the language used based on the tags\r\n communicated during key exchange [SSH-TRANS].\r\n\r\n If the language tag is not the empty string, the server SHOULD use\r\n the specified language for any messages sent to the client as part of\r\n this protocol. The language tag SHOULD NOT be used for language\r\n selection for messages outside of this protocol. If the server does\r\n not support the requested language, the language to be used is\r\n implementation-dependent.", "correct_text": "[see Notes]", "notes": "[Replace by errata ID 1678]\r\n\r\n(These two paragraphs apparently have been copied from Section 3.1\r\nwithout change.)\r\n\r\nThis specification makes no sense here:\r\n\r\nThe Information Request is sent from the *server* to the client,\r\nand it already contains strings that *do* make use of a particular\r\nlanguage/locale.\r\n\r\nThe one and only useful interpretation of the 'language tag'\r\nin the Information Request message is that it specifies the\r\nlanguage/locale used for building the 'instruction' and 'prompt'\r\nstrings in the request.\r\nThis parallels the use of the language tag, e.g., in the\r\nDisconnection Message of the SSH Transport Layer Protocol\r\n(cf. RFC 4253, Sect. 11.1).\r\n\r\nNOTE: The client might have announced a locale *list* in the\r\ninitial exchange, and the server should choose from that list;\r\nthe actual choice [for a particular message with text strings]\r\nneeds to be communicated to the client.\r\n\r\nNOTE: In multi-stage authentication, the backend authentication\r\nmechanisms will be the source of all these strings, and the SSH\r\nserver might have no choice than to just report the locale used\r\nby each backend mechanism to the client; such mechanisms easily\r\ncould make use of different locales - hence the locale needs to\r\nbe announced per message from the server in this context!\r\n\r\nNOTE: RFC 4253 recommends to send empty language tags fields in\r\nthe initial exchange; this makes the 'language tag' field in all\r\nSSH protocol messages containing text to be presented to the user\r\n*very* desirable !\r\n\r\nTherefore, the 'language tag' should also better *not* be deprecated\r\nin the SSH_MSG_USERAUTH_INFO_REQUEST message!\r\n\r\nfrom pending\n --VERIFIER NOTES-- \n [Replaced by errata ID 1678]", "submit_date": "2006-03-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "759", "doc-id": "RFC4588", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(1) [missing article]\r\n\r\nWithin Section 4 of RFC 4588, the second paragraph on page 8 says:\r\n\r\n [...]. See Section 8.1 for the specification of how the\r\n mapping between original and retransmission payload types is done\r\n| with Session Description Protocol (SDP).\r\n\r\nIt should say:\r\n\r\n [...]. See Section 8.1 for the specification of how the\r\n mapping between original and retransmission payload types is done\r\n| with the Session Description Protocol (SDP).\r\n ^^^^^\r\n\r\n\r\n(2) [improper wording]\r\n\r\nThe 4th paragraph of Section 6.3, on page 12, says:\r\n\r\n [...]. In such cases, an appropriate \"reorder delay\"\r\n algorithm may not actually be timer based, but packet based. For\r\n| example, if n number of packets are received after a gap is detected,\r\n then it may be assumed that the packet was truly lost rather than out\r\n of order. This may turn out to be far easier to code on some\r\n platforms as a very short fixed FIFO packet buffer as opposed to the\r\n timer-based mechanism.\r\n\r\nIt should say:\r\n\r\n [...]. In such cases, an appropriate \"reorder delay\"\r\n algorithm may not actually be timer based, but packet based. For\r\n| example, if n packets are received after a gap is detected, then it\r\n may be assumed that the packet was truly lost rather than out of\r\n order. This may turn out to be far easier to code on some platforms\r\n as a very short fixed FIFO packet buffer as opposed to the timer-\r\n based mechanism.\r\n\r\n(Alternatively, use \"if a number n of packets ...\" instead of the\r\n offending \"if n number of packets ...\" )\r\n\r\n\r\n(3) [word omission]\r\n\r\nIn the first paragraph of Section 6.4, on page 13, RFC 4588 says:\r\n\r\n [...] v\r\n| Sending NACKs only in regular RTCP compound decreases the maximum\r\n delay between detecting an original packet loss and being able to\r\n send a NACK for that packet. Implementers should consider the\r\n possible implications of this fact for the application being used.\r\n\r\nIt should say:\r\n\r\n [...] vvvvvvvvv\r\n| Sending NACKs only in regular RTCP compound packets decreases the\r\n maximum delay between detecting an original packet loss and being\r\n able to send a NACK for that packet. Implementers should consider\r\n the possible implications of this fact for the application being\r\n used.\r\n\r\n\r\n(4) [[posted separately.]]\r\n\r\n\r\n(5) [word omission]\r\n\r\nLater on in Section 8.1, on mid-page 15, the RFC says:\r\n\r\n v\r\n| The syntax is as follows:\r\n\r\n a=fmtp: apt=;rtx-time=\r\n\r\nIt should say:\r\n\r\n vvvvv\r\n| The SDP syntax is as follows:\r\n\r\n a=fmtp: apt=;rtx-time=\r\n\r\n(There also is a syntax for these parameters when written in a full\r\n MIME media type specification; this is not presented in the RFC,\r\n but it must be distinguished from the SDP syntax presented!)\r\n\r\n\r\n(6) [excessive text]\r\n\r\nThe final paragraph of Section 8.6, on mid-page 20, says:\r\n\r\n In the following sections, some example SDP descriptions are\r\n| presented. In some of these examples, long lines are folded to meet\r\n| the column width constraints of this document; the backslash (\"\\\") at\r\n| the end of a line and the carriage return that follows it should be\r\n| ignored.\r\n\r\nIt would suffice to say:\r\n\r\n In the following sections, some example SDP descriptions are\r\n| presented.\r\n\r\nRationale:\r\nAs will be shown below, in the examples given in Section 8.7,\r\nthere in fact is no need to perform this artificial line folding.\r\n\r\n\r\n(7) [simplification for improved clarity]\r\n\r\nThe artificial line folding in the examples in Section 8.7 can be\r\navoided without change in the indentation, while still conforming\r\nwith the line length limitations:\r\n\r\na) In the upper half of page 21, the lines,\r\n\r\n a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\\\r\n 0A21F\r\n\r\nshould read:\r\n\r\n a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F\r\n\r\nb) In the lower half of page 21, the lines,\r\n\r\n a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\\\r\n 0A21F\r\n\r\nshould read:\r\n\r\n a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F\r\n\r\nc) In the upper half of page 22, the lines,\r\n\r\n a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\\\r\n 0A21F\r\n\r\nshould read:\r\n\r\n a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F\r\n\r\n\r\n(8) [clarification]\r\n\r\nOn mid-page 21, the text in Section 8.7 says:\r\n\r\n A special case of the SDP description is a description that contains\r\n only one original session \"m\" line and one retransmission session \"m\"\r\n line, the grouping is then obvious and FID semantics MAY be omitted\r\n in this special case only.\r\n\r\nIt should better say:\r\n\r\n A special case of the SDP description is a description that contains\r\n only one original session \"m\" line and one retransmission session \"m\"\r\n| line, the grouping is then obvious and lines with grouping syntax\r\n (FID semantics) MAY be omitted in this special case only.\r\n\r\nRationale:\r\nIt is impossible to only omit *semantics*.\r\nCertain *lines* are omitted there -- the lines with grouping syntax\r\n(and FID semantics).\r\nAlternatively, \"(FID semantics)\" might be omitted entirely from\r\nthe changed text, as well.\r\n\r\n\r\n(9) [word omission -- clarification]\r\n\r\nThe first paragraph of Section 10.2, on page 25, says:\r\n\r\n This section shows how to combine retransmissions with layered\r\n encoding in multicast sessions. Note that the retransmission\r\n framework is offered only for small multicast applications. Refer to\r\n RFC 2887 [10] for a discussion of the problems of NACK implosion,\r\n severe congestion caused by feedback traffic, in large-group reliable\r\n multicast applications.\r\n\r\nIt should better say:\r\n\r\n This section shows how to combine retransmissions with layered\r\n encoding in multicast sessions. Note that the retransmission\r\n framework is offered only for small multicast applications. Refer to\r\n| RFC 2887 [10] for a discussion of the problems of NACK implosion, and\r\n severe congestion caused by feedback traffic, in large-group reliable\r\n multicast applications.\r\n ^^^\r\n\r\n\r\n(10) [word omission]\r\n\r\nIn the first paragraph on page 27, text within Section 13 says:\r\n\r\n [...]. Refer to Section 9.1\r\n of the Secure Real-Time Transport Protocol (SRTP) [12] for a\r\n| discussion the implications of two-time pads and how to avoid them.\r\n ^\r\n\r\nIt should say:\r\n vvvvvvvvvvvvvvv\r\n [...]. Refer to Section 9.1\r\n| of the Secure Real-Time Transport Protocol (SRTP) specification [12]\r\n| for a discussion of the implications of two-time pads and how to\r\n avoid them.\r\n ^^^^\r\n\r\n(11) [inconsistency]\r\n\r\nIn the fourth bullet on page 29, Appendix A.1 says:\r\n\r\n * avg-rtcp-size is approximated by 120 bytes. This is a rounded-up\r\n average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes\r\n for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a\r\n RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes.\r\n [...]\r\n\r\nI cannot follow these computations:\r\n 40+8+28+32 = 105 ??? and 40+8+64+32 = 157 ???\r\nWhat is wrong there?\r\nAuthors, please correct !\r\n\r\nBTW:\r\nWhat follows in the text essentially does not depend on the exact\r\nfigures, the rough order of magnitude is all that is needed.\r\nBut the presentation should be self-consistent.\r\n\r\n\r\n(12) [improvement of wording]\r\n\r\nIn the 6th bullet of Appendix A.1, the text on page 29/30 says:\r\n\r\n [...]. This means that if a packet is requested for\r\n retransmission a maximum of 2 times, the corresponding generic NACK\r\n report block requesting that particular packet is sent in two\r\n << page break >>\r\n| consecutive RTCP compounds; likewise, if it is requested for\r\n retransmission 10 times, then the generic NACK is sent 10 times.\r\n [...]\r\n\r\nIt should say:\r\n\r\n [...]. This means that if a packet is requested for\r\n retransmission a maximum of 2 times, the corresponding generic NACK\r\n report block requesting that particular packet is sent in two\r\n << page break >>\r\n| consecutive RTCP compound packets; likewise, if it is requested for\r\n retransmission 10 times, then the generic NACK is sent 10 times.\r\n [...]\r\n\r\n\r\n(13) [missing argument / clarification]\r\n\r\nOn page 31, Appendix A.2 says:\r\n vv\r\n| To find an estimate of the buffering time, T(), that a streaming\r\n server shall use in order to enable a given number of retransmissions\r\n for each packet, N. [...]\r\n\r\nIt should say:\r\n vvv\r\n| To find an estimate of the buffering time, T(N), that a streaming\r\n server shall use in order to enable a given number of retransmissions\r\n for each packet, N. [...]\r\n\r\n\r\n(14) [fractional sign]\r\n\r\nWithin the tables in Appendix A.4, on pages 32 and 33, the RFC text\r\nuses the comma (\",\") as the fractional sign (central european style).\r\nIn IETF documents, the decimal point (\".\") should be used instead.\r\n\r\n\r\nAuthors, Please comment.\r\nItems (4) / (11) need agreement / text correction from you.\r\nItems (6) + (7) might be considered non-esssential.\r\nAll other items seem to be straightforward and suitable for\r\ninclusion in an Errata Note.\r\n", "correct_text": "", "notes": "from pending\r\n\r\n--VERIFIER COMMENT--\r\n\r\n\r\nThanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:\r\n\r\n\"We will be happy to archive these and migt consider them if we do a revision of the RFC. But an errata document would only make sense if there is something seriously hindering interoperability. I have not seen anything falling into this category (well, and there are implementations out there from the spec).\"\r\n", "submit_date": "2006-08-14", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Jose Rey", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "760", "doc-id": "RFC2821", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "2.4.1", "orig_text": "In several places, RFC2821 refers to \"section 2.4.1.\".\r\nUnfortunately there *is* no section 2.4.1. To be quite honest, I'm\r\nreally not sure what the intended section number is. It doesn't\r\nappear obvious to me.", "correct_text": "[not submitted]", "notes": "from pending", "submit_date": "2005-05-12", "submitter_name": "Wayne Schlitt", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "761", "doc-id": "RFC4596", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1", "orig_text": "3.1. Routing of INVITE and MESSAGE to Different UA\r\n", "correct_text": "3.1. Routing of INVITE and MESSAGE to Different UAs\r\n", "notes": "from pending", "submit_date": "2006-08-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "762", "doc-id": "RFC4073", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "In the module heading and in the IMPORTS clause of the ASN.1 module\r\nof RFC 4073 (Appendix A on page 7), the textual label for the\r\nsub-identifier 9 of the OBJECT IDENTIFIER 1.2.840.113549.1 is\r\nspelled \"pkcs-9(9)\".\r\nBut, ALL other (#=4) appearances of this same sub-identifier in the\r\ntext of RFC 4073 use the spelling \"pkcs9(9)\" (without the '-').\r\n\r\nI've tried to resolve this inconsistency going \"back to the roots\",\r\nand unfortunately found a big mess! (see detailed list below)\r\n\r\nBasically, PKCS#9 v2.0 from RSA Labs and its ASCII-fication RFC 2985\r\nshould be considered the primary reference because this spec contains\r\nthe definition of the OBJECT IDENTIFIER 1.2.840.113549.1.9 .\r\nThere, the spelling consistently is \"pkcs-9(9)\" .\r\n\r\nThis notation style is strictly followed in all PKCS publications\r\nfrom RSA (as far as I could verify), and in most RFCs related to\r\nPKCS/CMS/PKIX. I've found 24 RFCs of this kind.\r\n\r\nBut there are two RFCs using the spelling \"pkcs9(9)\" (without the '-')\r\nexclusively.\r\n\r\nAnd finally, I found 8 RFCs - including RFC 4073 and your RFC 4049,\r\nas well - using both spellings mixed without any recognizable pattern.\r\n\r\nHere are the detailed results of my RFC scan - with shortened titles,\r\nand some content oriented grouping applied:\r\n\r\n'pkcs-9(9)' only :\r\n----------------\r\n 2985 - PKCS #9\r\n\r\n 2311 - S/MIME v.2 Message Specification,\r\n 2312 - S/MIME v.2 Certificate Handling,\r\n 2633 - S/MIME v.3 Message Specification\r\n 3114 - Company Classifying Policy via S/MIME Security Label\r\n 3183 - Domain Security Services using S/MIME\r\n 3850 - S/MIME v.3.1 Certificate Handling\r\n 3855 - Transporting S/MIME Objects in X.400\r\n\r\n 2459 - PKIX Certificate and CRL Profile [ obsoleted by: 3280 ]\r\n 3280 - PKIX Certificate and CRL Profile\r\n\r\n 2511 - PKIX Certificate Request Messages\r\n 3029 - PKIX Data Validation and Certification Server Protocols\r\n\r\n 2797 - Certificate Mgmt Messages over CMS\r\n 3161 - PKIX Time-Stamp Protocol\r\n\r\n 3125 - Electronic Signature Policies\r\n\r\n 3211 - Password-based Encryption for CMS [ obsoleted by: 3369+3370 ]\r\n 3274 - Compressed Data Content for CMS\r\n\r\n 2875 - D-H Proof-of-Posession\r\n 3185 - Reuse of CMS CEKs\r\n 3217 - Triple-DES and RC2 Key Wrapping\r\n 3370 - CMS Algorithms\r\n 3537 - HMAC Key Wrapping with 3DES or AES\r\n 3560 - RSAES-OAEP Key Transport in CMS\r\n 3565 - Use of AES Encryption in CMS\r\n\r\n'pkcs9(9)' only :\r\n---------------\r\n 3657 - Use of Camellia Encryption in CMS\r\n 4010 - Use of SEED Encryption in CMS\r\n\r\nmixed spelling :\r\n--------------\r\n 2630 - CMS [ obsoleted by: 3369+3370 ]\r\n 3369 - CMS [ obsoleted by: 3852 ]\r\n 3852 - CMS\r\n\r\n 2634 - Enhanced Security Services for S/MIME\r\n 3851 - S/MIME v.3.1 Message Specification\r\n\r\n 3126 - Electronic Signature Formats for lon-term signatures\r\n\r\n 4049 - BinaryTime\r\n\r\n 4073 - Multiple Content in CMS\r\n\r\nNote: I fear that there might exist similar inconsistencies for other\r\n==== object identifiers (verification: t.b.d.)\r\n\r\n\r\nSo, what should be done?\r\nIt certainly would be VERY preferable to follow identifier naming\r\nliterally, always and strictly, once published in a normatively\r\nreferable way.\r\nAt least, we should ensure a consistent use of already defined\r\nidentifiers to be followed in future IETF publications.\r\nAdditionally, it might be considered to post Errata Notes for some\r\n(or all non-obsoleted) RFCs in the 2nd and 3rd category above\r\n(i.e., RFCs 2634, 3126, 3657, 3851, 3852, 4010, 4049, 4073).\r\n", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2005-05-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "763", "doc-id": "RFC4596", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "2", "orig_text": "The may prefer to reach\r\nthe user on a device that supports video (because a video-conference\r\nis desired). \r\n", "correct_text": "They may prefer to reach\r\nthe user on a device that supports video (because a video-conference\r\nis desired). ", "notes": "from pending", "submit_date": "2006-08-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03"}, {"errata_id": "764", "doc-id": "RFC2028", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.6", "orig_text": "The IAB is also responsible for reviewing and approving the charters of new Working Groups that are proposed for the IETF.", "correct_text": "The formation of a working group requires a charter which is primarily negotiated \r\nbetween a prospective working group Chair and the relevant Area \r\nDirector(s), although final approval is made by the IESG with advice \r\nfrom the Internet Architecture Board (IAB).", "notes": "from pending", "submit_date": "2006-03-21", "submitter_name": "Pete Resnick", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "765", "doc-id": "RFC2234", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "page 5:\r\n\r\n LINEAR WHITE SPACE: Concatenation is ...\r\n ...\r\n ...\r\n ...\r\n ... ... to be freelyPand\r\n implicitlyPinterspersed around ...\r\n \r\npresumably, each \"P\" character should be a parenthesis and a space ??\r\n", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2005-05-19", "submitter_name": "Keith McCloghrie", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "766", "doc-id": "RFC4586", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7.3", "orig_text": "| We have shown that the limitations of RTP AVPF profile do not\r\n generate such high delay in the feedback messages that the\r\n performance of NEWPRED is degraded for sessions from 32 kbps to 2\r\n Mbps.", "correct_text": "| We have shown that the limitations of the RTP AVPF profile do not\r\n generate such high delay in the feedback messages that the\r\n performance of NEWPRED is degraded for sessions from 32 kbps to 2\r\n Mbps. ", "notes": "missing article\r\n\r\nfrom pending", "submit_date": "2006-08-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "767", "doc-id": "RFC4113", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "The DESCRIPTION clause of 'udpEndpointRemoteAddressType',\r\n at the bottom of page 10,\r\n\r\n \"The address type of udpEndpointRemoteAddress. Only\r\n IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or\r\n unknown(0) if datagrams for all remote IP addresses are\r\n accepted. ...\" ", "correct_text": " \"The address type of udpEndpointRemoteAddress. Only\r\n IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or\r\n unknown(0) if datagrams from all remote IP addresses are\r\n accepted. ...\"\r\n ^^^^ \r\n", "notes": "from pending", "submit_date": "2005-06-20", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Brian Haberman", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "768", "doc-id": "RFC4585", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "Errors (1)-(10) of 19", "orig_text": "(1)\r\n\r\nSection 1.1 of RFC 4585, on mid-page 4, says:\r\n\r\n Feedback (FB) message:\r\n An RTCP message as defined in this document is used to convey\r\n information about events observed at a receiver -- in addition to\r\n long-term receiver status information that is carried in RTCP\r\n receiver reports (RRs) -- back to the sender of the media stream.\r\n| For the sake of clarity, feedback message is referred to as FB\r\n| message throughout this document.\r\n\r\nI do not see how and why using the abbreviation might have improved\r\n*clarity* of the text; apparently, it has been used for *brevity* .\r\nTherefore, the two tagged lines should better say:\r\n\r\n| For the sake of brevity, feedback message is referred to as FB\r\n| message throughout this document.\r\n\r\nSimilarly, at the bottom of page 4, where the RFC says:\r\n\r\n Feedback (FB) threshold:\r\n The FB threshold indicates the transition between Immediate\r\n Feedback and Early RTCP mode. [...]\r\n [...]\r\n to application designers and is not used in any calculations. For\r\n| the sake of clarity, the term feedback threshold is referred to as\r\n FB threshold throughout this document.\r\n\r\nThe last 3 lines should better say:\r\n\r\n to application designers and is not used in any calculations. For\r\n| the sake of brevity, the term feedback threshold is referred to as\r\n FB threshold throughout this document.\r\n\r\n\r\n(2)\r\n\r\nThe first bulleted item in Section 3.1, on page 7, says:\r\n vvvvvvvvvvvvv\r\n| o Status reports are contained in sender report (SR)/received report\r\n (RR) packets and are transmitted at regular intervals as part of\r\n compound RTCP packets (which also include source description\r\n (SDES) and possibly other messages); these status reports provide\r\n an overall indication for the recent reception quality of a media\r\n stream.\r\n\r\nFor *clarity*, it perhaps should better say -- not binding together the\r\nwords intended to being separated by the slash marking the alternative:\r\n vvv\r\n| o Status reports are contained in sender report (SR) / received\r\n report (RR) packets and are transmitted at regular intervals as\r\n part of compound RTCP packets (which also include source\r\n description (SDES) and possibly other messages); these status\r\n reports provide an overall indication for the recent reception\r\n quality of a media stream.\r\n\r\n\r\n(3) [missing article]\r\n\r\nIn Section 3.4, on mid-page 11, RFC 4585 says:\r\n\r\n j) Let T_fd be the actual (randomized) delay for the transmission of\r\n FB message in response to an event at time t0.\r\n\r\nIt should say:\r\n\r\n j) Let T_fd be the actual (randomized) delay for the transmission of\r\n| a FB message in response to an event at time t0.\r\n ^^\r\n\r\n(4) [inappropriate wording]\r\n\r\nThe algorithm in Section 3.5.2, at the bottom of page 16, contains\r\nthe sub-step:\r\n\r\n 4b) If allow_early == TRUE, then R MUST schedule an Early RTCP\r\n packet for te = t0 + RND * T_dither_max with RND being a\r\n| pseudo random function evenly distributed between 0 and 1.\r\n ^^^^^^^^\r\n\r\nThis wording is inappropriate. RND is not a *function* (that's code!),\r\nbut a *number*, the function *value*. Therefore, the RFC should say:\r\n\r\n 4b) If allow_early == TRUE, then R MUST schedule an Early RTCP\r\n packet for te = t0 + RND * T_dither_max with RND being a\r\n| pseudo random number evenly distributed between 0 and 1.\r\n ^^^^^^\r\n\r\n\r\n(5) [inappropriate wording]\r\n\r\nThe algorithm in Section 3.5.3, at the top of page 19, says:\r\n\r\n 2. Otherwise, a temporary value T_rr_current_interval is calculated\r\n as follows:\r\n\r\n T_rr_current_interval = RND*T_rr_interval\r\n\r\n| with RND being a pseudo random function evenly distributed between\r\n 0.5 and 1.5. This dithered value is used to determine one of the\r\n following alternatives:\r\n\r\nSimilar to item (4) above, the RFC should say instead:\r\n\r\n 2. Otherwise, a temporary value T_rr_current_interval is calculated\r\n as follows:\r\n\r\n T_rr_current_interval = RND*T_rr_interval\r\n\r\n| with RND being a pseudo random number evenly distributed between\r\n 0.5 and 1.5. This dithered value is used to determine one of the\r\n following alternatives:\r\n\r\n\r\n(6) [typo / dup. wording]\r\n\r\nSection 3.6.2 of RFC 4585, on mid-page 21, says:\r\n\r\n Example: If a 256-kbit/s video with 30 fps is transmitted through a\r\n network with an MTU size of some 1,500 bytes, then, in most cases,\r\n| each frame would fit in into one packet leading to a packet rate of\r\n 30 packets per second. [...]\r\n\r\nIt should say:\r\n\r\n Example: If a 256-kbit/s video with 30 fps is transmitted through a\r\n network with an MTU size of some 1,500 bytes, then, in most cases,\r\n| each frame would fit into one packet leading to a packet rate of\r\n 30 packets per second. [...]\r\n\r\n\r\n(7) [wrong ref. tag]\r\n\r\nOn mid-page 23, Section 4.1 of RFC 4585 says:\r\n\r\n vvv\r\n| The AV profile defined in [4] is referred to as \"AVP\" in the context\r\n of, e.g., the Session Description Protocol (SDP) [3]. The profile\r\n specified in this document is referred to as \"AVPF\".\r\n\r\nThere apparently is a confusion of the ref. tags used.\r\nThe RFC should say:\r\n vvv\r\n| The AV profile defined in [2] is referred to as \"AVP\" in the context\r\n of, e.g., the Session Description Protocol (SDP) [3]. The profile\r\n specified in this document is referred to as \"AVPF\".\r\n\r\n\r\n(8) [missing article]\r\n\r\nIn Section 4.2, near the top of page 25, the ABNF production:\r\n\r\n rtcp-fb-pt = \"*\" ; wildcard: applies to all formats\r\n| / fmt ; as defined in SDP spec\r\n\r\nshould better say, improving the ABNF comment text:\r\n\r\n rtcp-fb-pt = \"*\" ; wildcard: applies to all formats\r\n| / fmt ; as defined in the SDP spec\r\n ^^^^^\r\n\r\n\r\n(9) [inconsistent specification]\r\n\r\nIn Section 4.2, the ABNF on page 25 contains the following productions:\r\n\r\n rtcp-fb-val = \"ack\" rtcp-fb-ack-param\r\n / [...]\r\nand\r\n rtcp-fb-ack-param = SP \"rpsi\"\r\n / SP \"app\" [SP byte-string]\r\n / SP token [SP byte-string]\r\n| / ; empty\r\n\r\nThis means that the feedback type \"ack\" *MAY* have parameters.\r\n\r\nContrary to that, below the ABNF, the RFC explains:\r\n\r\n Feedback type \"ack\":\r\n\r\n This feedback type indicates that positive acknowledgements for\r\n feedback are supported.\r\n\r\n The feedback type \"ack\" MUST only be used if the media session is\r\n allowed to operate in ACK mode as defined in Section 3.6.1.\r\n\r\n| Parameters MUST be provided to further distinguish different types\r\n| of positive acknowledgement feedback.\r\n\r\n [...]\r\n\r\nThe *MUST* in the tagged lines contradicts the ABNF.\r\n\r\nAuthors, please resolve the issue:\r\n\r\nEither have the ABNF changed by omission of the tagged line above,\r\n\r\n| / ; empty\r\n\r\nor change the tagged explanation lines to say:\r\n\r\n| Parameters MAY be provided to further distinguish different types\r\n| of positive acknowledgement feedback.\r\n\r\n\r\n(10) [incomplete specification, and an extraneous word]\r\n\r\nAt the bottom of page 26, Section 4.2 of RFC 4585 says:\r\n\r\n Other feedback types :\r\n\r\n Other documents MAY define additional types of feedback; to keep\r\n the grammar extensible for those cases, the rtcp-fb-id is\r\n| introduced as a placeholder. A new feedback scheme name MUST to\r\n be unique (and thus MUST be registered with IANA). Along with a\r\n| new name, its semantics, packet formats (if necessary), and rules\r\n for its operation MUST be specified.\r\n\r\nIt should say:\r\n\r\n Other feedback types :\r\n\r\n Other documents MAY define additional types of feedback; to keep\r\n the grammar extensible for those cases, the rtcp-fb-id is\r\n| introduced as a placeholder. A new feedback scheme name MUST be\r\n unique (and thus MUST be registered with IANA). Along with a new\r\n| new name, its semantics, possible parameters, packet formats (if\r\n necessary), and rules for its operation MUST be specified.\r\n\r\nRationale:\r\n\r\na) \"MUST to be unique\" should be \"MUST be unique\".\r\n\r\nb) Syntax and semantics of parameters (if any) obviously MUST be\r\n specified as well. The RFC text in the IANA Considerations\r\n (Section 9) already reflects this requirement.\r\n For completeness and clarity, it should be stated here as well.\r\n I have proposed minimal additional wording -- you might choose\r\n alternative words.", "correct_text": "", "notes": "from pending\r\n\r\n--VERIFIER COMMENT--\r\nThanks for the review. I have only quickly skimmed your comments\r\nand there does not seem to be anything serious.\r\n\r\nWe will be happy to archive these and migt consider them if\r\nwe do a revision of the RFC. But an errata document would\r\nonly make sense if there is something seriously hindering\r\ninteroperability. I have not seen anything falling into this\r\ncategory (well, and there are implementations out there from\r\nthe spec).\r\n", "submit_date": "2006-08-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Joerg Ott", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "895", "doc-id": "RFC4468", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": "X.7.8 Trust relationship required", "correct_text": "X.7.14 Trust relationship required", "notes": "Incorrect Enhanced Status Code. See for more details.\r\n", "submit_date": "2007-04-11", "submitter_name": "Alexey Melnikov", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "775", "doc-id": "RFC2288", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "", "orig_text": "Once you have written RFC 2288 that defined three URN namespaces:\r\n ISSN, ISBN, and SICI.\r\nThe IANA \"urn-namespaces\" registry does not (and probably never\r\ndid) contain any pointers to RFC 2288.\r\n\r\nMeanwhile, the 'ISSN' URN namespace definition has been restated\r\nin RFC 3044, including an IANA registration -- according to and\r\nusing the template specified in RFC 2611 (BCP 33) [that in the\r\nmeantime has been obsoleted itself by RFC 3406 (BCP 66)] --,\r\nand 'ISSN' currently appears as formal URN namespace #3 in the\r\nIANA URN namespaces registry.\r\n\r\nSimilarly, the 'ISBN' URN namespace definition has been restated\r\nin RFC 3187, including an IANA registration -- according to and\r\nusing the template specified in RFC 2611 --, and 'ISBN' currently\r\nappears as formal URN namespace #9 in the IANA registry.\r\n\r\nNow, RFC 2288 is *NOT* declared \"Obsoleted\" in the RFC index.\r\nContrary to that, the 'SICI' URN namespace does *NOT* appear\r\nin the current IANA URN namespaces registry.\r\nThus the fate of the 'SICI' namespace and the status of RFC 2288\r\nis questionable and unclear.\r\n\r\nI suspect that RFC 2288 should be considered obsoleted, and\r\n'SICI' should be considered deprecated.\r\n\r\nSo, what's to do in this case ?\r\n\r\nAccording to my understanding of the established procedures,\r\nthe Informational RFC 2288 cannot easily be re-classified as\r\nHistoric, and a specific footnote about the deprecated 'SICI'\r\nnamespace would not be easily entered into the IANA registry.\r\nTherefore, to make the situation clearly understandable for\r\neveryone, it seems easiest to have the RFC-Ed add the note\r\n '(Obsoleted by 3044, RFC 3187)'\r\nto the RFC index entry for RFC 2288.", "correct_text": "[see above]", "notes": "from pending", "submit_date": "2005-09-11", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "776", "doc-id": "RFC4450", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": "(1)\r\n\r\nNear the top of page 3, section 3 of RFC 4450 states the\r\nreasons for removal from the list -- i.e. *not* moving\r\nto HISTORIC state:\r\n o RFC 1584 -- an expected future dependency;\r\n o RFC 1755 -- believed to be actively in use.\r\n\r\nNevertheless, these two RFCs have been moved to HISTORIC\r\nstatus along with the publication of RFC 4450, as can be\r\nseen in rfcxx00.txt .\r\nThis is quite surprising. (Perhaps, you know what happened.)\r\n\r\nPreferrably, the final RFC text would better have been\r\ncoordinated with the actual Standards Actions performed --\r\nfor example, by addition of an IESG statement explaining the\r\ndeviation from the text.\r\n\r\n\r\n(2)\r\n\r\nDue to the 'numeric limitation' applied (restriction to RFCs\r\nwith numbers in the range ~700...2000) there are now a couple\r\nof RFCs that have lost their 'normative background'.\r\n\r\nFor example, the higher level SNA MIBs (RFCs 2051, (2155->)2455,\r\n2456, 2457, and 2582) more or less depend on the now deprecated\r\nbasic SNA node MIBs, RFCs (1665->)1666 and 1747. [ \"xx->yy\"\r\nis my shorthand notation for \"RFC xx obsoleted by RFC yy\". ]\r\nArguably, in this case, these dependant RFCs might be considered\r\ncandidates for a move to HISTORIC as well.\r\nBut there certainly are other cases as well (I have not yet\r\nchecked all the details).\r\n\r\nIt therefore should perhaps be considered to repeat the\r\nRFC 4450 'experiment' with an extended numeric range of RFCs,\r\ne.g. up to RFC 2500.\r\n\r\n\r\n(3)\r\n\r\nOn the other hand, the restriction to Standards Track documents\r\nhas other undesired implications:\r\n\r\na) In the past, usually at least an Experimental RFC has been\r\npublished as a first try for a new protocol (or an Informational\r\nRFC, in the case of a third-party protocol), before a Standards\r\nTrack version has been developed. Unfortunately, in this process\r\nit obviously has been avoided very often to formally OBSOLETE\r\nthe predecessor RFC[s] when the Standards Track version has been\r\npublished. (Similar undue 'politeness' can be observed, e.g.,\r\non the transition path of MIBs from SMIv1 to SMIv2.)\r\nCaused by RFC 4450 we now have non-deprecated RFCs predating\r\nRFCs moved to HISTORIC state.\r\n(The example instances I've been aware of at first glance, though\r\nstill being listed as EXPERIMENTAL in the RFC index, fortunately\r\nalready had been removed in the past from the 'Experimental RFCs'\r\nSection of rfcxx00.txt .)\r\nIt would be very useful, for clarity, to move these RFCs to\r\nHISTORIC status as well.\r\n\r\nb) There are 'companion documents' to Standards Track RFCs that\r\nhave been published as Informational RFCs for various (legitimate)\r\nreasons. These RFCs are outdated with their respective related\r\nspecifications, and as such, for clarity, should better be moved\r\nto HISTORIC status as well.\r\n\r\nFor example, IMHO the following Informational and Experimental RFCs,\r\nbeing closely related to RFCs that now have been deprecated, should\r\nbe considered candidates for deprecation (being made HISTORIC) as\r\nwell, for clarity, consistency, and/or historical context:\r\n\r\no RFC 1477 (IDPR Introduction);\r\no RFC 1482 (NSFNET Policy-Based Routing Database) -- IDPR related;\r\no RFC 1585 (MOSPF Analysis and Experience) -- depending on RFC 1584;\r\no RFC 1593 (SNA APPN Node MIB) -- 1st ed., eff.->2155->4255;\r\no RFC 1634 (IPX over WAN Media) -- successor to RFC 1551, the siblings\r\n of which (RFCs 1552 and 1553) have been made HISTORIC;\r\no RFC 1791 (TCP+UDP over IPX); \\ both still in\r\no RFC 1792 (TCP/IPX MIB); / rfcxx00.txt !\r\no RFC 1834 (WHOIS++ Introduction);\r\no RFC 1875 (UNINETT PCA Policy) -- based on PEM.\r\n\r\nIt might therefore perhaps be useful to perform a RFC 4450 like\r\n'experiment' for Informational and Experimental RFCs as well.\r\n\r\n\r\n(4)\r\n\r\nThe restriction in the RFC 4450 effort on Proposed Standards\r\ndetracts from the fact that there are [Full] Standard RFCs as\r\nwell which are clearly outdated, or of questionable quality and/or\r\nprecision.\r\nMy personal (incomplete) hot list of candidates comprises:\r\n STDs 15, 16, 17, 19, 35, 40, 42, 44, 49\r\n(Other legacy Standards doubtlessly should be updated, e.g.\r\nSTDs 5, 7, 13.)\r\n\r\nNote: In particular the situation with STDs 16+17 is annoying.\r\n Replacements are established, but vendors do not switch\r\n to SMIv2 and the newer MIBs (and do not offer SNMPv3,\r\n with its improved security features!) because these old\r\n specifications are still listed as Standard.\r\n\r\nI also strongly suspect that there are a few Draft Standard RFCs\r\nthat might be considered outdated.\r\n\r\nIt therefore might be worth repeating the RFC 4450 'experiment'\r\nfor Draft and Full Standards as well.", "correct_text": "[see above]", "notes": "From Eliot Lear \r\n\r\nAlfred,\r\n\r\nThanks for taking the time to read the document. I'd like to encourage\r\nyou to share your comments with the newtrk working group. You can find\r\ninformation on how to subscribe by going to http://www.ietf.org and\r\nclicking on \"Working Groups\".\r\n\r\nAs to your specific comments...\r\n\r\nAlfred ? wrote:\r\n> Hello,\r\n> I'd like to send you a few comments on the recently \r\n> published RFC 4450 (Cruft Removal) authored by you.\r\n>\r\n> First of all, thanks for your effort!\r\n>\r\n> After reading the RFC and looking into the changes\r\n> performed to rfcxx00.txt, I noticed a few issues. \r\n>\r\n>\r\n> (1)\r\n>\r\n> Near the top of page 3, section 3 of RFC 4450 states the\r\n> reasons for removal from the list -- i.e. *not* moving\r\n> to HISTORIC state:\r\n> o RFC 1584 -- an expected future dependency; \r\n> o RFC 1755 -- believed to be actively in use. \r\n>\r\n> Nevertheless, these two RFCs have been moved to HISTORIC\r\n> status along with the publication of RFC 4450, as can be \r\n> seen in rfcxx00.txt .\r\n> This is quite surprising. (Perhaps, you know what happened.)\r\n>\r\n> Preferrably, the final RFC text would better have been \r\n> coordinated with the actual Standards Actions performed --\r\n> for example, by addition of an IESG statement explaining the\r\n> deviation from the text.\r\n>\r\n\r\nThere was intended to be no deviation from the text. The RFC Editor is\r\nalso the one who keeps track of how specifications are classified. \r\n>\r\n> (2)\r\n>\r\n> Due to the 'numeric limitation' applied (restriction to RFCs\r\n> with numbers in the range ~700...2000) there are now a couple\r\n> of RFCs that have lost their 'normative background'.\r\n>\r\n> For example, the higher level SNA MIBs (RFCs 2051, (2155->)2455,\r\n> 2456, 2457, and 2582) more or less depend on the now deprecated\r\n> basic SNA node MIBs, RFCs (1665->)1666 and 1747. [ \"xx->yy\"\r\n> is my shorthand notation for \"RFC xx obsoleted by RFC yy\". ]\r\n> Arguably, in this case, these dependant RFCs might be considered\r\n> candidates for a move to HISTORIC as well.\r\n> But there certainly are other cases as well (I have not yet\r\n> checked all the details).\r\n>\r\n> It therefore should perhaps be considered to repeat the\r\n> RFC 4450 'experiment' with an extended numeric range of RFCs,\r\n> e.g. up to RFC 2500.\r\n>\r\n\r\nI believe the problem you refer to would occur no matter what point we\r\nstop. Also, at this time the normative limitation is being reconsidered.\r\n\r\n> \r\n> (3)\r\n>\r\n> On the other hand, the restriction to Standards Track documents \r\n> has other undesired implications:\r\n>\r\n> a) In the past, usually at least an Experimental RFC has been\r\n> published as a first try for a new protocol (or an Informational\r\n> RFC, in the case of a third-party protocol), before a Standards\r\n> Track version has been developed. Unfortunately, in this process\r\n> it obviously has been avoided very often to formally OBSOLETE\r\n> the predecessor RFC[s] when the Standards Track version has been\r\n> published. (Similar undue 'politeness' can be observed, e.g.,\r\n> on the transition path of MIBs from SMIv1 to SMIv2.)\r\n> Caused by RFC 4450 we now have non-deprecated RFCs predating\r\n> RFCs moved to HISTORIC state.\r\n> (The example instances I've been aware of at first glance, though\r\n> still being listed as EXPERIMENTAL in the RFC index, fortunately\r\n> already had been removed in the past from the 'Experimental RFCs'\r\n> Section of rfcxx00.txt .)\r\n> It would be very useful, for clarity, to move these RFCs to\r\n> HISTORIC status as well.\r\n> \r\n> b) There are 'companion documents' to Standards Track RFCs that\r\n> have been published as Informational RFCs for various (legitimate)\r\n> reasons. These RFCs are outdated with their respective related\r\n> specifications, and as such, for clarity, should better be moved\r\n> to HISTORIC status as well.\r\n> \r\n\r\nI think it's a matter of how you want to use the marking of \"HISTORIC\".\r\nI apply it only to specifications that are only on the standards track.\r\nYou are correct that these docs are related, and the ISD effort would\r\nprobably merge them, but it's not clear to me how that would affect status.\r\n> For example, IMHO the following Informational and Experimental RFCs,\r\n> being closely related to RFCs that now have been deprecated, should\r\n> be considered candidates for deprecation (being made HISTORIC) as\r\n> well, for clarity, consistency, and/or historical context:\r\n>\r\n> o RFC 1477 (IDPR Introduction);\r\n> o RFC 1482 (NSFNET Policy-Based Routing Database) -- IDPR related; \r\n> o RFC 1585 (MOSPF Analysis and Experience) -- depending on RFC 1584;\r\n> o RFC 1593 (SNA APPN Node MIB) -- 1st ed., eff.->2155->4255;\r\n> o RFC 1634 (IPX over WAN Media) -- successor to RFC 1551, the siblings\r\n> of which (RFCs 1552 and 1553) have been made HISTORIC;\r\n> o RFC 1791 (TCP+UDP over IPX); \\ both still in\r\n> o RFC 1792 (TCP/IPX MIB); / rfcxx00.txt !\r\n> o RFC 1834 (WHOIS++ Introduction);\r\n> o RFC 1875 (UNINETT PCA Policy) -- based on PEM.\r\n> \r\n> It might therefore perhaps be useful to perform a RFC 4450 like\r\n> 'experiment' for Informational and Experimental RFCs as well.\r\n> \r\n> \r\n> (4)\r\n> \r\n> The restriction in the RFC 4450 effort on Proposed Standards\r\n> detracts from the fact that there are [Full] Standard RFCs as\r\n> well which are clearly outdated, or of questionable quality and/or\r\n> precision.\r\n> My personal (incomplete) hot list of candidates comprises:\r\n> STDs 15, 16, 17, 19, 35, 40, 42, 44, 49\r\n> (Other legacy Standards doubtlessly should be updated, e.g.\r\n> STDs 5, 7, 13.)\r\n>\r\n> Note: In particular the situation with STDs 16+17 is annoying.\r\n> Replacements are established, but vendors do not switch\r\n> to SMIv2 and the newer MIBs (and do not offer SNMPv3,\r\n> with its improved security features!) because these old \r\n> specifications are still listed as Standard.\r\n>\r\n> I also strongly suspect that there are a few Draft Standard RFCs\r\n> that might be considered outdated.\r\n> \r\n> It therefore might be worth repeating the RFC 4450 'experiment' \r\n> for Draft and Full Standards as well.\r\n> \r\n\r\nAnd you might want to run that experiment. We had to start somewhere.\r\nThere is clearly more cruft.\r\n\r\nThanks,\r\n\r\nEliot\r\n\r\nfrom pending", "submit_date": "2006-03-18", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Eliot Lear", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "777", "doc-id": "RFC4234", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "3.4", "orig_text": " A range of alternative numeric values can be specified compactly,\r\n using dash (\"-\") to indicate the range of alternative values. Hence:\r\n\r\n DIGIT = %x30-39\r\n\r\n is equivalent to:\r\n\r\n DIGIT = \"0\" / \"1\" / \"2\" / \"3\" / \"4\" / \"5\" / \"6\" /\r\n\r\n \"7\" / \"8\" / \"9\"", "correct_text": "[not supplied]", "notes": "The word equivalent is correct only when US-ASCII character set is used, since:\r\n\r\nDIGIT = %x30-39 ; \r\nmeans any hexadecimal value between 0x30 and 0x39, \r\n\r\nwhile\r\n\r\nDIGIT = \"0\" / \"1\" / \"2\" / \"3\" / \"4\" / \"5\" / \"6\" / \"7\" / \"8\" / \"9\" ; \r\nmeans any digit from 0 thru 9.\r\n\r\nfrom pending\n --VERIFIER NOTES-- \nAs per Note in Section 2.3:\r\n\r\n ABNF strings are case-insensitive and the character set for these\r\n strings is us-ascii.\r\n\r\nSo these 2 representations *are* equivalent.\r\n", "submit_date": "2006-09-18", "submitter_name": "Zoltan Ordogh", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "778", "doc-id": "RFC4234", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "In Appendix B.1, it says:", "orig_text": " CHAR = %x01-7F\r\n ; any 7-bit US-ASCII character,\r\n ; excluding NUL", "correct_text": "[see below]", "notes": "NUL is not defined.\r\n\r\nSuggestions:\r\n(1)\r\nRe-write the document in a character-encoding-independent manner.\r\n(2)\r\nAdd definition of NUL (or NULL) as terminating null character - watch =\r\nout for character encoding!\r\n(3)\r\nAdd definition of NOTNULL as any character but terminating null =\r\ncharacter - watch out for character encoding!\r\n\r\nfrom pending\n --VERIFIER NOTES-- \nNUL is defined in US-ASCII.\r\n", "submit_date": "2006-09-18", "submitter_name": "Zoltan Ordogh", "verifier_id": "", "verifier_name": "Alexey Melnikov", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "779", "doc-id": "RFC4133", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "8.2", "orig_text": " [RFCYYYY] Tesink, K. and R. Fox, \"A Uniform Resource Name (URN) \r\n Namespace for the CLEI Code\", RFC YYYY, August 2005.\r\n\r\n", "correct_text": " [RFC4152] Tesink, K. and R. Fox, \"A Uniform Resource Name (URN)\r\n Namespace for the CLEI Code\", RFC 4152, August 2005.", "notes": "", "submit_date": "2005-09-22", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Ron Bonica", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "780", "doc-id": "RFC4235", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.2", "orig_text": " \r\n", "correct_text": " \r\nhttp://www.w3.org/2001/XMLSchema-instance\"\r\n xsi:schemaLocation=\"urn:ietf:params:xml:ns:dialog-info\"\r\n version=\"1\" state=\"full\" entity=\"sip:alice@example.com\">", "notes": "According to the schema in section 4.4 the attribute \"entity\" must appear on\r\nelement \"dialog-info\".\r\n\r\nfrom pending", "submit_date": "2007-01-14", "submitter_name": "Nicolas-Peter Pohland", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "781", "doc-id": "RFC4235", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.2", "orig_text": " \r\n \r\n \r\n ", "correct_text": " \r\n \r\n \r\n \r\n ", "notes": "The element must be enclosed by the element.\r\n\r\nfrom pending", "submit_date": "2007-01-14", "submitter_name": "Nicolas-Peter Pohland", "verifier_id": "", "verifier_name": "Cullen Jennings", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "782", "doc-id": "RFC2250", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "3.3", "orig_text": " Payload Type: Distinct payload types should be assigned\r\n for video elementary streams and audio elementary streams.\r\n See [4] for payload type assignments.\r\n\r\n M bit: For video, set to 1 on packet containing MPEG frame\r\n end code, 0 otherwise. For audio, set to 1 on first packet of\r\n a \"talk-spurt,\" 0 otherwise.\r\n\r\n PT: MPEG video or audio stream ID.\r\n\r\n", "correct_text": "[see notes]", "notes": "Payload Type and PT mean the same in RTP header\r\nSo, there exists a repetition.\r\n\r\nfrom pending", "submit_date": "2005-09-26", "submitter_name": "Vishal B S", "verifier_id": "", "verifier_name": "Robert Sparks", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "830", "doc-id": "RFC4342", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5", "orig_text": " The sender's measurement of the round-trip time uses the Elapsed Time\r\n and/or Timestamp Echo option contained in feedback packets, as\r\n described in Section 8.2. The Elapsed Time option is required, while\r\n the Timestamp Echo option is not. The sender maintains an average\r\n round-trip time heavily weighted on the most recent measurements.", "correct_text": " The sender's measurement of the round-trip time uses DCCP's mechanisms\r\n for round-trip time measurement. This includes Elapsed Time and/or\r\n Timestamp Echo options. As described in Section 8.2, feedback packets\r\n must carry an Elapsed Time option; Timestamp Echo is optional.\r\n The sender maintains an average round-trip time heavily weighted on the\r\n most recent measurements. Senders MAY use any available round-trip time\r\n measurements, including from the initial Request-Response packet exchange,\r\n to maintain this average. This differs from [RFC 3448], which constrains\r\n round-trip time measurements to feedback packets only.", "notes": "Clarification of round-trip time measurement.\r\n\r\nReported By: Eddie Kohler and Sally Floyd, from Gerrit Renker and Arjuna Sathiaseelan \r\n\r\nfrom pending", "submit_date": "2007-02-07", "submitter_name": "Eddie Kohler", "verifier_id": "", "verifier_name": "", "update_date": "2019-09-10 16:09:03"}, {"errata_id": "783", "doc-id": "RFC4234", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "", "orig_text": " The following clarifications apply to the meta-grammar in section 4.\r\n\r\na) Near the bottom of page 10, the rule:\r\n\r\n repetition = [repeat] element\r\n\r\n should say:\r\n\r\n| repetition = ( [repeat] element ) / option\r\n\r\n At the top of page 11, the rule:\r\n\r\n element = rulename / group / option /\r\n char-val / num-val / prose-val\r\n\r\n should say:\r\n\r\n| element = rulename / group /\r\n char-val / num-val / prose-val\r\n\r\n These changes have the effect to formally disallow\r\n a element in front of an