I have to concur with this. Even though it's reasonable to assume
most list members are technical folk, that does not imply in the
slightest that they have experience or even interest in "formal
methods". I paid enough attention in Formal Methods lectures to pass
the exam, but I wouldn't feel at all comfortable working under such a
thing, let alone defining one.
Well guys, as much as we may hate doing everything formally, sometimes
we have to. We are definatly open to any suggestions as to how to make
this process a bit easier, but I don't think we can get away from
doing this :) We need some document or model to evaluate proposals,
and the requirements document is one way of doing it. If you can think
of other ways, please let us know.
I don't think the Requirements and Technical Considerations documents
are excessive, in themselves. We do have to be relatively careful to
avoid needlessly duplicating information between them, otherwise the
definitions are likely to get desynced.
Actually, I'm not entirely sure that they aren't already duplicated (in
content, if not intent or audience). I wrote my Email Authentication
proposal against the TCs, and that lets me see quite a lot of
redundancy in the Reqs.
Anyway, my point is that there's a perception of bureaucracy, if you
say "we must do this [boring paperwork] *before* we can consider that
[which might be practical]". I appreciate that is probably not your
intent. It might be useful to step back and clarify the overall
situation for us.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg