Folks,
Having restricted access to the net is forcing me to see working group
activity in batches. This can be helpful for noticing patterns,
trends, and the like. (It also means I do not get to do coordination
with others before posting things. Hence, this is an entirely personal
posting rather than one being made "on behalf of" the CSV team.)
The current effort to compare CSV "versus" SPF, prompts me to notice
that there is no working group effort on a specification called "SPF",
nevermind "Unified SPF", Sender ID, or whatever other variant names
and versions might be used. There are a couple of IETF working group
documents that derive from those outside efforts, but folks do not
seem to be referring to working group documents. Yes, the marid-core
document cites SPF all over the place, but even it acknowledges that
it needs to fix those references.
Obviously the chairs will correct me if this assessment is wrong. In
that case I will ask them to point me to the working group
specifications for these other proposals. Failing that, I will ask
about the schedule for getting those proposals documented in the
working group.
CSV is a concrete specification, contained in three, concise
documents, totalling 36 pages, including the usual, repetitious
boilerplate. CSV provides for very narrow functionality, so it is easy
to understand what it is trying to do and to analyze how it performs.
The specifications have undergone relatively little conceptual or
functional change. Changes have been for clarification and
correctness. This is what incremental effort towards a stable
specification requires.
By contrast, discussions about "SPF" frequently treat hypothetical
capabilities, deployed capabilities, and multiple specifications of
capabilities as if they were all the same, single, concrete
technology. Perhaps other folks can keep clear what is concrete and
what is vague, but I can't.
It is always easy to appear to win an argument if one is not burdened
with the requirement to be concrete and stable, and abstract
hypotheticals are treated the same as reality. Easy, but not
technically productive.
When a specification is questioned along the lines of "how does this
work, exactly?" or "what happens in this case?" or "where does the
specification say that?" or the like, it is _always_ useful.
When a concrete specification is compared to an entire suite of
variant specifications and undocumented concepts, it is _never_ useful
for the technical quality of the effort, because it permits
assumptions and implications to diverge or slip through unrecognized.
This working group has some official documents. I would like to ask
that the working group discuss those documents and that it discuss
them incrementally. Incremental discussion and resolution is clearly
what Andrew is seeking, by virtue of the kinds of questions and action
items he has been posting. What I believe needs to change is the scope
of the working group's consideration of this family of technologies
and ideas currently going under the label "SPF".
Specifications and undocumented concepts that are outside the working
group ought to remain outside.
Undocumented concepts are, of course, fine to consider for inclusion
in the working group, but a concept is always vague and its utility is
typically not very high until it achieves relatively stable
documentation. The draft-ietf-marid-submitter specification is a
particularly good example of this process of incorporation. It went
quickly from basic idea to clear, concise, concrete specification. Now
folks can conduct concrete analysis on it.
So:
This is a formal request to the working group chairsm, to clarify
and restrict working group discussion to working group
specifications.
I think competitive analysis is a Good Thing. But it needs to based on
concrete, incrementally stable specifications.
Constantly shifting sands are far too difficult to stand on.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>