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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf