I believe that we should return to the original purpose of the RFC series which
was to collect an audit trail consisting of all the major milestones in the
design process.
The requirements document should become an Informational RFC as soon as
possible.
Work on the requirements document should not finish with the publication of the
RFC however. Instead it should continue as the specification document is worked
on. The specification document should reference (non-normatively) the specific
requirements that motivate each part of the design.
I would ideally like to do this by means of an explicit convention such as that
used in the EASA requirements approach. So a gravity hook would have a labelled
set of requirements:
[REQ-LEVITATE]
The gravity hook shall keep things off the floor....
[REQ-POWER]
The gravity hook shall require no external or internal power source
....
The design document would then refer to these requirements when setting out the
architecture.
This specification is designed to meet the requirements set out in [REQ]. In
particular...
Motive power for the system is provided by a perpetual motion machine in order
to meet the requirement [REQ-POWER]
Incidentally, shouldn't normative and non-normative references have different
colours or something so that readers can tell them apart easily?
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
Sent: Tuesday, October 17, 2006 4:47 PM
To: ietf-dkim
Subject: [ietf-dkim] New issue: fate of ssp-reqs draft...
This is something that I think we never decided, but now that
we're nearing closure for the open issues on the document we
should figure out its future.
Should the ssp-reqs draft:
(a) become an RFC of its own, as soon as we can do that, or,
(b) be incorporated into the eventual SSP protocol RFC or,
(c) just be allowed expire once we're done with it, or,
(d) finish it but only send it to the AD at the same time as
the SSP protocol draft?
Or, perhaps even, (e), something else?
The only reason to not choose (a) is probably that its a bit
more work and I guess means an additional IETF last call
which could mean additional delay, so I'd be marginally in
favour of (d) I think.
Thanks,
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html