RFC Errata
Found 22 records.
Status: Verified (22)
RFC 5661, "Network File System (NFS) Version 4 Minor Version 1 Protocol", January 2010
Note: This RFC has been obsoleted by RFC 8881
Note: This RFC has been updated by RFC 8178, RFC 8434
Source of RFC: nfsv4 (wit)
Errata ID: 2291
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-05-27
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 18.36.3. says:
The server
MUST specify an ONC RPC program number equal to csa_cb_program and
an ONC RPC version number equal to 4 in callbacks sent to the
client.
It should say:
The server
MUST specify an ONC RPC program number equal to csa_cb_program and
an ONC RPC version number equal to 1 in callbacks sent to the
client.
Notes:
RFC5661 disagrees with RFC5662. The latter specifies a version number of 1.
Errata ID: 2005
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-01-17
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 15.1.11.3 says:
The highest_slot argument in a Sequence operation exceeds the replier's enforced highest_slotid.
It should say:
The highest_slot argument in a Sequence operation exceeds the replier's enforced highest_slotid. Also, the rsa_target_highest_slotid argument in a CB_RECALL_SLOT operation exceeds maximum enforced slot ID of the session's fore channel.
Notes:
The NFSv4.1 specification permits the client to return NFS4ERR_BAD_HIGH_SLOT in
the event rsa_target_highest_slotid is higher the highest slot ID of the
session's fore channel. Arguably this is an unnecessary complication; the client
can return NFS4_OK to sucvh a CB_RECALL_SLOT operation, and then send a
SEQUENCE operation with an sa_highest_slotid argument that is less than or
equal to rsa_target_highest_slotid. NFSv4.2 should specify this simplification.
Errata ID: 2299
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-06-03
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 18.45.3. says:
If SECINFO_STYLE4_PARENT is passed, then SECINFO_NO_NAME is querying for the required security of the current filehandle's parent
It should say:
If SECINFO_STYLE4_PARENT is passed, then SECINFO_NO_NAME is querying for the required security of the current filehandle's parent, where the current filehandle MUST be that of directory (an object of type NF4DIR).
Errata ID: 2326
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 15.1.16.3 says:
NFS4ERR_NXIO (Error Code 5)
It should say:
NFS4ERR_NXIO (Error Code 6)
Errata ID: 2327
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 6.4.3.1 says:
If the object being created is not a directory, the inherited ACL SHOULD NOT inherit ACEs from the parent directory ACL unless the ACE4_FILE_INHERIT_FLAG is set.
It should say:
If the object being created is not a directory, the inherited ACL SHOULD NOT inherit ACEs from the parent directory ACL unless the ACE4_FILE_INHERIT_ACE is set.
Errata ID: 3208
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benny Halevy
Date Reported: 2012-05-02
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16
Throughout the document, when it says:
Notes:
Section 12.5.2. says:
The first successful LAYOUTGET
processed by the server using a non-layout stateid as an argument
MUST have the "seqid" field of the layout stateid in the response set
to one. Thereafter, the client MUST use a layout stateid (see
Section 12.5.3) on future invocations of LAYOUTGET on the file, and
the "seqid" MUST NOT be set to zero.
It should say:
The first successful LAYOUTGET
processed by the server using a non-layout stateid as an argument
MUST have the "seqid" field of the layout stateid in the response set
to one. Thereafter, the client MUST use a layout stateid (see
Section 12.5.3) on future invocations of LAYOUTGET on the file, and
the "seqid" MUST NOT be set to zero.
| The client MUST serialize LAYOUTGET operations using a non-layout
| stateid with any other operation affecting the layout state on the file,
| including CB_LAYOUTRECALL, to allow consistent initialization of the
| layout state.
Add the following paragraph to section 12.5.3.:
| A client MAY always forget its layout state and associated
| layout stateid at any time (See also section 12.5.5.1).
| In such case, the client MUST use a non-layout stateid for the next
| LAYOUTGET operation. This will signal the server that the client has
| no more layouts on the file and its respective layout state can be
| released before issuing a new layout in response to LAYOUTGET.
Section 12.5.5.2.1. says:
One critical issue with regard to layout operations sequencing
concerns callbacks. The protocol must defend against races between
the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
CB_LAYOUTRECALL. A client MUST NOT process a CB_LAYOUTRECALL that
implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
to which the client has not yet received a reply. The client detects
such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
layout stateid. If the "seqid" is not exactly one higher than what
the client currently has recorded, and the client has at least one
LAYOUTGET and/or LAYOUTRETURN operation outstanding, the client knows
the server sent the CB_LAYOUTRECALL after sending a response to an
outstanding LAYOUTGET or LAYOUTRETURN.
It should say:
One critical issue with regard to layout operations sequencing
concerns callbacks. The protocol must defend against races between
the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
CB_LAYOUTRECALL. A client MUST NOT process a CB_LAYOUTRECALL that
implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
to which the client has not yet received a reply. The client detects
such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
layout stateid. If the "seqid" is not exactly one higher than what
the client currently has recorded, and the client has at least one
LAYOUTGET and/or LAYOUTRETURN operation outstanding,
| or if the client has a outstanding LAYOUTGET with a non-layout stateid,
the client knows
the server sent the CB_LAYOUTRECALL after sending a response to an
outstanding LAYOUTGET or LAYOUTRETURN.
Section 12.5.5.2.1.1. says:
It is permissible for the client to send multiple parallel LAYOUTGET
operations for the same file or multiple parallel LAYOUTRETURN
operations for the same file or a mix of both.
It should say:
It is permissible for the client to send multiple parallel LAYOUTGET
operations for the same file
| using the layout stateid
or multiple parallel LAYOUTRETURN
operations for the same file or a mix of both.
Section 12.5.5.2.1.2. says:
Note
that in the first case, the "seqid" in the layout stateid of the
recall is two greater than what the client has recorded;
It should say:
Note
that in the first case, the "seqid" in the layout stateid of the
recall is two greater than what the client has recorded,
| or the client has an outstanding LAYOUTGET using a non-layout stateid;
Errata ID: 3379
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Asmita Karandikar
Date Reported: 2012-10-15
Verifier Name: Magnus Westerlund
Date Verified: 2019-10-25
Section 18.50.3 says:
If there are sessions (both idle and non-idle), opens, locks, delegations, layouts, and/or wants (Section 18.49) associated with the unexpired lease of the client ID, the server MUST return NFS4ERR_CLIENTID_BUSY.
It should say:
If there are sessions (both idle and non-idle), opens, locks, delegations, and/or wants (Section 18.49) associated with the unexpired lease of the client ID, the server MUST return NFS4ERR_CLIENTID_BUSY.
Notes:
Should not include layouts.
A forgetful client may not return LAYOUTS. In this case, a server will always return NFS4ERR_CLIENTID_BUSY on DESTROY_CLIENTID and end up persisting the client’s lease until it expires although the client is explicitly asking us not to.
Errata ID: 4711
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2016-06-16
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-03
Section 15.1.5.5 says:
A stateid with a non-zero seqid value does match the current seqid for the state designated by the user.
It should say:
A stateid with a non-zero seqid value is not the most current seqid for the state.
Notes:
Two issues here:
1) The negation of the fact, i.e., "does not match".
2) The state is not associated with an user.
Errata ID: 5040
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Price
Date Reported: 2017-06-12
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-03
Section 18.46.3 says:
Operations other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID, CREATE_SESSION, and DESTROY_SESSION, MUST NOT appear as the first operation in a COMPOUND.
It should say:
Operations other than SEQUENCE, BIND_CONN_TO_SESSION, EXCHANGE_ID, DESTROY_CLIENTID, CREATE_SESSION, and DESTROY_SESSION, MUST NOT appear as the first operation in a COMPOUND.
Notes:
In the section for DESTROY_CLIENTID (18.50.3), the following text exists (see snipped section below).
This means that DESTROY_CLIENTID must also be in the list for operations that are allowed
in the first operation of a compound.
<...snip...>
If DESTROY_CLIENTID is not prefixed by SEQUENCE, it MUST be the only
operation in the COMPOUND request (otherwise, the server MUST return
NFS4ERR_NOT_ONLY_OP). If the operation is sent without a SEQUENCE
preceding it, a client that retransmits the request may receive an
error in response, because the original request might have been
successfully executed.
<...snip...>
Errata ID: 5467
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2018-08-17
Verifier Name: Spencer Dawkins
Date Verified: 2018-08-17
Section 15.2 says:
| LAYOUTGET | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_LAYOUTTRYLATER, | | | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_RECALLCONFLICT, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_WRONG_TYPE |
It should say:
| LAYOUTGET | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_LAYOUTTRYLATER, | | | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, | | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_RECALLCONFLICT, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, | | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE, | | | NFS4ERR_WRONG_TYPE |
Notes:
LAYOUTGET takes a stateid argument that can represent either a layout or a delegation,
or open/lock state. As such, it needs to be able to report back when the state represented
by that stateid has expired.
(Verified on NFSv4 mailing list)
Errata ID: 6015
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sushil Agarwal
Date Reported: 2020-03-12
Verifier Name: Magnus Westerlund
Date Verified: 2020-09-04
Section 17 says:
CB_SEQUENCE | OPT
It should say:
CB_SEQUENCE | REQ
Notes:
The section 20.9.3 of CB_SEQUENCE says
"In each CB_COMPOUND request, CB_SEQUENCE MUST appear once and MUST be the
first operation. The error NFS4ERR_SEQUENCE_POS MUST be returned
when CB_SEQUENCE is found in any position in a CB_COMPOUND beyond the
first. If any other operation is in the first position of CB_COMPOUND, NFS4ERR_OP_NOT_IN_SESSION MUST be returned."
Since CB_RECALL_SLOT is REQ operation in NFSv4.1. This make CB_COMPOUND as REQ procedure. Since CB_COMPOUND require CB_SEQUENCE as its first operation and hence CB_SEQUENCE must be required operation.
Errata ID: 3558
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Cal Turney
Date Reported: 2013-03-19
Verifier Name: Martin Stiemerling
Date Verified: 2013-03-20
Section 15.1.4.2 says:
In Table 5 Section 5.1 Page 342, NFS4ERR_DQUOT is defined as error number 69:
"| NFS4ERR_DQUOT | 69 | Section 15.1.4.2 |"
However, in Section 15.1.4.2 Page 349 it is identified as error code 19:
"15.1.4.2. NFS4ERR_DQUOT (Error Code 19)"
It should say:
"15.1.4.2. NFS4ERR_DQUOT (Error Code 69)"
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.
In 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.
Errata ID: 2006
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-01-17
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 15.1.1.3 says:
For any of a number of reasons, the replier could not process this
operation in what was deemed a reasonable time. The client should
wait and then try the request with a new slot and sequence value.
Some examples of scenarios that might lead to this situation:
o A server that supports hierarchical storage receives a request to
process a file that had been migrated.
o An operation requires a delegation recall to proceed, and waiting
for this delegation recall makes processing this request in a
timely fashion impossible.
In such cases, the error NFS4ERR_DELAY allows these preparatory
operations to proceed without holding up client resources such as a
session slot. After delaying for period of time, the client can then
re-send the operation in question (but not with the same slot ID and
sequence ID; one or both MUST be different on the re-send).
Note that without the ability to return NFS4ERR_DELAY and the
client's willingness to re-send when receiving it, deadlock might
result. For example, if a recall is done, and if the delegation
return or operations preparatory to delegation return are held up by
other operations that need the delegation to be returned, session
slots might not be available. The result could be deadlock.
It should say:
For any of a number of reasons, the replier could not process this
operation in what was deemed a reasonable time. The requester should
wait and then try the request with a new slot and sequence value.
Some examples of scenarios that might lead to this situation:
o A server that supports hierarchical storage receives a request to
process a file that had been migrated.
o An operation requires a delegation recall to proceed, and waiting
for this delegation recall makes processing this request in a
timely fashion impossible.
In such cases, the error NFS4ERR_DELAY allows these preparatory
operations to proceed without holding up requester resources such as a
session slot. After delaying for period of time, the requester can then
re-send the operation in question. If the operation that returned
NFS4ERR_DELAY was not a Sequence operation, the initial, preceding
Sequence operation of the Compound request MUST NOT be re-sent with same
slot ID and sequence ID; one or both MUST be different on the re-send. If
the operation that returned NFS4ERR_DELAY was a Sequence operation, then
the Sequence MUST be re-sent with the same slot ID and sequence ID.
Note that without the ability to return NFS4ERR_DELAY and the
requester's willingness to re-send when receiving it, deadlock might
result. For example, if a recall is done, and if the delegation
return or operations preparatory to delegation return are held up by
other operations that need the delegation to be returned, session
slots might not be available. The result could be deadlock.
Notes:
This errata is correcting two problems:
(1) The use of term "requester" instead of "client" since NFS4ERR_DELAY
is applicable for both the backchannel and fore channel.
(2) Clarification that NFS4ERR_DELAY from a Sequence operation is handled
differently from non-Sequence operations.
Errata ID: 2062
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Varga
Date Reported: 2010-03-04
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 2.10.6.1.3 says:
A reply that consists only of the Sequence operation with the error NFS4ERR_FALSE_RETRY. When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_FALSE_RETRY... If the replier determines the users are different between the original request and a retry, then the replier MUST return NFS4ERR_FALSE_RETRY. ...current minor version (e.g., SETCLIENTID), the replier MAY return NFS4ERR_FALSE_RETRY... The difference is due to NFS4ERR_FALSE_RETRY being a valid error for only Sequence operations...
It should say:
A reply that consists only of the Sequence operation with the error NFS4ERR_SEQ_FALSE_RETRY. When the replier detects a false retry, it is permitted (but not always obligated) to return NFS4ERR_SEQ_FALSE_RETRY... If the replier determines the users are different between the original request and a retry, then the replier MUST return NFS4ERR_SEQ_FALSE_RETRY. ...current minor version (e.g., SETCLIENTID), the replier MAY return NFS4ERR_SEQ_FALSE_RETRY... The difference is due to NFS4ERR_SEQ_FALSE_RETRY being a valid error for only Sequence operations...
Notes:
References to NFS4ERR_FALSE_RETRY instead of NFS4ERR_SEQ_FALSE_RETRY
Errata ID: 2249
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Eisler
Date Reported: 2010-05-10
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 12.5.5.2.1.5 says:
Once a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID is sent, the server MUST NOT allow the client to use any layout stateid that refers to a file with the specified fsid except for LAYOUTCOMMIT operations. Once the client receives a CB_LAYOUTRECALL of LAYOUTRECALL4_ALL, it MUST NOT use any layout stateid that refers to a file with the specified fsid except for LAYOUTCOMMIT operations.
It should say:
Once a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID is sent, the server MUST NOT allow the client to use any layout stateid that refers to a file with the specified fsid except for LAYOUTCOMMIT operations. Once the client receives a CB_LAYOUTRECALL of LAYOUTRECALL4_FSID, it MUST NOT use any layout stateid that refers to a file with the specified fsid except for LAYOUTCOMMIT operations.
Notes:
Copy/paste error from the previous paragraph. s/_ALL/_FSID/ in the second sentence of the corrected paragraph.
Errata ID: 2280
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul J Gilliam
Date Reported: 2010-05-20
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 10.4 says:
OPEN_DELEGATE_READ delegations may be outstanding simultaneously and do not conflict. An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its own, all opens. Only OPEN_DELEGATE_WRITE delegation may exist for a given file at a given time, and it is inconsistent with any OPEN_DELEGATE_READ delegations.
It should say:
OPEN_DELEGATE_READ delegations may be outstanding simultaneously and do not conflict. An OPEN_DELEGATE_WRITE delegation allows the client to handle, on its own, all opens. Only one OPEN_DELEGATE_WRITE delegation may exist for a given file at a given time, and it is inconsistent with any OPEN_DELEGATE_READ delegations.
Errata ID: 2324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Trond Myklebust
Date Reported: 2010-07-12
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 2.10.6.2 says:
A retry might be sent while the original request is still in progress on the replier. The replier SHOULD deal with the issue by returning NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but implementations MAY return NFS4ERR_MISORDERED.
It should say:
A retry might be sent while the original request is still in progress on the replier. The replier SHOULD deal with the issue by returning NFS4ERR_DELAY as the reply to SEQUENCE or CB_SEQUENCE operation, but implementations MAY return NFS4ERR_SEQ_MISORDERED.
Errata ID: 2328
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2010-07-13
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 15.1.16 says:
Notes:
From 3530:
NFS4ERR_RESOURCE For the processing of the COMPOUND procedure, the server may exhaust available resources and can not continue processing operations within the COMPOUND procedure. This error will be returned from the server in those instances of resource exhaustion related to the processing of the COMPOUND procedure.
Since it is not used by 5661, shouldn't it appear in Section 15.1.16 Obsoleted Errors?
Errata ID: 2330
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2010-07-14
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 3.3.7 says:
0 1 +-----------+-----------+-----------+-- | count | 31 .. 0 | 63 .. 32 | +-----------+-----------+-----------+--
It should say:
0 1
+-----------+-----------+-----------+--
| count | 31 .. 0 | 63 .. 32 |
+-----------+-----------+-----------+--
Errata ID: 2548
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: J. Bruce Fields
Date Reported: 2010-10-11
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 18.36.3 says:
csa_fore_chan_attrs, csa_fore_chan_attrs:
It should say:
csa_fore_chan_attrs, csa_back_chan_attrs:
Errata ID: 4215
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Haynes
Date Reported: 2014-12-30
Verifier Name: Martin Stiemerling
Date Verified: 2016-02-02
Section 22.1 says:
All assignments to the registry are made on a First Come First Served basis, per Section 4.1 of [55]. The policy for each assignment is Specification Required, per Section 4.1 of [55].
It should say:
The registry is to be maintained using the Specification Required policy as defined in Section 4.1 of [55].
Notes:
Found during the IANA Review of 3530bis.
Errata ID: 6324
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tigran Mkrtchyan
Date Reported: 2020-11-04
Verifier Name: RFC Editor
Date Verified: 2024-02-02
Section 18.23.3 says:
The request's cookieverf field should be set to 0 zero) when the
It should say:
The request's cookieverf field should be set to 0 (zero) when the
Notes:
Missing the open parenthesis