Subject: RE: [ietf-dkim] New issue: fate of ssp-reqs draft...

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Oct 2006 10:44:27 -0700

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: [email-masked] 
> [mailto:[email-masked]] 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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Oct 2006 21:43:25 +0200

Phill,

On the plus side, you're right that it captures a good snapshot of a 
completed milestone.  On the other hand, it's very heavy weight.  Yet 
another AD review + IETF Last call + IESG review + RFC Editor time.  If 
it helps drive IETF consensus in the end, then it is probably worth it.  
And it could in this case.

Eliot