Subject: [spfbis] Comments on draft-ietf-spfbis-experiment-04

From: SM <[email-masked]>
Date: Thu, 19 Apr 2012 11:40:57 -0700

Hello,

These comments on draft-ietf-spfbis-experiment-04 are merely 
editorial.  It's not a review.

In Section 1:

   "over a period of two years from publication in order to determine a"

I suggest: from the date of publication.

In Section 2.1:

   "Two large-scale DNS surveys were run that looked for the two"

I suggest adding a reference to RFC 1035.

BTW, DNS RR Type could be used throughout the draft for consistency.

In Section 2.2:

   "It is likely impossible to determine from a survey which MTAs (Mail
    Transfer Agents)"

Reverse the MTAs and the term in full (expand on first use).

In Section 2.2:

   "The [OPENSPF] web site maintains a list of known implementations"

I would drop known as it cannot list what is unknown.

In Section 2.3:

   "An unknown number of clients implement SUBMITTER."

I suggest: SMTP clients.

   "An active survey was done of a large number of running and publicly
    reachable MTAs."

What is an active survey?

   "The vast majority of the MTAs advertising SUBMITTER were different
    instances of one MTA.  That MTA was a mail filtering service,
    which reports that about 11% of all observed SMTP sessions involve
    clients that make use of SUBMITTER."

I suggest

     The vast majority of the MTAs advertising the SUBMITTER SMTP extension
     were different instances of one MTA. It was reported by the mail filtering
     service operating that MTA that about 11% of all observed SMTP sessions
     involved SMTP clients that make use of the SUBMITTER SMTP extension.

In Section 5:

   "It is standard procedure within the IETF to document as standard
    those protocols and practices that have come into sufficient common
    use as to become part of the basic infrastructure."

I would drop this.  The charter already allows 4408bis to be 
published on the Standards Track.

   "In light of the this and the analysis in the previous section, the
    working group recommends to the IESG the following:"

We are not talking as a working group or to the IESG here.  This is 
an IETF document.

       "The experiment comprising the series of RFCs defining the
        SUBMITTER SMTP extension, the Sender-ID mechanism, the Purported
        Responsible address algorithm, and SPF, should be considered
        concluded."

I would rewrite this as:

      The experiments documented in RFC 4405, RFC 4406, RFC 4407 and 
RFC 4408 are
      considered as concluded.

In Appendix A:

   "the rigors of the RFC publication process."

I suggest "Internet Standards Process".

    "Later, after type 99 was assigned"

I would say publication of RFC 4408 (Andrew might know about the 
procedure at that time).

   "document, in fact), a plan was put into place to effect a gradual"

Why the plan is not documented?  It would be easier to say that (DNS) 
RR Type 99 did not see widespread adoption for:

   3.  the substantial deployed base was already using RR Type 16, and it
        was working just fine, leading to inertia;

And move (3) to the top.

      "[SPF] itself included a faulty transition plan, likely because of
        the late addition of a requirement to develop one: It said a
        server SHOULD publish both types and MUST publish at least one,
        while a client can query either or both, which means both can
        claim to be fully compliant while failing utterly to
        interoperate."

I would put this to lack of IETF review.

    "It is likely that this will happen again if the bar to creating new
     RR types even for experimental development purposes is not lowered"

Why? :-)

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Apr 2012 21:08:55 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Thursday, April 19, 2012 11:41 AM
> To: [email-masked]
> Subject: [spfbis] Comments on draft-ietf-spfbis-experiment-04
> 
> Hello,
> 
> These comments on draft-ietf-spfbis-experiment-04 are merely editorial.
> It's not a review.
> 
> In Section 1:
> 

OK.

> I suggest adding a reference to RFC 1035.

