Re: [spfbis] A proposed reorganization

[Scott Kitterman <[e-mail]>]

On Monday, September 17, 2012 03:58:02 PM Dave Crocker wrote:
> Scott,
> 
> On 9/17/2012 1:54 PM, Scott Kitterman wrote:
> >> 1. I cannot quite figure out what your use of "It" refers to.  My guess
> >> is that it refers to the document status, but would appreciate your
> >> clarifying or at least confirming.
> > 
> > It is the process whereby DKIM was advanced in maturity status and
> > simultaneously redefined.  It doesn't really matter though.
> 
> The fact that you continue to make such an assertion -- and to make it
> in this forum -- remains problematic.
> 
> I assume that the specific is as you cited farther down, about i=.
> Unfortunately, for its supposed relevance to the current -bis effort,
> fixing that specification error was in response to an errata, AND it was
> /before/ DKIMbis was started.  It also didn't really change DKIM, except
> for resolving a fundamental ambiguity in output semantics.

I'm glad to stop claiming the DKIM development process is a bad example as 
long as people don't claim it was a good one. 

> >> 3. You appear to believe that changing document organization somehow
> >> changes SPF syntax or semantics.  Please explain that view.
> > 
> > No.  I think the reorganization makes it harder to understand things. 
> > It's
> > the contemporaneous effort to expunge all mention of receiver policy that
> > I
> > believe changes things.
> 
> The proposal concerns reorganizing the text.  A proposal to alter
> receiver policy language is -- or should be, IMO -- a separate topic.
> 
> As for being harder to understand, there have been specific observations
> about lack of logical sequence to the existing organization and even to
> possible layering violations in the way things are documented.  The
> latter was noted as inviting reader confusion, such as about 'fail' and
> an implied requirement for doing a specific SMTP failure code.

This continues to mystify me.  If people are going to read "If you choose to 
do A, here is how you communicate that choice" as "You must do A", then 
there's no hope.  Whether the example belongs there or not, I think this is a 
poor reason t move it.  

It might better be in (from -07) the Section 9 discussion of local policy 
since there's where we discuss rejection, but I think it's useful to have a 
normative statement of what SMTP and enhanced status codes to use (since you 
can't unambiguously figure out the correct enhanced status code to use just 
from reading references).  So maybe it's better where it is.

I think there are reasonable alternatives here, but I don't think that people 
getting confused about rejection being required is a good reason to change 
anything.

snipped more DKIM references.

> >> This is called an appeal to authority:
> >>      http://en.wikipedia.org/wiki/Argument_from_authority
> >> 
> >> It has its uses, but typically is problematic.  It often is used in
> >> place of providing meaningful justification for a view.  And indeed I
> >> can't tell how you mean it to be applied here.
> > 
> > First, while it's generally problematic, the page you says states that is
> > is usually problematic because "either the Authority is not a
> > subject-matter expert, or there is no consensus among experts in the
> > subject matter".
> We can go with the latter, for the current purposes.
> 
> But you might also want to review the later section in the article,
> about Bias and prejudice.

I'm quite familiar with confirmation bias.

> > I suggest that I am a subject matter expert (on SPF) and that among such
> > subject matter experts this is general consensus on the points I'm making,
> 
> I'll assume that you are not dismissing other 'subject matter experts'
> present in this forum, or rejecting their expertise?  And even if you
> are, you are now offering yourself as the expert about experts.  That
> repeats the problem of appeal to authority.

Not at all.

> >    so
> > 
> > you objection generally good, is specifically not appropriate in this
> > case.
> > It's also an appeal to authority itself.
> 
> Wow.  That last sentence confuses the heck out of me.  In what way does
> it qualify as an appeal to authority?

