Re: [spfbis] Review of draft-ietf-spfbis-experiment-05

[Dave Crocker <[e-mail]>]

On 4/22/2012 1:58 PM, Barry Leiba wrote:
> OLD
>     After six years, sufficient experience and evidence have been
>     collected that the experiment thus created can be considered
>     concluded, and a single protocol can be advanced.  This document
>     presents those findings.
>
> I would prefer that this document avoid making pronouncements and
> stating these kinds of opinions ("a single protocol can be advanced").
>   The point of this draft is to document results.

+1


> OLD
>     Due to the absence of consensus behind one or the other, and because
>     Sender-ID supported use of the same policy statement defined by SPF,
>     the IESG at the time was concerned that an implementation of
>     Sender-ID might erroneously apply that statement to a message and,
>     depending on selected recipient actions, could improperly interfere
>     with message delivery.
>
> This seems to have a significant SPF bias.  May I suggest this?:

SPF defined the record.  It was there first.  Sender ID came afterwards, 
creating the overload.  A 'bias' in this case has rather solid 
historical precedent.


> NEW
>     Due to the absence of consensus behind one or the other and because
>     SPF and Sender-ID supported use of the same policy statement with
>     different semantics, the IESG at the time was concerned that
>     implementations of SPF or Sender-ID might erroneously apply a
>     statement that had been published with the semantics of the other,
>     and, depending on selected recipient actions, could improperly
>     interfere with message delivery.

My above comment notwithstanding, this wording looks fine to me, and in 
general I concur with this sort of neutral language.


> OLD
>     It is important to note that this document makes no direct technical
>     comparison of the two protocols in terms of correctness, weaknesses,
>     or use case coverage.  The email community at large has already done
>     that.
>
> I suggest "has already done that through its deployment choices."
>   Otherwise, one might wonder where the comparison that's been done is
> documented.

ok.


> OLD
>     3.  Although the two mechanisms often used different email addresses
>         as the subject being evaluated, no data collected showed any
>         substantial operational benefit (e.g., cheaper processing,
>         improved accuracy) to using Sender-ID over SPF.
>
> I suggest "to using either mechanism over the other."

Hmmm.  Different issue:  Often the email addresses are the same.  It's 
the /fields/ that are /always/ different.  I suggest changing the 
wording to say "email address fields".

Tidbits of other cleanup:

      3.  Although the two mechanisms often use different email address
          fields for evaluation, no data collected showed any
          substantial operational benefit (e.g., cheaper processing,
          improved accuracy) to using one mechanism over the other..


> OLD
>     3.  The absence of significant adoption of the [SUBMITTER] extension,
>         [SENDER-ID], and [PRA], indicates that there is not a strong
>         community prepared to develop those mechanisms beyond
>         experimental status.
>
> I would MUCH rather see this reported factually, without further
> opinion.  Something like this:
>
> NEW
>     3.  The absence of significant adoption of the [SUBMITTER] extension,
>         [SENDER-ID], and [PRA], indicates that there is not a strong
>         community deploying and using these protocols.

Here, I think I disagree.  Part of the analysis can reasonably note that 
the analysis period has gone a long time and that a failure to archive 
much traction after this long is not likely to produce better traction 
in the future.


> OLD
>     4.  Continued widespread use of [SPF] indicates it is worthy of
>         consideration for the Standards Track.
>
> I suggest this:
> NEW
>     4.  [SPF] has widespread implementation and deployment, comparable
>         to that of many Standards Track protocols.
>
> -- Security Considerations --
>
> OLD
>     This document contains information for the community, akin to an
>     implementation report, and does not introduce any new security
>     concerns.  Its implications could, in fact, resolve some.
>
> That last sentence seems odd.  Unless you want to be specific about it,
> I suggest removing it.

ok.


> -- Informative References --
>
> We can always argue whether an Informational document, by its nature,
> can have "normative" references.

There's nothing to argue about.  Many Informational documents are 
specifications.  Specifications dictate behavior (within the context of 
the specifications.) Some of the behaviors that are dictated 
fundamentally rely on external specifications that are cited. Language 
that dictates behavior is called 'normative'.  This includes such 
essential citations.

I think this is a reasonable summary of the issue:

 
http://stackoverflow.com/questions/6420522/what-does-normative-and-non-normative-mean-in-reference-to-xml


I suspect the envisioned debate is caused by confusing normative-ness 
with standards status...


 >  Still, in the sense that we use it
> here, references that are central to the understanding of the document
> at hand are usually considered to be normative.  DNS is arguable, but
> I'd say no.  I think the references to PRA, SENDER-ID, SPF, and
> SUBMITTER are normative.

You think that SPF or Sender ID could function without the DNS 
specification???  That is, what is it you think might be arguable about 
classing it as a normative reference?


d/
-- 
  Dave Crocker
  bbiw.net