Re: [apps-discuss] APPSDIR review of draft-ietf-appsawg-media-type-regs-07

[Ned Freed <[e-mail]>]

> >>  In the case of registration for the IETF itself, the registration
> >>  proposal MUST be published as an RFC.  When the RFC is in the IETF
> >>  stream it is an IETF Consensus RFC <xref target="RFC4844"/> , which
> >>  can be on the Standards Track, a BCP, Informational, or Experimental.
> >>  Registrations published in non-IETF RFC streams are also allowed, and require
> >>  IESG approval.

> > By definition, when an RFC is published "for the IETF itself", it is on the IETF
> > stream, so the first and second sentences aren't well-aligned.

Actually, that's not true. As noted below, the IAB stream is a different stream
yet pretty clearly part of the IETF. But it is entirely possible for a document
in the Independent Stream to be produced and published at the instigation of
the IETF and intended for the IETF's benefit.

> That text is Ned's original as tweaked by my suggestion, so it's at
> least half mine.  Let me explain, and we can see if there's a better
> way to say it.

> Look above that, and see that we have cases 1 and 2: case 1 involves
> IETF registrations, and case 2 involves registrations by other SDOs.
> There are then two paragraphs that say, "the first procedure" and "in
> the second case", also referring to (1) and (2).  I think you're OK
> with that.  Now, this text is again referring to the first case (and
> the next graf addresses the second).  The bit about "the IETF itself"
> is meant to be as opposed to other SDOs, and is meant to include the
> IAB, IRTF, and even Independent streams.

> As I look at it again, I think it might be better to fold these two
> paragraphs into the previous two.  How does this look, replacing the
> four paragraphs after the two numbered bullets?:

> -------------------------------------
>    The first procedure is used for registering registrations from IETF
>    Consensus documents, or in rare cases when registering a
>    grandfathered (see Appendix A) and/or otherwise incomplete
>    registration is in the interest of the Internet community.  The registration
>    proposal MUST be published as an RFC.  When the RFC is in the IETF
>    stream it is an IETF Consensus RFC, which can be on the Standards
>    Track, a BCP, Informational, or Experimental.  Registrations
>    published in non-IETF RFC streams are also allowed, and require IESG
>    approval.

>    In the second case the IESG makes a one time decision on whether the
>    registration submitter represents a recognized standards body; after
>    that, a Media Types Reviewer (Designated Expert or a group of
>    Designated Experts) performs the Expert Review as specified in this
>    document.  Subsequent submissions from the same source do not involve
>    the IESG.  The format MUST be described by a formal standards
>    specification produced by the submitting standards body.
> -------------------------------------

> Ned might prefer that the documentation requirements remain in their
> own paragraphs, in which case we might just replace "In the case of
> registration for the IETF itself" with "In case (1), above," or some
> such.  But I kind of like the version that merges these paragraphs.

No, this is better because (1) It's shorter and (2) It groups the materal
relevant to a particular procedure together. However, it orphans the next
paragraph that also discusses IETF documents. But there's no problem making
that part of the first paragraph, which gives us:

   The first procedure is used for registering registrations from IETF
   Consensus documents, or in rare cases when registering a
   grandfathered (see Appendix A) and/or otherwise incomplete
   registration is in the interest of the Internet community.  The
   registration proposal MUST be published as an RFC.  When the RFC is
   in the IETF stream it is an IETF Consensus RFC, which can be on the
   Standards Track, a BCP, Informational, or Experimental.
   Registrations published in non-IETF RFC streams are also allowed, and
   require IESG approval.  A registration can be either in a standalone
   "registration only" RFC or incorporated into a more general
   specification of some sort.

   In the second case the IESG makes a one time decision on whether the
   registration submitter represents a recognized standards body; after
   that, a Media Types Reviewer (Designated Expert or a group of
   Designated Experts) performs the Expert Review as specified in this
   document.  Subsequent submissions from the same source do not involve
   the IESG.  The format MUST be described by a formal standards
   specification produced by the submitting standards body.

I could maintain the split of the first paragraph, but beyond that ... please
consider the audience. This is not talking to some random person who wants to
register something; it's talking to people who involved in a standards process.
For better or worse, a barrier every standards process I've ever seen - and
I've been involved in several - imposes on participants is a basic
understanding of that process. So all this wordsmithing is accomplishing ...
what, exactly?

Anyway, modulo the paragraphing, I'm now going to regard this as closed 
unless someone comes up with a *really* cogent argument to make further
changes.

				Ned