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

["t.petch" <[e-mail]>]

<inline>

Tom Petch

----- Original Message -----
From: "Ned Freed" <[e-mail]>
To: "Mykyta Yevstifeyev" <[e-mail]>
Cc: "Ned Freed" <[e-mail]>; <[e-mail]>
Sent: Sunday, February 05, 2012 7:14 AM
Subject: Re: [apps-discuss] I-D Action:
draft-ietf-appsawg-media-type-regs-00.txt; now -01


> > 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.
>
> I completely fail to see any inconsistency or the relevance of any of this.
> Yes, the IESG makes a one-time determination that a given group is in fact an
> SDO, and in almot every case this is certain to be little more than a
pro-forma
> action. So what? Once that is done they have no involvement in the media type
> approval process, which is the part that happens over and over and over again
> and has to be optimized.


Ned

I understand what you are trying to do but it is more from this e-mail than from
the I-D:-(  I do think that the I-D stresses the role of the IESG overmuch and
leaves me with the impression that each and every request will take up the
IESG's time, and only then will be approved for passing on to Expert Review
whereas your e-mail suggests that the IESG are only involved once for each SDO
and that IANA can recognise the SDO thereafter.

I think that this needs calling out more clearly, in the Abstract, since, as you
say, it is the point of the I-D.

I think too that it needs calling out because others may wonder how it will work
in practice.  Other SDOs are not like us; the interface to them is different,
some have much more formal procedures for interacting with other SDOs so the
issue of how a communication is recognised as from an approved SDO, and so not
need further IESG involvement, may be hard to achieve.  I see IETF Last Call as
the acid test of this idea so I think it needs to be in the Abstract.

So I like the idea, but wonder if it may come to grief on the politics of other
SDOs.

Tom Petch

>
> > 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?
>
> It's a list that IANA consults. It is not a registry. Exactly what the text
> says currently.
>
> > 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?
>
> The process that happens between IANA and the IESG is intentionally
unspecified
> here. Since representatives of IANA attend IESG meetings as a matter of
routine
> and routinely place items on the IESG agenga for action, what's the point of
> specifying some completely unnecessary process?
>
> Remember: The focus here is on getting things done. Not on creating
unnecessary
> bureaucracy.
>
> > 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?
>
> Not when the end result is an RFC of any sort, no. Think about it for a
minute:
> Will people understand the difference between a registration in an independent
> submission and one in a IETF document? Do you seriously think it is a good
idea
> for there to be a way to get a registration into an RFC without some sort of
OK
> from the IETF? And since the IESG reviews both non-IETF RFCs and
IETF-generated
> standards tree registrations anyway, doesn't it make sense for them to be the
> ones to do it?
>
> > 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?
>
> In no way, shape, or form does it conflict. In one case the IESG is checking
to
> see if a given organization is in fact an SDO - which will be a trivial check
> in almost every case. In the other case the expert reviewer is checking to see
> if the underlying format is properly specified. These are entirely different
> activities.
>
> > Summary.  The page-long description of the procedures for Standards Tree
> > registration will help nobody in registering media types in this tree.
>
> That may be your opinion. I doubt very much if anyone else agrees with you.
> I absolutely do not.
>
> >  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).
>
> I have no real idea what you're getting at here, but it sounds far more
complex
> that what we have.
>
> Look. There aren't that many SDOs out there that need to register media types,
> and the ones that do create type afer type after type. The approved list will
> almost immediately contain them all. Once that happens the process for an SDO
> registering a type is they fill in a form, the reviewer reviews, done.
Couldn't
> possibly be any simpler.
>
> And at this point I'm done discussing this.
>
> > >
> > > > >
> > > > > > 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.
>
> That's implicit in the template. I see no reason to repeat it and no
> requirement to.
>
> > >
> > > 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.
>
> I see no point in generating such a document.
>
> Ned
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>