Secure Shell: Milestone Update.

[Bill Sommerfeld <sommerfeld%sun.com@localhost>]

As mentioned in our meeting session last week, our milestones are
extremely stale because we've been quasi-inactive until issues out of
our control were resolved

Now that the core drafts have apparently been unwedged, I propose to
update our active milestones as follows:

DELETE:

Drop            Agent draft ready for last call
Drop            Publish draft on X.509v3/pkix support

Update:

Apr 05          GSSAPI draft ready for last call
Apr 05          Resurrect and last-call newmodes
Apr 05          Resurrect and last-call secsh-break
Apr 05          File transfer draft ready for last call
May 05          IESG approval of core drafts

We have a large number of nearly complete extensions drafts which
expired while the core drafts were wedged.  Most just require a little
wordsmithing and process tweaking before they can move forward.  I'd
like to get those done soon so that we can *really* go inactive.

I'm proposing to toss two much-requested items over the side because
we've had several attempts at writing them fizzle due to lack of
energy.  The appearance of a volunteer to write them with a committed
completion date could well bring them back but I'm not holding my
breath.

On the other hand, in reviewing RFC2026's requirements for Draft
Standard,
it is apparent that we are pretty much already there:

   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level. 

The one thing we are missing is, of course:

   A specification shall remain at the Proposed Standard level for at
   least six (6) months.

The fine print:

   The Working Group chair is responsible for documenting the specific
   implementations which qualify the specification for Draft or Internet
   Standard status along with documentation about testing of the
   interoperation of these implementations.  The documentation must
   include information about the support of each of the individual
   options and features.  This documentation should be submitted to the
   Area Director with the protocol action request. (see Section 6)

*IF* I can find a volunteer willing to produce the above documentation
for two (or more) SSHv2 implementations, I'll be inclined to add an
additional:

Jan 06		Submit documentation to Security AD required to advance 		secure
shell protocol core to Draft Standard.

Comments?  I'd like to send these in by next week.

					- Bill