Subject: Has IANA gone mad?

From: Bruce Lilly <[email-masked]>
Date: Sat, 17 Jul 2004 15:43:06 -0400

Sent to ietf-822 and ietf-msgtrk mailing lists, cc to [email-masked], responses
default to ietf-822

Yesterday, "message/tracking-status" appeared in the IANA registry for MIME
message media types (http://www.iana.org/assignments/media-types/message/).
It lists "RFC-ietf-msgtrk-trkstat-05.txt" as the reference document -- of
course there is no such document.  The closest existing document is a draft
dated March 2003, more than a year old ("Internet drafts are valid for six
months").

Why on Earth did this suddenly appear yesterday?

The ietf-msgtrk mailing list appears to be dormant; in the last three months
the only message to appear on that mailing list's archive are spam messages
(http://www.imc.org/ietf-msgtrk/mail-archive/maillist.html).  There are fewer
than a dozen message in the mailing list archive in the past year, spam
included.

What's going on?!?

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sat, 17 Jul 2004 17:55:09 -0400

IANA made the assignment because this document:

http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-05.txt

was approved for publication as a Proposed Standard by the IESG on
2004-03-23 and the document is now in the RFC Editor's queue.  The IANA
actions have to be completed before the document can be finished by the RFC
Editor.

The msgtrk working group will be closed once the remaining documents (all of
which are in the RFC Editor's queue) are published as RFCs.

-Scott-
Area Advisor for MSGTRK

> -----Original Message-----
> From: Bruce Lilly [mailto:[email-masked]] 
> Sent: Saturday, July 17, 2004 3:43 PM
> To: ietf-msgtrk mailing list
> Subject: Has IANA gone mad?
> 
> 
> Sent to ietf-822 and ietf-msgtrk mailing lists, cc to 
> [email-masked], responses default to ietf-822
> 
> Yesterday, "message/tracking-status" appeared in the IANA 
> registry for MIME message media types 
> (http://www.iana.org/assignments/media-types/message/).
> It lists "RFC-ietf-msgtrk-trkstat-05.txt" as the reference 
> document -- of course there is no such document.  The closest 
> existing document is a draft dated March 2003, more than a 
> year old ("Internet drafts are valid for six months").
> 
> The ietf-msgtrk mailing list appears to be dormant; in the 
> last three months the only message to appear on that mailing 
> list's archive are spam messages 
> (http://www.imc.org/ietf-msgtrk/mail-archive/maillist.html).  
> There are fewer than a dozen message in the mailing list 
> archive in the past year, spam included.
> 
> What's going on?!?
> 
>

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 18 Jul 2004 16:13:37 -0400

> actions have to be completed before the document can be finished by the RFC

While I can understand the rationale, it does pose some difficulties for
implementors; lacking an RFC, implementors are at somewhat of a loss to
provide justification for handling the MUST, MUST NOT, REQUIRED, etc.
provisions of the applicable specification ("Under no circumstances
should an Internet-Draft be referenced [...[ nor should a vendor claim
compliance with an Internet-Draft" -- RFC 2026).  Some coordination
between the rfc-editor and IANA would be helpful to implementors. Having
the RFC first (which includes the registration template information for
the relevant media type) would not be a problem, as I see it. whereas
the current situation (registered media type with no document that can
be referenced) does pose problems.  Ideally the RFC and IANA registration
would happen simultaneously; RFC first seems workable, but registration w/o
RFC causes difficulties.

> which are in the RFC Editor's queue) are published as RFCs.

It's a shame that the draft in question (16 months old) has a number of
oddities -- being based on RFC 1894 -- which have been corrected in RFC 3464
(e.g. reference to "xtext", which would by analogy be equivalent to me
pointing out that dictionaries provide a definition of the word "rhinoceros",
which is otherwise not used anywhere in this message).

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

---

From: [email-masked]
Date: Sun, 18 Jul 2004 13:25:34 -0700 (PDT)

> between the rfc-editor and IANA would be helpful to implementors.

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.

> Having
> the relevant media type) would not be a problem, as I see it.

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.

The approach that's currently used is both practical and has not produced the
many operational problems other approaches we've used in the past have had.

> whereas
> be referenced) does pose problems.

I disagree.

> Ideally the RFC and IANA registration

Ideally, perhaps, but it isn't practical.

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

				Ned

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 18 Jul 2004 17:40:34 -0400

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

> 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?  Doesn't registration in the IETF
tree require IESG review and publication as an RFC [RFC 2048 section 2.1.1]?
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)?

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

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

---

From: [email-masked]
Date: Sun, 18 Jul 2004 15:38:50 -0700 (PDT)

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

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

> couldn't find anything in the past 4 months-- but there seems to be an awful

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

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

> It's not a case of "cite by reference", which might have avoided the issue,

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

				Ned

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sun, 18 Jul 2004 19:33:47 -0400

> Is the registration template in the draft of a document 
> intended to become a Proposed Standard not reviewed by the 
> IESG?  Doesn't registration in the IETF tree require IESG 
> review and publication as an RFC [RFC 2048 section 2.1.1]?
> 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)?

Ned was the shepherding AD before I completed the IESG actions on this
document.  He knows the history better than I do, but I can confirm (as I
said in my original reply) that this document _was_ reviewed and approved by
the IESG.  It _will_ become an RFC.  You can check the status, including all
of the relevant IESG comments and dates, using the I-D tracker:

https://datatracker.ietf.org/public/pidtracker.cgi

-Scott-

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 19 Jul 2004 19:49:17 -0400

> protocol police swooping down and making arrests.

Sure, there's no enforcement -- but I still want to do the right thing w.r.t.
not citing drafts as references.  My case is perhaps a bit unusual (the
implementation is a validating parser, which can emit a message including
references when there's a standards violation or potential interoperability
issue).

> coherency is almost never a good idea.

It seems to me that having IANA update the registry *twice* (once with the media
type and a bogus pointer to a non-RFC, and then again when the RFC is published)
would be more work than updating it *once*.  Alternatively, since the registry
is in HTML format, the incomplete information could be commented out until RFC
publication; if I recall correctly, it's not at all difficult to do in Adobe
PageMill 3.0 (which is apparently what IANA uses).

The msgtrk issue isn't the first or only (or even the worst) problem; sometime
last November, IANA also introduced message/CPIM, and after 8 months or so, there
still isn't any RFC reference -- and the draft had already passed its expiration
date by last November (the cpim draft expired about a year ago, in July 2003).
Now I'm not sure exactly what you meant earlier by "The actual RFC then gets
published in fairly short order after IANA actions are completed", but I think
we probably have a different idea of what constitutes "fairly short order".

I don't want to belabor the point; message/CPIM with no RFC was an annoyance, but
was until recently the only unresolved entry in the message media type registry.
With the addition of message/tracking-status -- with message/CPIM still unresolved --
I hope I'm not seeing the continuation of a trend.

---

From: [email-masked]
Date: Mon, 19 Jul 2004 23:23:02 -0700 (PDT)

> not citing drafts as references.

If you really believe this you're completely missing the point of the IETF
process. There are drafts and then there are drafts. Referencing a random draft
that Joe Blow put out there is one thing, referencing a draft that has been
approved for publication as an RFC is quite another. An approved draft in
effect _is_ a standard; it just hasn't completed the publication process yet.

I note in passing that it is easy to determine the status of any draft;
this is what the datatracker is for.

Now, you may argue that there's some chance that a document may change or even
be withdrawn between the time it is approved and the time it comes out as an
RFC. But the validity of this concern doesn't stand up when you examine the
publication record -- there have only been a couple of times this sort of thing
has happened. There have been many more cases where something that was approved
as proposed standard was substantially changed when the document was revised
and republished, so if you're going to get tense about stuff changing on you,
you'd best not touch anything that hasn't made it to standard status.

> My case is perhaps a bit unusual (the

I see nothing unusual about it, nor do I see any problem with such an
implementation being based on an approved draft.

> would be more work than updating it *once*.

Performing several separate actions that require no special coordination is
much, much easier than performing even one action that would have to be tightly
coordinated.

>  Alternatively, since the registry

Sorry. The goal here is to get things checked, checked, and rechecked; a
commented out registration entry isn't readily visible for authors to check and
approve. So, while this might be easy for IANA to do, doing so breaks a much
more important aspect of the process.
 
> date by last November (the cpim draft expired about a year ago, in July 2003).

First, draft-ietf-impp-cpim-msgfmt-08.txt was approved as a proposed standard
back in October, 2003. (I again note that you could have determined this by
checking the datatracker.) Drafts approved for publication do not expire; the
notion that this registration was based on a draft that has now expired is
totally  bogus.

Second, this document is currently in 48 hour author review (a fact you could
have easily determined by checking the RFC Editor queue), so its publication is
imminent.

> we probably have a different idea of what constitutes "fairly short order".

The editing process for most documents is pretty quick. However, there are
sometimes exceptions - a document will have some issue or other that prevents
its publication as an RFC from occurring in a timely fashion.

If memory serves, draft-ietf-impp-cpim-msgfmt-08.txt was delayed due to
some normative references not being available. This sort of thing
happens from time to time.

> I hope I'm not seeing the continuation of a trend.

If the trend you refer to is the immediate appearance of IANA registrations of
stuff that appears in approved drafts, it is a trend I for one would love to
see continue, regardless of the time it takes for the drafts the registry
refers to to complete the publication process.

				Ned

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 20 Jul 2004 05:01:15 -0700

--On 2004-7-19 11:23 PM -0700 [email-masked] wrote:

> I note in passing that it is easy to determine the status of any
> draft; this is what the datatracker is for.

And I note in passing, for the UMPTEENTH time, that the bloody 
datatracker is buried in such a non-obvious place that expecting anyone 
to use it is pointless. (Use it? How on earth do you expect anyone to 
even FIND it?)

Either put the bloody thing UP FRONT ON THE RFC AND ID pages at 
ietf.org, or burn it.

--lyndon

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 20 Jul 2004 08:32:27 -0400

> Either put the bloody thing UP FRONT ON THE RFC AND ID pages at 

Among any of those umpteen times, did you happen to mention the situation to
the IETF Secretariat?  If brought to their attention I'm sure they'd be
willing to put a link to the tracker in an obvious place.

I'll send a request myself momentarily.

-Scott-

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 20 Jul 2004 06:42:22 -0700

--On 2004-7-20 8:32 AM -0400 Scott Hollenbeck <[email-masked]> 
wrote:

> Among any of those umpteen times, did you happen to mention the
> situation to the IETF Secretariat?  If brought to their attention I'm
> sure they'd be willing to put a link to the tracker in an obvious
> place.

Yes (via the AD (Ned), and to the RFC Editor). (And I suspect via 
ietf@, although it has been long enough that I no longer remember.)

--lyndon

---

From: [email-masked]
Date: Fri, 23 Jul 2004 07:46:22 -0700 (PDT)

> Either put the bloody thing UP FRONT ON THE RFC AND ID pages at

Yes, well, I've passed your concern about this on in the past. The response was
to add a link at the top of the IESG Activities/Actions page, the logic being
that the status tracker is an IESG entity. (I note that a link to the RFC
Editor queue appears in a similar position under the "RFC Pages" link.) I
personally would prefer to have a link on the main IETF page but nobody else
seems to think this is appropriate.

OTOH, there are these things called bookmarks. You only have to find it
once...

				Ned

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 23 Jul 2004 11:22:44 -0400

> seems to think this is appropriate.

FWIW there's now a link on the Internet-Drafts page:

http://www.ietf.org/ID.html

-Scott-

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 23 Jul 2004 23:59:56 -0400

[email-masked] wrote:

> There are drafts and then there are drafts. Referencing a random draft

From the point of view of being able to say RFC NNNN section W.X.Y.Z says
foo is prohibited/required, a draft is a draft and there is no RFC until
there is an assigned RFC number.

> this is what the datatracker is for.

I have no idea who this Darth Racker person is :-).  I know about the
rfc-index on the isi.edu ftp site.  If RFC 3232 hadn't superseded
the Assigned Numbers RFC with the IANA web-based "database" that prompted
this discussion, I'd still be checking RFC XX00 (RFC 1700 successor)
for the relevant assigned numbers.  I haven't looked at the IESG home
page in probably a year or more -- why should I; I haven't seen any RFC
listed in the rfc-index declaring the rfc-index obsolete.

> so if you're going to get tense about stuff changing on you,

Change isn't the problem, it's having (or not having) a stable
document which can be referenced w.r.t. specific requirements and/or
prohibitions (recommendations, etc.). Since "published RFCs never
change" (except when they're revised via errata), an RFC may be
referenced, whereas referring to a draft is verboten.  To give
more perspective on the situation, I have no problem in referring
to 30-year-old RFCs where appropriate (it is occasionally necessary
to read old email, for example) with confidence that the referenced
RFC hasn't changed since publication (modulo published errata), and
that the referenced RFC is available to anybody who cares to refer to
it (modulo hard disk crashes at ISI).

> implementation being based on an approved draft.

Until publication, there's no RFC number to refer to.  And the draft is
ephemeral; it is (theoretically) removed after 6 months.  A  validating
parser validates according to a collection of specifications and in
the event of a violation of some provision, it is desirable (to say the
least) to refer to the particular specification which applies. For example,
while RFC 2822 has no requirement w.r.t. the number of message header fields
specifying recipients, RFCs 822, 733, and 724 do/did require at least one of
To, Cc, or Bcc header fields. And as you know, MIME message/rfc822 has
yet a different set of requirements.  It does no good (ignoring the prohibition
against referring to drafts for the moment) to refer to draft-foo-bar-baz-MM
as a specification, not only because that specification might change, but
also because it may be unavailable in future to those who wish to consult
that reference.

> checking the datatracker.)

Again, I know nothing about "datatracker", and judging by recent comments
here, I'm not the only one. [And putting a link on some obscure web page isn't
likely to change that.]  If the draft was approved, what is its RFC
number?

> Drafts approved for publication do not expire; the

So drafts expire after six months except when they don't. Okaaaaay...
And when something suddenly appears in the IANA registry with no reference
in the rfc-index, all there is is (maybe) some draft which nobody is
supposed to refer to because "drafts are not standards".  No RFC number to
refer to.

> have easily determined by checking the RFC Editor queue), so its publication is

I see no mention of any "queue" in the rfc-index. And today, well over 48
hours after your message, I still see no RFC corresponding to either the
CPIM or msgtrk drafts in the latest rfc-index.  So not only do we apparently
have a different concept of "fairly short order", but also of "48 hours"
and/or "imminent".

> refers to to complete the publication process.

The trend is the departure from the situation prior to the discontinuation
of the Assigned Numbers RFC, where the assigned numbers could be easily
referenced back to a published RFC.   The change to a web-based conglomeration
has happened, and I have adapted -- despite many seemingly irrelevant changes
to formatting, inconsistencies (text files for some items, HTML for others,
etc.), spurious changes to the modification dates with no substantive change
to the content, etc.  However, the appearance of registered magic "numbers"
prior to publication of an RFC that can be referenced is a great departure
from the situation that existed when the Assigned Numbers RFC was periodically
published.

---

From: [email-masked]
Date: Sat, 24 Jul 2004 09:12:49 -0700 (PDT)

> there is an assigned RFC number.

But there is a document that has been approved at some standard level. Standard
!= RFC.

> listed in the rfc-index declaring the rfc-index obsolete.

Sigh. Nobody ever claimed that the RFC Index is obsolete, only that it
doesn't tell the whole story. Reductio ad absurdum weakens your
argument, it does not strengthen it.

> prohibitions (recommendations, etc.).

You're missing the point. An approved draft is a document that isn't
supposed to change in any significant way prior to publication as
an RFC. Cases where changes have occurred are much rarer than cases
where an RFC is obsoleted by something that's substantially different
than the original.

> Since "published RFCs never
> referenced, whereas referring to a draft is verboten.

And if this concerns you you should wait until the RFC is out.

> likely to change that.]

The other comments, such as they are, were from people concerned that it was
hard to find the tracker page. They most certainly weren't ignorant of its
existance, as apparently you were.

> If the draft was approved, what is its RFC number?

You are being absurd again. Approval of documents has never coincided with RFC
publication for at least as long as I've been a participant in the IETF - that
is, since 1989. Maybe it did before that - I wouldn't know.

> So drafts expire after six months except when they don't. Okaaaaay...

It most certainly is OK, your sarcasm notwithstanding. And when the document is
published the draft is replaced with a tombstone pointing at the published RFC.

> I see no mention of any "queue" in the rfc-index.

Your ignorance of the process the RFC Editor has been using for quite a while
now doesn't do your argument any good.

> And today, well over 48

Once the RFC is complete the RFC Editor asks authors for review. The review is
supposed to be done within 48 hours. However, since this is a volunteer
organization the RFC Editor has no ability to insist on timely review. Rather
than published something that the authors haven't had a chance to look at
(which has been shown over and over and over again to result in documents full
of errors), the RFC Editor generally will extend the period as needed.
Additionally, if the author finds typographical errors in the draft the token
goes back to the RFC Editor to deal with the errors. So the final step can take
longer in some cases.

> from the situation that existed when the Assigned Numbers RFC was periodically

Bruce, I'm afraid I find your position to be totally without merit,
preposterous, and absurd. I also find your apparent ignorance of the IETF
process and the tools used to support that process to be nothing short of
appalling. Things like the RFC Editor queue and the datatracker were introduced
years ago with not inconsiderable fanfare. They have also been discussed at
great length on various lists.

In any case, I no longer have time to waste on this silly arugment, so this
will be my final message on the topic.

				Ned