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

[Ned Freed <[e-mail]>]

> I understand what you are trying to do but it is more from this e-mail than from
> 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
> leaves me with the impression that each and every request will take up the
> 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
> 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.

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.

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

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

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