Thomas,
A mistake in writing the motivation from me. It is the IANA actions that
has Standards Action that can't really be combined with experimental
status. And you and Jari has clarified why that doesn't work.
Yes, Specification Required would work, but would not require IETF last
call. Which was one of the goals here. Thus the suggested IETF review.
Magnus
Thomas Narten skrev 2010-02-03 14:55:
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
--
Magnus Westerlund
IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto:
magnus(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf