Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt; now -01

[Mykyta Yevstifeyev <[e-mail]>]

2012/2/4 Ned Freed <[e-mail]>

> > > > In Section 3.1: when specifying the procedures for registration media
> > > types
> > > > in Standards Tree, you mentioned (in terms of RFC 5226): IESG
> approval,
> > > > Specification Required, IETF Consensus, RFC Required with IESG
> Approval,
> > > > i.e. 4 different registration policies. Whereas they serve a variety
> of
> > > > possible cases, I think we would benefit from a single policy which
> would
> > > > cover all of them. I suppose it is "Specification Required with IESG
> > > > Approval" that would cover the following cases: (1) IESG-approved
> > > document,
> > > > (2) specification of other standards body; registration undergoing
> IESG
> > > > approval, (3) non-IESG-approved RFCs, registration of which also
> undergo
> > > > IESG approval. The possible cases may also be discussed, though.
> > >
> > > > MY> Also relevant in this version.
> > >
> > > If I understand what you're trying to do, not going to happen. The main
> > > point
> > > of this revision is to remove the need for the IESG to be involved in
> the
> > > approval of standards tree types from other SDOs, while retaining their
> > > role in
> > > IETF registration approval. As such, your suggestion for a single
> policy
> > > for
> > > all registrations is totally inconsistent with the fundamental goal of
> this
> > > revision.
> > >
>
> > I meant procedure for Standards Tree only, and in no way for all
> > registrations.  The four policies I listed are mentioned in Section 3.1
> > only, which defines Standards Tree procedures.
>
> But that's exactly the point. We're not talking about anything but
> standards
> tree registrations here. Yet there are two completely different processes
> for
> registering types in the standards tree. You appear to be asking for there
> to
> be only one, and having two is the entire point of this revision.
>
> Now, if you want to talk about there being a simpler or different set of
> criteria for or the other of those processes, then you're going to have to
> make
> a strong case for doing so. As it is I'm just not seeing any rationale for
> changing anything in section 3.1.
>

Mow, reading Section 3.1 of -01, I notice several inconsistencies with the
above position and between some of the document's parts.  I mean:

1)

   The standards tree is intended for types of general interest to the
   Internet community.  Registrations in the standards tree MUST be
   either:
   ...
   2.  registered by a recognized standards body using the
       "Specification Required" IANA registration policy [RFC5226]
       (which implies Expert Review).

And later, you say:

   In the second case the IESG makes the decision on whether the
   registration submitter represents a recognized standards body;

So, anyway, IESG isn't fully eliminated from this process, as they are to
decide on whether some SDO is 'recognized' standards body or not.  The
Expert Reviewer is IESG's representative, and so I don't know the reasons
to make IESG decide on 'recognized' bodies.  Additionally, in Section 8 you
ask IANA to

   maintain a list of IESG-recognized standards bodies who are
   allowed to register types in the standards tree.

and give no other provisions on this.  Is this going to be a registry or
something else, and how is it going to be filled in?  Does this mean that
once IESG allowed some SDO to register their media type in Standards Tree,
IANA will automatically add this SDO to the list?  Or something else?

2)

   Registrations published in non-IETF RFC streams are allowed and
   require IESG approval.

I don't have an idea of what "are allowed" means?  Are they to undergo this
review depending on whether their authors see it necessary?  Doesn't this
fall into the second case for registrations in Standards Tree?

3)

   Standards-tree registrations from recognized standards bodies may be
   submitted directly to the IANA, where they will undergo Expert Review
   [RFC5226] prior to approval.  In this case, the Expert Reviewer(s)
   will, among other things, ensure that the required specification
   provides adequate documentation.

Doesn't this conflict with the paragraph mentioned above in 1) about IESG's
decision on 'recognizedness' of SDO?

Summary.  The page-long description of the procedures for Standards Tree
registration will help nobody in registering media types in this tree.  I
like RFC 4288 description, and RFC 2048 description, which only contained
three paragraphs which stated these registrations must be approved by
IESG.  Now, if you want to allow other SDO to register their types without
IESG's approval, that's easy to do by only adding a few words, so stating
that IETF-sourced and grandfathered registrations in Standards Tree are
subject to IESG's approval of the document registering them (and this means
RFC 5226 IETF consensus) and registrations ibid which originate from other
SDOs are subject to Expert Review who will also review and ensure
appropriate level of documentation (and this means RFC 5226 Specification
Required).  Also it may be stated that non-IETF-stream RFCs may register
Standards Tree types with IESG's approval (that's actually what you now
have, but "are allowed" has already been commented on above).


>
> > >
> > > > Section 6: s/RFC 3978/RFC 5378/ (and in References)
> > >
> > > > MY> This is fixed.
> > >
> > > > Sections 6 and 8: As your document sets up the registry for
> +suffixes, it
> > > > should contain the description as required by RFC 5226, which it
> > > currently
> > > > doesn't have.
> > >
> > > > MY> This comment still applies.
> > >
> > > Description where? I do not understand this one. I also do not see the
> > > requirement you're talking about anywhere in RFC 5226. (The word
> > > description
> > > appears exactly twice, and neither time in a requirement.)
> > >
>
> > I mean your description in Section 6 should follow Section 4.2 of RFC
> 5226.
>
> I don't actually see anything in RFC 5226 that says you have to define
> a registry using a particular layout in your document - all it says is that
> certain information has to be provided. And with one important exception,
> all of that information is currently present, just not in that format.
>
> That said, a thought occurs. This is a new registry that's not currently
> set up, and that means we need to call out the action to create it in the
> IANA considerations section of this document. So what I'm going to do is
> add that action to the IANA considerations, which will appear as a list
> more or less conforming to the list in section 4.2 of RFC 5226. (Most of
> the list items will simply be references to other sections of the
> current document.)
>

I wasn't talking about the layout.  You could freely describe the registry
in Section 6 and then reference it later in Section 8.  But I meant you
didn't mention RFC 5226 specification policy for this registry, as well as
its name (now mentioned).  You may add some paragraph to Section 6.1
stating that this document creates the registry called "Structured Syntax
Suffix" and the registration policy is "Expert Review" with the
registration process spelled out below.  Additionally, the structure
(fields to be present in the registry itself) are to be defined.


>
> The sticking point is the initial registry content. I really don't want  to
> clutter up an important process specification that's intended to be used
> for a
> long period of time with this crap that's only useful once. (I've always
> objected to this requirement in RFC 5226 - I think it's excessive rigidity
> causes more problems than it solves.) So I'm going to try to finesse it by
> saying that an initial list of the content of the registry effectively
> already
> exists and is in IANA 's hands - it's the list of conforming suffixes in
> current use in the existing media  types registry - and direct the media
> types
> reviewers to, at the time of registry creation, extract that list and use
> it as
> the initial registry content. This also addresses the possibility that an
> additional legitimate suffix should show up and get registered under the
> current rules, making having a static list in a document somewhat
> problematic.
>

I think upon approval of the document Expert Reviewer will examine the
currently used ones, and we'll be able to publish a separate document
registering them.


>
> > >
> > > > --citing ends--
> > >
> > > You might want to look at the open issues list and consider if they are
> > > good
> > > ideas or not.
> > >
>
> > Commenting on the 'open issues':
>
> >    o  The list of fields in the registration is getting long.  Should
> >       the fields be numbered and referred to by number in order to
> >       facilitate translation into other languages and similar
> >       activities?
>
> > Whereas I'm not a native English speaker, I can say that this won't help
> in
> > translation in any way (I can't imagine such way, at least).  Also, what
> > are 'similar activities' here?
>
> Since this one is not my idea I'll let other folks respond. (It's entirely
> possible I failed to describe or justify it properly.)
>
> >    o  Currently anyone can register a vendor media type on behalf of a
> >       vendor but subsequent to that only the vendor can make changes.
> >       Do we want to retain this restriction?
>
> > I think we should allow registering vnd types by anyone with vendor's
> > approval (or by tacit agreement if vendor is ignoring the proposal), and
> to
> > change the registration in a similar way.
>
> That approach actually sounds pretty good to me. Let's see what others
> think.
>
>                                Ned
>