Re: reporting requirements

[Ilya N. Golubev]

> If you're going to
> insist

Insisting on nothing.  Just have no way to do so.

> that people make assumption about your setup because you aren't
> interested in describing it, then expect misleading answers.

Certainly there will always be such a risk.  The matter is how much.
Certainly operating on incomplete data involves making assumptions.
And, again (<address@hidden>), it is what people are
generally pretty good at.  Depending on responder's skill, error rate
may be pretty low, to negligible.

Far less than the rate of making assumptions directly contradicting
details already supplied in report, assuming what one can trivially
rule out by looking at such a details.  Can easily recall (and, with a
little bit more work, find in archives of mail concerning another
package) at least 1 such case.

> MUCH more aware of what assumptions they are making and performs
> sanity checks on those assumption as they go.

Note that that does not mean completely refusing to make assumptions.
And these sanity checks even do not necessarily mean requesting more
data.


> because you aren't
> interested in describing it

As already wrote (<address@hidden>), this is normally not
even the main reason.  It is much more often that it is the responders
who directly object to describing.  And certainly would rather never
receive such an objections, make it a law that one can post as much
details as deems reasonable.


> You seem quite sure about how much work it takes for me to write
> different types of replies.  Interesting.

Nothing magic.  Used and using to do a similar job on other packages.


> Right, instead of ignoring them, we ask question

The initial point was that asking like that was not only unnecessary,
but could easily make answering pointless, worthless.  Would rather
receive quite different reply, and on request will post a sample.  And
if that was impossible, in that particular case even ignoring the
report (for time just enough to write [not a bug] followup) was
better.


> Guessing what the
> other end meant is practically *banned* in many IETF protocols

"Handled gracefully" was humorous analogy, not a reference to model
deemed adequate.  So considering RFC contents in that much detail is
just not relevant.  Certainly (IETF) protocols described there are
intended to run on pretty dumb entities, ones not even remotely
capable of (again) "operating on incomplete data".