> I like to inform everyone that we intended to make a post approval > change to the IANA rules for "GIST: General Internet Signalling > Transport" (draft-ietf-nsis-ntlp-20). This document is approved for > publication as experimental. In the change of intended status during > IESG processing, we failed to adjust the policies on the IANA registries > this document creates. Thus there are registries that has the policy of > Specification Required, which are almost impossible to fulfill when the > normative reference is going to be experimental. Thus we intend to > address this by changing all "Standards Action" policies to "IETF > Review" as specified by RFC 5226. I don't necessarily have an opinion about the proposed changes, but I don't quite understand the rationale. "Specification Required" is intended to allow for publication of documents outside of RFCs. It reqiures an Expert Reviewer to look at the document and make a determination about whether the spec is sufficiently implementable. That is, RFC 5226 says: > Specification Required - Values and their meanings must be > documented in a permanent and readily available public > specification, in sufficient detail so that interoperability > between independent implementations is possible. When used, > Specification Required also implies use of a Designated > Expert, who will review the public specification and > evaluate whether it is sufficiently clear to allow > interoperable implementations. The intention behind > "permanent and readily available" is that a document can > reasonably be expected to be findable and retrievable long > after IANA assignment of the requested value. Publication > of an RFC is an ideal means of achieving this requirement, > but Specification Required is intended to also cover the > case of a document published outside of the RFC path. For > RFC publication, the normal RFC review process is expected > to provide the necessary review for interoperability, though > the Designated Expert may be a particularly well-qualified > person to perform such a review. > > Examples: Diffserv-aware TE Bandwidth Constraints Model > Identifiers [RFC4124], TLS ClientCertificateType Identifiers > [RFC4346], ROHC Profile Identifiers [RFC4995]. Given that, could you please clarify what you mean by "Thus there are registries that has the policy of Specification Required, which are almost impossible to fulfill when the normative reference is going to be experimental." IMO, an experimental RFC would be fine for "specification required". Thomas _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf