Re: Secure Shell: Milestone Update.

[Sam Hartman <hartmans-ietf%mit.edu@localhost>]

>>>>> "Bill" == Bill Sommerfeld <sommerfeld%sun.com@localhost> writes:

    Bill>  1) go through the documents, coming up with a list of
    Bill> distinct features.  Post this feature list to the WG for
    Bill> review.


I've never advanced something to draft before, so I'll be new at this
too.  It will be a bit of a race to see whether ssh or Kerberos deals
with this documentation challenge first.

My understanding is that the construction of the feature list is the
most challenging part of the process.  You want to avoid having too
many features; treating each MUST/SHOULD/mAY as a feature is clearly
too much effort and in many cases results in untestable features.
However if your feature list is too course you risk appeal or a
discuss vote at the IESG.

I've talked to Russ about this and received some advice I'll pass
along.

Avoid getting yourself into a situation where you need to test a MUST
NOT.  For example, it would be difficult to verify conformance if you
listed "MUST NOT crash on badly formed input," as a feature.  In
general, if testing something to go to draft requires you to write
code to generate invalid input or to create a can't happen situation
then you are doing something wrong and probably doing too much work.


--Sam