Re: [NSIS] Draft-ietf-nsis-ntlp: Late change of IANA consideration section

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------