Re: Fwd: Re: draft-ietf-tn3270e-luname-print-02.txt

[Bill Kelly <[e-mail]>]

Hi,

My 2 cents' worth on this subject...

> Bob,
>
> ...    So, at the moment, the categories--as
> far as I'm concerned--for things that describe protocol details are:
>
> (1) Informational, used only to describe current practice or some piece
> of protocol history that is of value to the community.  This category,
> IMO, should never be used for something that is a not-yet-deployed
> proposal.
>
> (2) Experimental: Any other protocol spec, especially one that
> describes something that isn't in the practice yet, that is judged not
> ready for prime time (i.e., Proposed Standard status).
>
> (3) Proposed standard.  (otherwise).

The OCS work (RFCE) should clearly not now be Informational, according to
this definition.  I'm not sure it doesn't fit into Experimental, though,
under the guise of "Any other protocol spec...that is judged not ready for
prime time".  It's just that I don't think many of us believe it should ever
be "prime time" - it should be an interim solution.

> Now, if the WG is saying that this isn't part of the current practice
> *and* isn't anything you want in a standard, then it is, IMO, a dead
> document unless there is approval to publish it as experimental.

Nobody wants it dead.  By "approval to publish it as experimental" does he
mean approval by the WG?  My impression is that that's what the WG wanted
in the first place, but was told by the IESG/IAB folks that it's not
appropriate for Experimental.  I presume he means that he'd have to do some
arm-twisting to get higher ups to agree to a classification of
"Experimental"?

> In
> that theory of the world, there are only two other courses of action:
> to make it into an appendix to the "extensions" doc or to hold it up
> until the extensions doc goes into Proposed Standard processing and
> then process this as an informational "path not taken" document.

At first I was having trouble following John's line of thought here. By
"In that theory of the world" I think he's saying "if there is no approval
to publish as Experimental"?  So that the situation is: the IESG won't
agree to Experimental, and the WG doesn't want Standard, leaving the two
options John proposes.

I presume "holding it up" means not publishing it until RFCS is submitted
as a Proposed Standard?  If so, we're probably only talking a few
weeks-to-a month or so, right?  I think that an Informational "path not
taken" classification could work out - vendors like McData, OCS, WallData,
and others who have big enough financial stakes have already implemented
it; others who don't want to wait a year or two for RFCS to grind through
the standards process can also implement it.  But they would be doing so
with the knowledge that it will become an obsolete technology once RFCS
becomes a standard.

As far as making RFCE an appendix to the standards-track RFC, I suppose
that might be acceptable as well, as long as it is done with the following
conditions:

- it is clearly identified as being nothing more than an interim
  solution, one that vendors can use until RFCS (the "Enhancements" RFC)
  becomes a Standard.  At that time, RFCS should be changed to note that
  the protocol described in the appendix is historical; better yet, the
  appendix could be removed and published as an Informational RFC (since
  I believe at that point it qualifies under John's definition (1) above).

- it is clearly identified as being authored entirely by Cleve, Michelle,
  and Tom (or whoever OCS decides is appropriate), with no direct
  connection to RFCS.

Either way (holding it up for a month or two, then publishing as
Informational -or- making it an appendix to RFCS), really boils down to the
same thing: it is not intended to be a Standard; it is a limited,
interim solution for those who *must* implement something *now*; it will
be obsoleted by the Standards RFC.

> If Erik agrees with this analysis and you, or the WG, don't, I'm happy
> to raise it with the full IESG.  But any information you can provide
> before I do that on why the WG doesn't think "experimental" would be
> appropriate would be helpful.
>
>    john

Again, I think the majority of the WG *does* want the OCS work to be
experimental; I'm a little confused by John's comments.  Who is saying
that it should not be classified as Experimental???  Bob, can you please
clarify this?

Thanks,
Bill

Bill Kelly               phone: [phone]
Auburn University     Internet: [e-mail]