ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Lean vs. Fat 'requirements'

2006-08-10 13:18:25


Requirements,

What do I sign
Who does my signing
When does my DKIM Public Key expire
Who do I sign for
Who shall I never sign for (I sign no mail)
What receiver expectation shall I set (perhaps dodgy)

What else should be on the list?

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
bill(_dot_)oxley(_at_)cox(_dot_)com 


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hallam-Baker,
Phillip
Sent: Thursday, August 10, 2006 3:57 PM
To: Jon Callas; dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Lean vs. Fat 'requirements'


[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jon Callas

Subject: Re: [ietf-dkim] Lean vs. Fat 'requirements'

On 10 Aug 2006, at 6:55 AM, Dave Crocker wrote:

Some of us believe, rather strongly, that this is a particularly 
important "bias" to the development of the requirements list.  It 
occurs, to me, however, that it might not be clear whether there is 
working group consensus on it.

I would be interested in seeing statements of preference for, or 
against, having the requirements be minimalist, and include 
only those 
items for which there is clear rough consensus to include.

If an item engenders real wg controversy, it is *not* included.

Comments?


Minimalist good.

Blank checque vetoes bad.

The best way to make the requirements discussion interminable is to
allow groups to exercise a veto by filibustering requirements they
dislike.

I don't care about the complexity of a requirements document. All I care
about is that the complexity of the solution be minimized.

I rate the skill of a protocol designer by their ability to find simple
solutions to complex requirements.

Time after time the IETF has produced worthless trash because the
requirements analysis was either incomplete or arbitrarily constrained.
If you look at the protocols that have become overly complex the root
cause is frequently inadequate requirements analysis in the first
instance leading to protocols that acrete a missmash of ad-hoc
extensions.

The only reason that PKIX has CRLs, OCSP, SCVP, Attribute certificates
all as add on mechanisms to basic certs is because the original
requirements analysis was incomplete. The complexity of the resulting
spec is enormous.


_______________________________________________
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

<Prev in Thread] Current Thread [Next in Thread>