Subject: RE: [ietf-dkim] SSP requirements

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 8 Aug 2006 08:50:52 -0700

OK a new point, the SSP requirements need to be addressed to different audiences:

1) Authors of software
2) Operators of software.

It seems to me that a lot of points here are only discussing the second and thus we end up with more heat than light as there is considerably greater variation in operational situations than many expect.

The specification is going to be written primarily for the authors of the software rather than operators.

So many times a MUST is going to be 'a compliant DKIM verifier MUST allow configuration X'.

I think it is reasonable to state that a compliant package MUST NOT reject verification failures out of hand. Whether that is possible is another issue since it is a policy issue and MUST is generally reserved for interface compatibility issues.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Aug 2006 16:59:17 +0100

> 2) Operators of software.

I don't recall seeing this mentioned before!

Thank you,
Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Aug 2006 09:17:58 -0700

> I don't recall seeing this mentioned before!

Are "requirements" documents now expected to contain boilerplate requirements
that apply to every single specification produced by the IETF?  How is that
helpful?

As soon as we allow items like the above onto the list, we automatically need to
list large numbers of others, concerning deployment, administration, operations
and use.  None of these will have any meaningful benefit to the list, other than
to make the list longer and to make the salient issues more obscure.

Perhaps we should restrict requirements documents to issues that are specific to
the topic at hand.  It might also help if we do more than provide an
unmotivated, cryptic laundry list, but instead explain what the issues are, with
respect to the current topic, namely SSP.

My point is that we need to but a burden on those suggesting items for the list.
 At the list, they need to explain how the item relates to the current topic and
why it is essential to class the item as a "requirement".  It would also be
reasonable to expect some discussion of possible ways the "requirement" could be
satisfied.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Aug 2006 17:26:27 +0100

> that apply to every single specification produced by the IETF?  How is that

Fair enough. But in this case, there has perhaps been some
confusion as a result of not seeing this difference, so
raising it on the list seems reasonable/useful.

It probably does map into either zero or one sentence in a
reqs. document, as you say, since its such a generic point.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Aug 2006 09:41:22 -0700

> raising it on the list seems reasonable/useful.

Dealing with confusion is almost always a good thing.  However I do not see how
a simple listing of generic "requirements" actually *deals* with the concern.

By contrast, discussion about the implications for SSP strikes as potentially
quite helpful.

The more general point, here, is that requirements that are stated in a more
general form are substantially less useful than ones that make statements that
are concrete and have some obvious or stated relationship to the particulars of SSP.

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Aug 2006 09:57:15 -0700

>> 2) Operators of software.

Hmmm.  I was so struck by the these items being entirely generic, that I missed
a deeper issue:  Who is the requirements document for?

I was under the impression that the requirements document's intended audience is
primarily those specifying the protocol and service.

Other readers are secondary.  For them the document serves as pedogogy about the
nature of the problem that the protocol and service are solving.

In other words, the requirements documents needs to tell US what functional
constraints we must satisfy with a specification that we develop.

d/
-- 

  Dave Crocker

---

From: <[email-masked]>
Date: Tue, 8 Aug 2006 13:12:21 -0400

1.) Authors of software
MUST be able to reject, accept, accept with identifiers any failure to
verify, extensible to all conditions

Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hallam-Baker,
Phillip
Sent: Tuesday, August 08, 2006 11:51 AM
To: Stephen Farrell
Cc: [email-masked]
Subject: RE: [ietf-dkim] SSP requirements

OK a new point, the SSP requirements need to be addressed to different
audiences:

1) Authors of software

It seems to me that a lot of points here are only discussing the second
and thus we end up with more heat than light as there is considerably
greater variation in operational situations than many expect.

The specification is going to be written primarily for the authors of
the software rather than operators.

So many times a MUST is going to be 'a compliant DKIM verifier MUST
allow configuration X'.

I think it is reasonable to state that a compliant package MUST NOT
reject verification failures out of hand. Whether that is possible is
another issue since it is a policy issue and MUST is generally reserved
for interface compatibility issues.

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 8 Aug 2006 18:49:23 -0400

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>

> It seems to me that a lot of points here are only discussing
> the second and thus we end up with more heat than light as
> there is considerably greater variation in operational situations
> than many expect.
>

Gee, I never thought of bringing this up as a requirement. You would think
that this would be naturally expected.

Smart move Phillip!  Thanks!

But without a doubt, I have often stated the debates are nearly always
associated with the:

   Philosophical differences between Developers and Administrators.

It happened in MARID, it happened in SPF, it happened with DKIM-BASE and it
has happening now and it will always happen were there is a mix bag of
professional disciplines.

I guess that is why we have a consensus concept, but IMV, it is typically
tilted in one direction from an administrator standpoint, atleast in the WGs
I've participated in. <g>

That isn't necessarily a problem. In this day of age where "All in One" and
integrated packages, specially those that provide scripting designs or
integration, admins have become to wear many hats, and vice a versa,
developers are often users of their own creations and no doubt have to
support their administrator customer needs.  So there is a lot of wisdom
here on both camps.

>From my standpoint, for the problem related to the abuse of mail, the time
has come where the SMTP vendor does more in the area - directly!!

However, to keep with tradition, the SMTP vendor needs to only address
strong compliancy issues with has been lacking.  This is the sound approach
that offers both technical (and legal) consistency.   These options are
programmed for administrators to use in thier local policy statements.

The rest of the "indeterminate" mail, like now, is passed on to the
administrator's other MFA (Mail Filtering Agent) tools.

In the cased of SSP, this concept is one that is better understood by
developers. When they see a DKIM-BASE and are asked to implement it,  they
have a better viewpoint of what are the implementation problems, specially
those what can be address with a SSP concept.

My personal concern, is that a standalone DKIM-BASE system has issues that
have falling thru the crack.   Some believe that a Trusted-Layer is all you
need to fix the DKIM-BASE "cracks".   That's probably true, but this is not
defined and it fast materializing as a "batteries required" concept that
will have many different market segments.   SSP is a simple concept that
deals with some rather simple policy concepts.  I believe it should be part
of the DKIM protocol like it was when it was first envisioned.  Sometimes
the best idea is the first one you think of.

DKIM + SSP is a pretty sound concept for implementation into a mail design
that I see will cater to my "operators of software" - without batteries. :-)

Hector Santos, Santronics Software, Inc.
http://www.santronics.com