OK (though done earlier, since that's not the first reference to the DNS).

> BTW, DNS RR Type could be used throughout the draft for consistency.

I've seen the nomenclature "RRtype" used a lot.  For now I've changed it to this throughout the document.  Andrew, you read a lot of DNS stuff, what's the current popular favourite?

> Reverse the MTAs and the term in full (expand on first use).

OK.

> I would drop known as it cannot list what is unknown.

OK.

>    "An unknown number of clients implement SUBMITTER."

I think that's obvious from the context, but OK.

> What is an active survey?

"active" means you initiated the contact; "passive" is the opposite, meaning you waited for something to contact you.  Thus, an active survey of MTAs is one where a bunch of connections to MTAs in the wild are made and the results observed.

>      involved SMTP clients that make use of the SUBMITTER SMTP extension.

OK, with slight tweaks of my own.

> I would drop this.  The charter already allows 4408bis to be published
> on the Standards Track.

I don't think the charter comes into play here.  The reason this text is there is to set up the rest, especially the part where we think SPF deserves advancement to the standards track.

> We are not talking as a working group or to the IESG here.  This is an
> IETF document.

Many IETF documents act as communications to or within the IETF; BCPs for example, and I suspect some Informational ones as well.

I think what we have is reasonable because the IESG Note basically gave an assignment to the community.  The response can reasonably be addressed to them.

Either way, I think there has to be a sentence or two that sets up the major conclusions list.  Do you have an alternative to propose?

>       The experiments documented in RFC 4405, RFC 4406, RFC 4407 and RFC 4408 are
>       considered as concluded.

We didn't list the RFC numbers elsewhere, but only listed references.  I could re-insert the references here if you prefer.

> I suggest "Internet Standards Process".

How about "IETF standards track process"?

> I would say publication of RFC 4408 (Andrew might know about the

I believe the assignment came a short while before publication.  Scott would know that history better than me, short of going back to look at the mxcomp archive.

> Why the plan is not documented?

It was, as part of RFC4408, namely the MUST publish one and SHOULD publish both stuff referenced later.

> It would be easier to say that (DNS)

Are the other things in that list not valid?

Why is that reordering easier?

> I would put this to lack of IETF review.

How about adding: "Publication occurred without proper IETF review, so this was not detected prior to publication." ?

>      RR types even for experimental development purposes is not lowered"

"Insanity is doing the same thing over and over again but expecting different results."

I'm sure we haven't seen the last policy idea that will try to use the DNS for transport.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 17:39:21 -0400

On Thursday, April 19, 2012 09:08:55 PM Murray S. Kucherawy wrote:
> I believe the assignment came a short while before publication.  Scott would
> know that history better than me, short of going back to look at the mxcomp
> archive.

The assignment came shortly before the AUTH48.  IIRC, we had a week or so two 
experiment with having two types and still be able to impact what became RFC 
4408 (there were some significant AUTH48 changes as a result).

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 17:43:17 -0400

> I suggest: from the date of publication.

The IESG note in RFC 4408 includes:

   The community is invited to observe the success or failure of the two
   approaches during the two years following publication, in order that
   a community consensus can be reached in the future.

I'd suggest "during the two years following publication"

I.e. use the IESG wording here exactly.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 17:50:52 -0400

>         claim to be fully compliant while failing utterly to

Why should this be moved to the top.  From the perspective of the lack of 
transition, it is the least important point listed.  This is an 
interoperability bug, not a transition bug.  It might be better to say RFC 
4408 included no transition plan.  The only fix that would have made any 
operational sense when RFC 4408 was published would have been to make 
publishing and checking TXT mandatory.  That would be made the already 
vanishingly small chance of transition even that much smaller.

> I would put this to lack of IETF review.

What lack of IETF review?  Even though there was not a consensus call for the 
draft that became SPF, Wayne Schlitt was very careful to solicit reviews from 
the relevant IETF experts, including getting reviews on namedroppers.

The real problem is that the RR Type for Type SPF was only assigned very 
shortly before AUTH48  so there was virtually no time to experiment with using 
both TXT and SPF toghether.  The multiple RR type design we have is a paper 
design plus a week of playing around with code.  It is much, much less mature 
than the basic protocol and it shows.

Scott K

---

From: SM <[email-masked]>
Date: Thu, 19 Apr 2012 14:34:07 -0700

Hi Murray,
>OK (though done earlier, since that's not the first reference to the DNS).

I haven't given sufficient consideration to the references section as 
this was not a review.

>I've seen the nomenclature "RRtype" used a lot.  For now I've 
>changed it to this throughout the document.  Andrew, you read a lot 
>of DNS stuff, what's the current popular favourite?

I'll defer to Andrew.

>"active" means you initiated the contact; "passive" is the opposite, 
>meaning you waited for something to contact you.  Thus, an active 
>survey of MTAs is one where a bunch of connections to MTAs in the 
>wild are made and the results observed.

I see.  It's not clear to the reader.

>I don't think the charter comes into play here.  The reason this 
>text is there is to set up the rest, especially the part where we 
>think SPF deserves advancement to the standards track.

Ok (as my comments were editorial).

>Many IETF documents act as communications to or within the IETF; 
>BCPs for example, and I suspect some Informational ones as well.

Yes, but it doesn't fit this WG unless it is using pre-evaluation I-Ds.

>I think what we have is reasonable because the IESG Note basically 
>gave an assignment to the community.  The response can reasonably be 
>addressed to them.
>
>Either way, I think there has to be a sentence or two that sets up 
>the major conclusions list.  Do you have an alternative to propose?

I'll do that during a review.

>We didn't list the RFC numbers elsewhere, but only listed 
>references.  I could re-insert the references here if you prefer.

I'll defer to you.  This is probably a matter of style.

>How about "IETF standards track process"?

No, it's better not to invent that. :-)

>I believe the assignment came a short while before 
>publication.  Scott would know that history better than me, short of 
>going back to look at the mxcomp archive.

I probably did not explain the point correctly.  Please ignore my comment.

>publish both stuff referenced later.

I'll leave this for a review.

>Are the other things in that list not valid?

Yes, as editorial.

>Why is that reordering easier?

It starts with the main point.

>How about adding: "Publication occurred without proper IETF review, 
>so this was not detected prior to publication." ?

I'll leave this for a review if it is ok with you.

>I'm sure we haven't seen the last policy idea that will try to use 

The point was RR assignments. :-)  There was some discussion about 
this on another list.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Thu, 19 Apr 2012 15:53:45 -0700

Hi Scott,
>Why should this be moved to the top.  From the perspective of the lack of

The comment was editorial.

>What lack of IETF review?  Even though there was not a consensus call for the

It's an individual opinion.  A consensus call doesn't bring 
much.  It's more than a matter of soliciting reviews.

Regards,
-sm

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Apr 2012 22:27:28 -0400

Dear colleagues,

No hat.

> I've seen the nomenclature "RRtype" used a lot.  For now I've changed it to this throughout the document.  Andrew, you read a lot of DNS stuff, what's the current popular favourite?

RFC 1034 spells it RR type.  See section 3.3.

RFC 2929, the 2000-era "DNS IANA Considerations" spelled it RR TYPE.
The IANA registry says Resource Record (RR) TYPEs.  Replacements of
2929 (5395 and 6195) have spelled it RRTYPE.

Many of us spell it RRTYPE just because "type" is such a common word.

I cannot recall seeing it as "RRtype", but that doesn't mean I
haven't.  

> I don't think the charter comes into play here.  The reason this text is there is to set up the rest, especially the part where we think SPF deserves advancement to the standards track.

I get SM's worry, though: it sounds like the document is attempting to
make claims about how the IETF works, and there's no reason for us to
say anything about it.  What about this

    It is reasonable to conclude the experiment by making observations
    about which protocol has been most widely deployed, and
    standardizing it.  

?
    
> How about "IETF standards track process"?

The official name from BCP 9 is "Internet Standards Process".

> I believe the assignment came a short while before publication.  Scott would know that history better than me, short of going back to look at the mxcomp archive.

There is a fascinating nest of trouble here.  The expression
"attractive nuisance" comes to mind.

RFC 4408 was published in 2006.

The RRTYPE assignment rules were, at the time, "IETF Consensus", as
established by RFC 2929.  However, perhaps amusingly, RFC 4020, which
allowed for early IANA allocation of standards track code points, was
published in 2005.  It appears that the SPF dispute was part of the
impetus for this.  (Also, for the replacement of the rules in 2929
with something rather less absurd.)

Better still, the earliest discussion of the SPF RRTYPE I am able to
find in the namedroppers archive is from a request to add an agenda
item to the meeting at IETF 61.  That was in 2004.  (I found this in
the marc.info archive, because the IETF namedroppers archive doesn't
go back that far, and the administrator of psg.com helpfully took the
namedroppers archive off the Internet over a year ago -- with adequate
libation you can probably get me to rant about this event -- so I
might have missed something; but I don't think so.)

However, RFC 4408 never was IETF consensus, of course -- that was in
fact the point of the publication as it happened.  Even under the
rules of RFC 4020, I don't think 4408's RRTYPE request met the rules.
So one can argue that the assignment of RRTYPE 99 _at all_ was an
error.  Isn't this fun?

It seems to me that, unless we want to convene a meeting of the IETF
Old Fart's Club so that we can debate this arcane point of IETF
history, it would be better to stick to Murray's original
formulation.  It elides the details with no loss of accuracy.

> How about adding: "Publication occurred without proper IETF review, so this was not detected prior to publication." ?

I think having a bunfight about who dropped this particular ball is a
good way to distract people from the main conclusion.  I wouldn't bother.

(I will say that I fully expect a lot of complaining and defensiveness
over this entire appendix, and I'm not sure that it'll do more good
than harm.  It reads awfully finger-waggy to me, even if I'm in a
super sympathetic mood.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Apr 2012 22:51:29 -0400

Dear colleagues,

No hat.

On Thu, Apr 19, 2012 at 05:50:52PM -0400, Scott Kitterman wrote:
> 
> What lack of IETF review?  Even though there was not a consensus
> call for the draft that became SPF, Wayne Schlitt was very careful
> to solicit reviews from the relevant IETF experts, including getting
> reviews on namedroppers.

Having just waded through a great deal of that review, I am not
entirely sure that the solicitation resulted in a lot of good feelings
on either side.  TXT was just part of that train wreck.

But in the interests of not needlessly opening old train-induced
wounds, I really think that -- absent a lot of textual evidence and,
maybe, references to interviews with the principals -- we ought to
stand mute about the causes of past events.  It's enough to say in
this document that as a matter of fact there is a serious problem in
the way the two RRTYPEs are used in the protocol.  It doesn't matter
why it happened.  Any case where you have two different RRTYPEs used
to do approximately the same thing runs the same risk, and it's a
needless one.  That's the core point of the text, and it seems worth
making as a contribution to future interoperability.

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 23:26:34 -0400

> making as a contribution to future interoperability.

I agree with this.  The one point that (and it doesn't matter why it happened 
this way) I think it important to consider for future efforts is that because 
the RR Type was assigned late there was almost no time to do the running code 
part of rough consensus and running code (ironically, because it was an 
experimental RFC the rough consensus part was skipped too).

Late assignment was a problem that the IETF needs to be careful to avoid in 
the future.  I don't care about digging into why or who's fault it was.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2012 03:31:02 -0000

>experimental RFC the rough consensus part was skipped too).

Even if the language had been right, it's hard to imagine a transition
from one RRTYPE to another once there's any installed base at all.

R's,
John

---

From: SM <[email-masked]>
Date: Thu, 19 Apr 2012 20:27:07 -0700

>No hat.

bis. :-)

>I cannot recall seeing it as "RRtype", but that doesn't mean I

Thanks for documenting this.

>say anything about it.  What about this

Yes.  And it's good to remember that this WG is also part of the IETF.

>     about which protocol has been most widely deployed, and

As my comments were editorial, I don't have any preference.

>"attractive nuisance" comes to mind.

Yes.

>namedroppers archive off the Internet over a year ago -- with adequate

I may have a backup of that list from a mirror.

I did some quick cross-checking.  I would not get into the historical 
details as part of a review unless there isn't any other option.

>So one can argue that the assignment of RRTYPE 99 _at all_ was an

:-)

>than harm.  It reads awfully finger-waggy to me, even if I'm in a

I expect trouble.  The draft could be cleansed by getting an external 
review before it gets to Last Call.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 23:35 -0400

On Friday, April 20, 2012 03:31:02 AM John Levine wrote:
> >I agree with this.  The one point that (and it doesn't matter why it
> >happened this way) I think it important to consider for future efforts is
> >that because the RR Type was assigned late there was almost no time to do
> >the running code part of rough consensus and running code (ironically,
> >because it was an experimental RFC the rough consensus part was skipped
> >too).
> 

I agree and that was obvious from the start, but the lack of time to 
experiment almost led us to deliver a spec that would have made it even 
harder.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Apr 2012 23:36:23 -0400

> the future.  I don't care about digging into why or who's fault it was.

Aha.  Well, that problem is solved now, so I don't think we need to
comment on it either.  (RRTYPE assignment is now by expert review.
The last one took 3 weeks.  It was for TLSA, which is what DANE is
working to produce.)  

RRTYPEs that require special processing (think DNAME or DNSKEY) still
require IETF consensus, and you can't really do early assignment in
those cases, because it's dangerous.  You need to do a lot of lab
experiments, instead.  Nobody wants these kinds of things, normally,
however, so it's not a problem we need to solve, I think.

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 23:52:55 -0400

> however, so it's not a problem we need to solve, I think.

OK.  Then maybe we should mention the problem and congratulate everyone on 
having solved it in the meantime so we're not just complaining.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Apr 2012 05:16:16 +0000

> Sent: Thursday, April 19, 2012 8:27 PM
> To: [email-masked]
> Subject: Re: [spfbis] Comments on draft-ietf-spfbis-experiment-04
> 

I don't understand this comment.  Has someone forgotten that?

> >than harm.  It reads awfully finger-waggy to me, even if I'm in a super
> >sympathetic mood.)
> 