It rejects my argument that I have appropriate expertise to have an authority 
position (i.e. this fits the exception case where it's OK) not by assessing the 
merits, but by referring to another authority and asserts that by definition 
any claim of authority is wrong.

> >> In the extreme, it might be your assertion that because you have not
> >> seen certain issues over the course of your extended experience, they
> >> are not real or significant issues.  Taken to its logical conclusion,
> >> that probably would mean ignoring all errata, except the ones that you
> >> have encountered.
> > 
> > My assertion is that it's evidence that there are not real or significant
> > issues.  I don't claim it's dispositive on it's own, but I think
> > operational experience and evidence should be weighed heavily.  I think
> > more than opinions of people who've just read the spec.
> 
> For a topic like document reorganization, a relevant area of expertise
> is technical editing.  Specific examples have been provided about
> aspects of the current draft that suffer in the terms of good technical
> writing and especially good specification writing.
> 
> I thought that Murray's comments on this also quite useful.

I think it's reasonable, on the basis of a claim to expertise to discuss what 
expertise is relevant.  I believe that, while technical writing experience is 
an important expertise for this discussion, it is less significant than 
experience implementing RFC 4408 and with operational use of the protocol.

Running code is important.  http://www.rfc-
editor.org/errata_search.php?rfc=5965 is out there now because when I was 
participating in the MARF working group, I hadn't implemented it yet and so it 
wasn't until I starting trying to do so, I discovered the error.

> >> One use that is probably not what you intended is that readers of RFCs
> >> also often do not understand some basic issues.  Indeed, one of the
> >> things I like about IETF specification style is that we have a freedom
> >> to include tutorial material and, more general, to attend to the
> >> pedagogic aspects of specifications more than most other standards
> >> groups.
> >> 
> >> This happens to be why I'm in favor of the proposed re-organization:  It
> >> is cleaner and follows a better logical sequence.  That makes is more
> >> helpful to a broader base of readers.
> > 
> > I disagree.  It makes splits information about related topics up and makes
> > it harder to find.  For example, if you're interested in getting feedback
> > on your SPF deployment, 4408bis (both organizations) suggests two
> > methods.  In -07 they are together.  In the reorg, they are not.  I think
> > this is the opposite of clarity.
> 
> Examples of the current document organization's conflating topics have
> been provided.  Feedback on the proposed change suggested refinements to
> it.  Certainly the kind of issue you cite would be something I'd expect
> a new and improved document organization to attend to carefully.

Except I think it's fundamentally flawed, so moving to the new organization and 
then bug fixing it won't get back to as good as what we have now.

> >> When making claims about a population -- such as the entire set of
> >> existing and potential readers of SPFbis -- it is almost never
> >> sufficient to cite only one's own experience, no matter how extensive.
> >> It's relevant, but not sufficient.
> > 
> > Of course not.  I'm interested in other people's experiences as well.  I'm
> > much less interested in comments grounded in lack of experience.  They
> > aren't all of equal value.
> 
> Forgive me, but I haven't noticed any process for assessing empirical
> knowledge being offered by others.
> 
> More significantly, what you describe is a process of deciding whether
> the person speaking is 'worthy' of their view, as opposed to a process
> of evaluating the view itself.

If 5 people agree on something, but have little experience with the topic, but 
two people, who have great experience the topic disagree, then, while both 
views should certainly be considered and evaluated, I think it's more likely 
the two with experience will have the more correct view.

> >> My own reading is that it provides more tightly coherent sequences --
> >> although I and others have noted possible ways to improve the proposed
> >> organization further --  which is exactly the opposite interpretation
> >> from yours.
> > 
> > Section 2.5 would be split in two and some information further split into
> > appendicies.  You may find each individual bit more coherent, but I think
> > that as a whole it's more scattershot.
> 
> Actually, Section 2.5 is a really good example of problematic
> conflating.  The section defines its scope as "interpret[ing] the
> results of the check_host() function".
> 
> Yet Section 2,5,4 has /normative/ text about a specific form of
> reporting AND it points elsewhere for another.
> 
> The section should confine itself to its stated goal.  Discussion of
> reporting mechanisms should be separate and later.

Or change the title to match the text.

> > snipped the IESG reference, since I replied to that already.
> > 
> >> Perhaps we can focus on the substance of suggested changes, rather than
> >> purported attributes of the speakers?
> > 
> > If one person says a spec is usable and they've actually implemented stuff
> > from the spec and one person say it is not, but they haven't, I don't
> > think those opinions are inherently equal.
> 
> Except "one person say[s] it is not" hasn't been asserted; this suggests
> that you've misunderstood the concern about document organization.

Clearly there are several people on the list who believe the current 
organization is sufficiently deficient that it's worth making life more difficult 
for the known set of implementors to improve it.

> > I believe the guidance from the chairs has made discussion of most of my
> > concerns OBE.
> 
> oh?

At the time I wrote that, I read guidance == direction, so nevermind.

Scott K