Re: Has IANA gone mad?

[ned.freed@xxxxxxxxxxx]

> > Bruce, I'm sorry, but this is simply absurd. The IANA and the RFC Editor
> > already work together closely to coordinate this sort of thing. Specifically,
> > the editing process has a phase during which the relevant registrations are
> > completed. The actual RFC then gets published in fairly short order
> > after IANA actions are completed.

> > The notion that having dangling reference in the registry for the very short
> > period of time while the publication process is completely is a problem does
> > not pass the laugh test. I doubt very much that implemetors are going to to
> > waste time prowling the registries looking for MIME types to support, and even
> > if some people have taken sufficient leave of their senses to do this sort of
> > thing it is not a practice we should condone.

> I guess we're going to have to agree to disagree about this. I do pay attention
> to the IANA registries, and I have implemented message/tracking-status including
> provision for 2.1.9 extended status, the extended action keywords, and the
> relevant REQUIRED, MUST, and MUST NOT provisions.  But I am at a loss to provide
> a reference justifying doing so.  Since the implementation is open source and
> is not sold, I suppose I could weasel out of the RFC 2026 "vendor" clause, but
> there is still the "Under no circumstances" clause that is troubling.

I think you worry too much. The fact of the matter is that people, including
quite a few major vendors, implement internet-drafts all the time. Heck, they
even implement _unapproved_ internet-drafts all the time. (IMO sometimes this
is justified but often it isn't.) But AFAIK there have been no sightings of the
protocol police swooping down and making arrests.

> > I'm afraid you're dead wrong about this. The reality is that registration
> > problems often don't turn up until the registration has been completed and
> > reviewed as part of the publication process. Failure to perform these action
> > prior to publication can and does lead to errors that have required
> > republication in the past.

> Is the registration template in the draft of a document intended to become a
> Proposed Standard not reviewed by the IESG?

Of course it is. But if review were the same as actually performing an action,
we  wouldn't have implementation requirements for progression along the
standards track. The fact of the matter is that there can be problems that
aren't apparent at the review stage and which only turn up during the
registration process.

  Doesn't registration in the IETF
> tree require IESG review and publication as an RFC [RFC 2048 section 2.1.1]?

Of course it does. But again, review != actually performing an action.

> What about RFC 2048 [2.3.1] -- was this proposed registration posted to the
> ietf-types mailing list for review (I looked at the mailing list archives, but
> couldn't find anything in the past 4 months-- but there seems to be an awful
> lot of spam)?

I doubt it, but this step is optional in any case.

> >>Ideally the RFC and IANA registration
> >>would happen simultaneously; RFC first seems workable, but registration w/o
> >>RFC causes difficulties.
> >
> >
> > Ideally, perhaps, but it isn't practical.

> In principle, it doesn't seem to me to be a big deal to withhold publication
> (review is a separate issue) in the registry until the RFC is published...

It creates a situation where additional steps are necessary. IANA has more than
enough to do as it is, and experience has shown that adding considerable
coordination overhead just to achieve an _extremely_ slight increase in
coherency is almost never a good idea.

Even granting that such coordination wouldn't cause more problems than it 
solves, you're letting the costly best be the enemy of the much cheaper plenty
good enough.

> > > So presumably comments such as the "xtext" issue would have to be directed to
> > > the RFC editor/authors once the RFC is published.

> > The RFC Editor routinely checks for references to documents that have been
> > obsoleted. So this is almost certainly going to be caught by the editing
> > process. Of course you can always drop the RFC Editor or the authors a note to
> > make sure it gets dealt with.

> In this case it seems that the specific issue mentioned arises because text
> from RFC 1894 was cloned, and when 1894 was obsoleted, it wasn't updated.
> It's not a case of "cite by reference", which might have avoided the issue,
> but of copying of text.

Again, means exist to correct this sort of thing as part of the editing
process.

				Ned