Re: Watershed.

["Daniel J. Bernstein" <[e-mail]>]

First things first: I suggest once again that Ident move to some port
other than TCP port 113.

Reasons: TCP port 113 is currently in use for a protocol called TAP. TAP
is not compatible with Ident: TAP clients and servers can and do send
data which will confuse Ident servers and clients, and vice versa. TAP
is being documented by the ad-hoc TAP-std working group, which appears
to be about ready to publish its first spec. TAP is in very heavy use:
nic.merit.edu:nsfnet/statistics/1992/t1-9206.ports (the latest report
available) shows that, on the NSFNET T1 backbone, there were nearly half
a million packets for port 113 in June 1992. Only thirty ports named in
t1-9206.ports (out of several hundred) had more traffic.

I do not see how Ident can possibly be useful when its implementors will
run headlong into a large and active installed base of *incompatible*
use throughout the Internet. I do not see what conceivable advantage
there is in leaving Ident on the same port.

Ident was (despite my objections at the time) given the charter of
defining a protocol, not documenting a protocol in use. On 26 July the
Ident working group chairman and document author, Mike StJohns, stated
in response to an objection to changes from current practice, ``*sigh*
This isn't even a Proposed Standard yet - until it is, this is a real
red herring.'' Earlier, on 11 July, Mike StJohns stated, `` ... rather
than "Objection: Doesn't meet current practice" which by the way isn't a
valid objection for anything at the pre-Proposed Standard level.''

I believe that these statements by Mike StJohns are neither sane nor
proper ISOC/IAB/IESG/IETF policy. I ask Vint Cerf, in his position
within ISOC: Does ISOC condone the creation of a vaporware de jure
standard which directly interferes with an existing de facto standard?
Is current implementation practice irrelevant to documents submitted for
Proposed Standard status?

In message <[e-mail]> Mike StJohns writes:
> Its finally time to advance this thing. As of tuesday, I'll be
> sending the current draft forward and asking it be placed on the
> standards track as a Proposed Standard.

This is outrageous.

``The current draft'' is different from the latest Internet Draft.
Submitting it to the IESG without giving the community enough time to
review it---i.e., without at least two weeks as an I-D---is a blatant
violation of RFC 1310, lines 323ff. No matter how inaccurate RFC 1310
might be, I cannot believe that the IESG did not intend to guarantee a
reasonable level of community review of any standards-track document.

I ask Phill Gross, in his position within the IESG, to reject Mike's
submission on this basis. The Ident spec has many problems but this one
alone is such an imposition on the rights of the IETF that I do not see
how the document can be allowed to proceed.

I wonder how many people on the Ident list---let alone the entire
IETF---know what ``the current draft'' actually is. At one point Mike
StJohns sent two different documents to the Ident list, and he never
made clear which one was ``the current draft.''  Mike StJohns has
repeatedly stated that he will make or is making certain changes---
without identifying exactly what the changes are, let alone waiting for
consensus on the Ident list. Even in this last ``watershed'' message he
talks about publishing ``the current draft'' but then states that he's
going to make more changes.

Exactly what is ``the current draft''? Is it too much to ask that Mike
StJohns show the Ident group his document before going ahead and
publishing it in Ident's name?

Mike StJohns sent his ``watershed'' message Sunday evening. Is it
reasonable to announce a major action less than two days before doing
it?

Mike ended the ``watershed'' message with this paragraph:

> This notice represents my last call to the list for changes to the
> draft.  If you have any further comments, please make them quickly
> *with* specific suggestions for a change in language.  As I've said
> before I will not contemplate any further changes in the security
> section. 

I will refrain from commenting in detail on the level of dictatorship
implied by the final ``I will not contemplate'' sentence. Let me simply
point out some Ident history.

In mid-May I objected to the use of port 113 for Ident. A large fraction
of Ident's problems stem from its use of a port which is currently in
use for a *different and incompatible* protocol, namely TAP. But Mike
StJohns refused. (``Nice try,'' he said.)

In late June, upon request, I sent to Ident a list of 73 problems with
the current Ident spec. Most of the problems stemmed from changes which
had been introduced singlehandedly by Mike StJohns; many of them stemmed
from the incompatible use of port 113. As I pointed out at the time,
every problem could be fixed by a suggestion which had previously
appeared on the Ident list. Mike StJohns did not respond.

In mid-July Mike StJohns explicitly stated that he was ignoring me and,
in particular, my list of 73 problems. Three people (Icarus Sparry,
Anders Andersson, and Christopher Davis) immediately jumped to my
defense, pointed out various particular problems with the Ident spec,
and asked Mike StJohns to pay attention to my list. Mike StJohns did not
do so. Icarus and Christopher also supported my suggestion to remove the
Ident spec's security section entirely. Mike StJohns ignored them and
refused to allow further discussion of the security section.

Given this history, it is fraudulent of Mike StJohns to suggest that
there are no open issues on the Ident list. Only a fraction of the 73
problems I listed have been addressed. Four people have asked Mike
StJohns to address the problems. Who does Mike StJohns think he is to
say that his opinions are final and that these four people should be
ignored?

I am now raising the port number issue for a second time. Changing
Ident's port would solve many of the 73 problems. How can Mike StJohns
simultaneously (1) refuse to change the port, on such grounds as the
supposed link between RFC 931 and Ident, and (2) refuse to consider
backwards compatibility with current use of the port, let alone RFC 931?

Why is Mike StJohns so intent on corrupting port 113?

---Dan