I think that would be a Fine Thing.

I agree with the "finger-waggy" characterization, but the pain to which the work was subjected really needs to be avoided.  It made a big mess even without the fervent participant behaviour six years ago.  Although it feels like it's better now, there's no BCP in place act like a stopper against it happening again.  If this could be a first step in such a direction, I think it's worth the risk.

And if this is something the working group wants to say (and this is the first expression of any sort of concern about it), then we should try to say it.

At the same time, if there's truly no path forward including it, then I'm happy to take it out of here and see if it can find a home elsewhere.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Apr 2012 05:19:27 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, April 19, 2012 8:53 PM
> To: [email-masked]
> OK.  Then maybe we should mention the problem and congratulate everyone
> on having solved it in the meantime so we're not just complaining.

Does someone want to suggest replacement text for the Appendix to this end, or following Andrew's suggestion?  Or are we talking about leaving it?

It's late and I'm having trouble following what it is we think we should be saying instead of what's there now.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Apr 2012 05:25:56 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Thursday, April 19, 2012 10:19 PM
> To: [email-masked]
> It's late and I'm having trouble following what it is we think we
> should be saying instead of what's there now.

Also, I'm applying the change to use "RRTYPE" now, with a definition up front for good measure.  I'll post -05 shortly.  I suggest we start WGLC on -05 and revise Appendix A as part of that since it's the only part we seem to still be discussing, and it's not really part of the meat of the work.

-MSK

---

From: SM <[email-masked]>
Date: Thu, 19 Apr 2012 23:32:31 -0700

Hi Murray,
>I don't understand this comment.  Has someone forgotten that?

I don't know.  That didn't even cross my mind.

>I agree with the "finger-waggy" characterization, but the pain to 
>which the work was subjected really needs to be avoided.  It made a 
>big mess even without the fervent participant behaviour six years 
>ago.  Although it feels like it's better now, there's no BCP in 
>place act like a stopper against it happening again.  If this could 
>be a first step in such a direction, I think it's worth the risk.

BCPs cannot fix such problems in my humble opinion.  It's up to 
participants to figure out how to resolve issues.

>And if this is something the working group wants to say (and this is 
>the first expression of any sort of concern about it), then we 
>should try to say it.

I think that it is up to the working group to devise what it wants to say.

>At the same time, if there's truly no path forward including it, 
>then I'm happy to take it out of here and see if it can find a home elsewhere.

I'll stay out of this.

>should be saying instead of what's there now.

Take a break.

Regards,
-sm