Subject: Draft-ietf-nsis-ntlp: Late change of IANA consideration section

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Feb 2010 11:19:48 +0100

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 intended to instruct the RFC-editor in 10 days time about this change.
If there are any objections please bring those forward.

Cheers

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: [email-masked]
----------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Wed, 03 Feb 2010 08:55:00 -0500

> 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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Feb 2010 16:30:06 +0200

Thomas,

> sufficiently implementable.

I do not understand this either, but I'll note that draft-ietf-nsis-ntlp 
has a ton of Standards Action IANA rules. It does not make sense to have 
such rules in a spec that itself is going for Experimental. So maybe 
Magnus should have said s/Specification Required/Standards Action/ in 
his e-mail... I would support the change of Standards Action rules to 
IETF Review.

Jari

---

From: Thomas Narten <[email-masked]>
Date: Wed, 03 Feb 2010 09:46:46 -0500

> such rules in a spec that itself is going for Experimental.

Well, this problem stems from the fact that the IETF produces all
sorts of  "mini-documents", and the appropriate status for individual
"mini-documents" is often fairly specific (e.g., BCP vs. Standards
vs. info, etc.).

But we often put them all in one document and don't worry so much
about whether the overall category of document is right for each
individual "mini-document" within the document.

I.e., one could argue that all IANA considerations should be BCPs (and
they usually are when they are standalone), but we don't ask standards
track documents to move the IANA considerations to a separate document
just to make all our categories look clean... (and for good reason!)

Thomas

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Feb 2010 16:53:18 +0200

Thomas,

> just to make all our categories look clean... (and for good reason!)

I agree, but in this case the issue is even more fundamental than the 
document structure. If FOO is experimental technology, does it make 
sense to require that extensions of FOO are standards?

Jari

---

From: Thomas Narten <[email-masked]>
Date: Wed, 03 Feb 2010 09:58:10 -0500

> sense to require that extensions of FOO are standards?

Ah, I see now. And I agree with you -- it doesn't seem to make sense!

Thomas

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Feb 2010 16:11:38 +0100

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

-- 

Magnus Westerlund