Telnet Environment Option appeal

[[e-mail]]

Marjo,

This note is intended to summarize actions and close the loop
on the HP protest about the Telnet WG's choices about the
handling of the environment option.  I've waited to send it
until we had the final form of the WG's revised proposal in
hand and I could again review everything that led up to it.

The essence of your original protest was that, in proposing
to replace RFC 1408, a Proposed Standard on the Telnet
Environment Option, with a revision that "corrected" some
values that were improperly transcribed into 1408 from a
reference implementation, the WG was acting improperly and
that, since HP (and possibly others) had an installed base
that followed 1408 as specified, preference should be given
to the literal text of 1408, rather than what it was intended
to mean.  You also suggested that it would set a very bad
precedent for IETF to be recognizing "reference
implementations" in preference to published RFCs and that
more clarification of what implementors were expected to do
at different maturity levels in the standards process would
be in order.

There is no disagreement about these last two points,
although the delicate balance between the advantages of early
implementations and avoiding deployment of things that might
change has proven difficult to capture in specific text.

The "reference implementation" versus "published RFC" issue
really does not apply in this case.  It would with a full
standard, and, except in unusual circumstances, with a draft
standard.  But proposed standards exist precisely so that
implementation experience can be gained and flaws in the
specification identified and corrected.  As we have
discussed, if an obviously severe problem had been
identified, there would be enthusiasm, presumably from HP as
well as everyone else, for fixing it, even if the fix were
incompatible.  What makes this case difficult is the
essential triviality of the problem.

Whether a problem is trivial or significant in its impact and
consequences, the Area Directors and IESG will not
second-guess a working group's technical conclusions at the
Proposed Standard level, at least as long as those
conclusions are a priori reasonable.  The integrity of the
IETF process seems to rest on that principle, and
well-meaning attempts to violate it by IESG or IAB have led
to serious problems.  Technical decisions don't come
top-down.  What the Areas and IESG can, and must, do is to
try to guarantee that all significant viewpoints have been
heard from and all significant technical alternatives have
been given reasonable consideration.  In this particular
instance, that might or might not have been the case prior to
your protest, but it is certainly the case today.

There was also no disagreement that the error in RFC 1408
created a mess, and that installed base would be negatively
impacted whether your preferred solution (carrying the RFC
1408 definitions into the new version) or the WG's original
proposal (using the intended definitions in the new version)
was adopted.   Since the two approaches do not interoperate
without some special and careful coding, it was clear that
the "new version" could not be published as a Draft Standard,
regardless of the choice that was made.

We asked that the WG reconsider the situation, considering
all possible options.  We advised the WG that it would
probably be architecturally unwise to carry an approach into
a final standard that would require a kludge or heuristic
code of all implementations for all time, even if such a
solution might be attractive, as an option, for vendors
interested in maximum interoperability with older
implementations.

After lengthy discussion, both in Amsterdam and on its
mailing list, the WG concluded that the best solution for the
long-term was to deprecate the old environment option and to
establish a new one, with a new code and to publish
guidelines for interoperation with the older form (whether
implemented according to strict reading of RFC 1408 or
according to the reference implementation).  The discussions
clearly demonstrate careful consideration of all points of
view and a rational balancing of long-term and short-term
considerations.   Consequently, I have accepted a request
from the WG to propose the current environment option text
(draft-ietf-telnet-envmnt-option-02.txt) to IESG as a
Proposed Standard, replacing RFC 1408 and to propose the
interoperability guidelines
(draft-ietf-telnet-interoperability-00.txt) for publication
as a WG-produced Informational RFC.

I consider that this closes the original protest.  If you
disagree, you have the right to appeal to the full IESG by
sending a note to its chair, Phill Gross ([e-mail])
with copies to the IESG at [e-mail].

Sincerely,
   John C. Klensin
   Co-Area Director for Applications