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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 5 Feb 2012 08:04:30 +0200

2012/2/4 Ned Freed <[email-masked]>

> > > > 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
>

---

From: Ned Freed <[email-masked]>
Date: Sat, 04 Feb 2012 22:14:59 -0800 (PST)

> 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.

> Additionally, in Section 8 you
> ask IANA to

> 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

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.

> 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?

> 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.

> 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

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.

> (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.

> currently used ones, and we'll be able to publish a separate document

I see no point in generating such a document.

				Ned

---

From: "t.petch" <[email-masked]>
Date: Tue, 7 Feb 2012 11:28:39 +0100

<inline>

Tom Petch

----- Original Message -----
From: "Ned Freed" <[email-masked]>
To: "Mykyta Yevstifeyev" <[email-masked]>
Cc: "Ned Freed" <[email-masked]>; <[email-masked]>
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

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

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Ned Freed <[email-masked]>
Date: Tue, 07 Feb 2012 07:38:45 -0800 (PST)

> the I-D:-(

That's because the goals of the changes are irrelevant to actually performing
the process. I intentionally do not get into those, because such text almost
immediately becomes a pointless distraction to people actually trying to get
stuff registered.

> I do think that the I-D stresses the role of the IESG overmuch and
> IESG's time,

I disagree, but I'll add some clauses and a sentence clarifying that IESG
involvement is  a one time thing.

> and only then will be approved for passing on to Expert Review

> say, it is the point of the I-D.

It absolutely does NOT belong in the Abstract. Again, the the purposes and
goals of this revision are only relevant during the development process; once
this document is published as a BCP this turns into irrelevant material readers
have to wade through to undersand the point of the document as well as to get
at the actual requirements and process steps.

In fact this is very similar to the issue of putting silly "this obsoletes
that" crap in the Abstract which is being discussed in another thread. The
consensus there so far is that cluttering up the Abstract with this and similar
nonsense is a really stupid thing to be doing.

> the acid test of this idea so I think it needs to be in the Abstract.

Again the answer from me is a very, very, very emphatic NO. And as for
interactions with other SDOs that go beyond the basic process; that's not
simply a rathole, rather it's a huge chasm I have been explicitly directed by
the PTB to avoid in this specification.

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

Politics in other SDOs have been big problems in the past and I have no doubt 
will continue to be a problem in the future. But a registration process
document is not the place to get into any of this, if for no other reasons than
the issues shift over time and anything we write will quickly be dated and may
in fact become a serious liability.

That said, if you seriously want to fall into this particular chasm and go
splat at the bottem, you can always try and get some text about this into the
advisory document the HAPPIANA folks are talking about writing. My guess is the
IESG will not allow a document containing such text to go forward (I certainly
wouldn't if I were on the IESG), but of course I don't speak for them.

				Ned