Scott, I offer the following friendly amendments.
-andy, as an individual OLD: 124 Note that the "Specification Required" policy requires review by a 125 "designated expert". Section 5 of RFC 8126 [RFC8126] describes the 126 role of designated experts and the function they perform. This 127 policy also requires "a permanent and readily available public 128 specification". RFC documents meet that requirement. Proprietary 129 specifications may meet that requirement, depending on how they are 130 archived and accessible. Internet-Draft documents do not meet that 131 requirement. RFC 2026 [RFC2026] notes that "Internet-Drafts have no 132 formal status, and are subject to change or removal at any time". NEW: Note that the "Specification Required" policy requires review by a "designated expert". Section 5 of RFC 8126 [RFC8126] describes the role of designated experts and the function they perform. This policy also requires "a permanent and readily available public specification". RFC documents meet that requirement. Proprietary specifications may meet that requirement, depending on how they are archived and accessible. RFC 2026 [RFC2026] notes that "Internet-Drafts have no formal status, and are subject to change or removal at any time". However, the IETF does allow their use for registrations into "Specification Required" registries using the process described in [RFC7120]. OLD: 150 Extensions should be evaluated for architectural soundness using the 151 guidelines described in RFC 3735 [RFC3735], including the Security 152 Considerations section of that document. Expert evaluation should 153 explicitly include consideration of the privacy consequences of 154 proposed extensions, and, at a minimum, ensure that any privacy 155 considerations are fully documented in the relevant specification(s). 156 URIs proposed in extensions (XML namespace and schema registration 157 requests are commonly found in EPP extensions) should be evaluated 158 for both syntactic and semantic correctness. XML schema and 159 namespace URIs must be registered in the IETF XML Registry using the 160 procedures described in RFC 3688 [RFC3688]. IETF namespaces must be 161 reserved for IETF specifications. Non-IETF namespaces must be used 162 for non-IETF specifications; the designated experts may need to work 163 with a registrant to identify URIs that can be added to the IETF XML 164 Registry. Extensions and any normative reference necessary to 165 implement the extension must not be denoted with "work in-progress" 166 or any similar description. NEW: Extensions should be evaluated for architectural soundness using the guidelines described in RFC 3735 [RFC3735], including the Security Considerations section of that document. Expert evaluation should explicitly include consideration of the privacy consequences of proposed extensions, and, at a minimum, ensure that any privacy considerations are fully documented in the relevant specification(s). URIs proposed in extensions (XML namespace and schema registration requests are commonly found in EPP extensions) should be evaluated for both syntactic and semantic correctness. XML schema and namespace URIs must be registered in the IETF XML Registry using the procedures described in RFC 3688 [RFC3688] unless they are defined in an Internet Draft temporarily registered in this registry according to the procedures of [RFC7120]. IETF namespaces must be reserved for IETF specifications. Non-IETF namespaces must be used for non-IETF specifications; the designated experts may need to work with a registrant to identify URIs that can be added to the IETF XML Registry. Extensions and any normative reference necessary to implement the extension must not be denoted with "work in-progress" or any similar description. OLD: 210 Document Status: The document status of the specification document. 211 For RFC documents, the possible set of values includes "Standards 212 Track", "Informational", "Experimental", "Historic", and "BCP" as 213 described in Sections 4 and 5 of RFC 2026 [RFC2026]. For documents 214 that are not RFCs, this will always be "Other". NEW: Document Status: The document status of the specification document. For RFC documents, the possible set of values includes "Standards Track", "Informational", "Experimental", "Historic", and "BCP" as described in Sections 4 and 5 of RFC 2026 [RFC2026]. For Internet Drafts, this will be "Temporary". For all other documents this will be "Other". OLD: 216 Reference: A permanent, publicly available reference to the 217 specification of this extension. This could be an RFC number or some 218 other pointer to the document defining the extension that meets the 219 "Specification Required" registry policy. NEW: Reference: A publicly available reference to the specification of this extension. For RFCs, this will be the RFC number. For Internet Drafts, this will be a reference to the draft in the datatracker. For all other documents, this will be a refernce to the extension that meets the "Specification Required" registry policy. OLD: 221 Registrant Name and Email Address: The name and email address of the 222 person that is responsible for managing the registry entry. If the 223 registration is of an IETF Standards Track extension, this can simply 224 be listed as "IESG, <[email protected]>". NEW: Registrant Name and Email Address: The name and email address of the person that is responsible for managing the registry entry. If the registration is of an IETF Standards Track extension or an Internet Draft, this will be "IESG, <[email protected]>". _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
