Original text:
8. <del> [[ Editor's Note: Should we create a registry for tokens that go into the various JSON objects used by this protocol, i.e., the field names in the JSON objects? ]] </del> 8.1. The "Well-Known URIs" registry should be updated with the following 8.6.1.  This registry lists values that are used within URN values that are provided in the "type" field of problem documents in ACME. Initial contents: The codes and descriptions in the table in errors above, with the Reference field set to point to this specification. <del> 8.6.2. </del>  This registry lists the types of resources that ACME servers may list in their directory objects. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 8.6.3. </del>  This registry lists the types of identifiers that ACME clients may request authorization to issue in certificates. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 8.6.4. </del>  This registry lists the ways that ACME servers can offer to validate control of an identifier.  The "Identifier Type" field in template

Reviewer comments:
As discussed at IETF 97, this PR creates specification-required registries of fields in ACME objects, so that they can be extended in an orderly fashion. Currently only applies to account and order objects, not authorizations. Not for any ideological reason -- I would be happy to add that for symmetry if people think there might be a need..

Revised text:
8.  8.1. The "Well-Known URIs" registry should be updated with the following 8.6.1. <ins> This registry lists field names that are defined for use in ACME account objects.  Fields marked as "client configurable" may be included in a new-account request. Template: Field name: The string to be used as a key in the JSON dictionary Field type: The type of value to be provided, e.g., string, boolean, array of string Client configurable: Boolean indicating whether the server should accept values provided by the client Reference: Where this field is defined Initial contents: The fields and descriptions defined in account- objects. 8.6.2. This registry lists field names that are defined for use in ACME order objects.  Fields marked as "client configurable" may be included in a new-account request. Template: Field name: The string to be used as a key in the JSON dictionary Field type: The type of value to be provided, e.g., string, boolean, array of string Client configurable: Boolean indicating whether the server should accept values provided by the client Reference: Where this field is defined Initial contents: The fields and descriptions defined in order- objects. 8.6.3. </ins> This registry lists values that are used within URN values that are provided in the "type" field of problem documents in ACME. Initial contents: The codes and descriptions in the table in errors above, with the Reference field set to point to this specification.  <ins> 8.6.4. </ins> This registry lists the types of resources that ACME servers may list in their directory objects. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]]  <ins> 8.6.5. </ins> This registry lists the types of identifiers that ACME clients may request authorization to issue in certificates. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]]  <ins> 8.6.6. </ins> This registry lists the ways that ACME servers can offer to validate control of an identifier.  The "Identifier Type" field in template