Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

From: Måns Nilsson <[email-masked]>
Date: Mon, 19 Aug 2013 17:05:21 +0200

Subject: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Mon, Aug 19, 2013 at 06:19:16AM -0700 Quoting The IESG ([email-masked])
> 
> The IESG has received a request from the SPF Update WG (spfbis) to
> consider the following document:
> - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
>    Version 1'
>   <draft-ietf-spfbis-4408bis-19.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-09-02. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as
RFC unless substantial parts are reworked.

* The charter disallows major protocol changes -- removing the SPF RR type
is a direct charter violation; since SPF is being used on the Internet.

* The overloading of the TXT record is a hack at best, aimed at
circumventing DNS management systems vendors that fail to ship
support. Breaking the DNS model with specific resource records is not
the way to get better application support. (besides, the major argument
at the time was "it's so hard and takes ages to get a RR type", which
isn't true anymore and also, the RRtype is allocated, what's the fuss? )

* The empirical data that was gathered and the conclusions from which
that where published as RFC 6686 are IMNSHO flawed and rushed in that they
set far too optimistic deadlines for adaptation before declaring failure.

The IESG should send draft-ietf-spfbis-4408bis-19 back to spfbis wg and tell
the wg that instead of deprecating SPF it should be algorithmically
preferred while maintaining support for TXT.

Thanks, 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
It was a JOKE!!  Get it??  I was receiving messages from DAVID LETTERMAN!!
YOW!!

---

From: "John Levine" <[email-masked]>
Date: 19 Aug 2013 16:05:49 -0000

>is a direct charter violation; since SPF is being used on the Internet. ...

Uh huh.

$ dig besserwisser.org txt

;; QUESTION SECTION:
;besserwisser.org.		IN	TXT

;; ANSWER SECTION:
besserwisser.org.	86173	IN	TXT	"MN-1334-RIPE"
besserwisser.org.	86173	IN	TXT	"v=spf0x44 be allowed to contaminate the DNS."
besserwisser.org.	86173	IN	TXT	"v=spf0x42 besides, SPF as concept is a layering violation."
besserwisser.org.	86173	IN	TXT	"v=spf0x41 not valid. because SPF records belong in RRtype 99."
besserwisser.org.	86173	IN	TXT	"v=spf0x43 adding insult to injury, this layering violation MUST not "

$ dig besserwisser.org spf

;; QUESTION SECTION:
;besserwisser.org.		IN	SPF

;; ANSWER SECTION:
besserwisser.org.	86140	IN	SPF	"v=spf1 ip6:0::/0 -all"
besserwisser.org.	86140	IN	SPF	"v=spf1 ip4:0.0.0.0/0 -all"

R's,
John

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 19 Aug 2013 21:05:33 +0200

> >is a direct charter violation; since SPF is being used on the Internet. ...

Yes.  The TXT specification is 

"TXT-DATA        One or more <character-string>s.

TXT RRs are used to hold descriptive text.  The semantics of the text
depends on the domain where it is found."

	(RFC 1035 section 3.3.14.)

There is nothing syntactially worng with those entries. I congratulate
people advocating SPF in TXT records while also writing parsers.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Youth of today!  Join me in a mass rally for traditional mental
attitudes!

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Aug 2013 15:10:59 -0400

On Monday, August 19, 2013 21:05:33 Måns Nilsson wrote:
> Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender 
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to 
Proposed Standard Date: Mon, Aug 19, 2013 at 04:05:49PM -0000 Quoting John 
Levine ([email-masked]):
> > >...

I did check and the library I help maintain, pyspf, correctly didn't think any 
of the TXT records you have published are SPF records.  It's not that hard.  
Operationally, there are far more problems associated with actually trying to 
use Type 99 than there are with SPF records in Type TXT.

As Michael Hammer mentioned, we've been through all this before and people 
might want to review the previous WG discussion on the topic.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 19 Aug 2013 15:59:50 -0400

>>> is a direct charter violation; since SPF is being used on the Internet. ...

The SPF working group discussed this issue at painful, extensive length.

As you saw when you read the WG archives, there is a significant interop 
bug in rfc 4408 in the handling of SPF and TXT records, which (again after 
painful and extension discussion) we decided the least bad fix was to get 
rid of SPF records.  I don't see anything in your note about how else you 
think we should address the interop bug.

In your case it doesn't matter, since your TXT and SPF records make no 
usable assertions, but a lot of people use SPF right now as part of their 
mail stream management.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Aug 2013 16:08:02 -0400

Note that I am not the shepherd for this draft, but I am the WG
co-chair.

> is a direct charter violation; since SPF is being used on the Internet.

That argument doesn't work, because the WG had to make a major
protocol change in this area no matter what, since 4408 has an
interoperability problem.  If you wish to argue that the WG decided on
the wrong protocol change, that line is open to you; but nobody can
argue that the change is wrong because of our charter.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 19 Aug 2013 20:42:37 -0000

>people advocating SPF in TXT records while also writing parsers.

None of your TXT records are SPF records because they don't start with
the required version tag.  You have two type 99 records that start
with the version tag, which is invalid under section 3.1.2 of RFC 4408
and the similar section 3.2 of 4408bis.  

So you're publishing no SPF information at all.  I gather that you've
tried the popular SPF implementations like libspf2 and verified that
they correctly report that they found nothing.

I really don't understand what point you're making here.

R's,
John

---

From: HLS <[email-masked]>
Date: Mon, 19 Aug 2013 16:44:28 -0400

I'm having a hard time with both sides of the argument, especially the
supposed existence of a "interop problem" which seems to only to be
highlighted to "procedurally" stump the SPF type advocates.  I don't
believe there was an adequate answer from the advocates of removing the SPF
RR type and the repeated assertion that its been discussed at length has
not resolved the issue because it really hasn't been appropriately address.
 Its not convincing. This is the reason the issue will not go away.

My take is that the the initial MARID design expectations where being met
and to me, that is a very important design consideration in all this; what
were the original expectations with a TXT/SPF migration. Although very
slowly, there were some deployments administratively and technically.

In my estimation, the WG did receive positive support that there was
sincere interest in adding support for the SPF record type primarily
because there was some level of adoption discovered during the "interop"
report work.  You can include us (SSI) as having interest in
enabling/adding SPF record support.

I  recommend the following to basically allow IMPLEMENTATORS to decide:

1) Continue with the TXT/SPF migration plan,

2) Address any technical protocol issue with using an SPF type,

3) Add implementation designs notes on the pros and cons.

This will allow coders to add the optimized logic for usage.  It will also
allow for new problem solving seeds to be laid down. It will hopefully get
the DNS software vendors to finally add direct support for unnamed TYPE
support (query and passthru).

Finally, which is what I have been trying to get - why hasn't the IETF
taking this issue (unnamed type support) very serious? The reason I wonder
because if the DNS vendors don't address this, then to me, that should be
the only reason to remove the SPF type or even bother with any new RR type
concept.  The interop problem cited about RFC 4408 is not convincing to me.
The only reason my package as an early adopter didn't have SPF support was
purely for short term optimizations and lack of servers with unnamed type
processing  support reasons - no mas.

--
HLS

-- 
hls

---

From: Pete Resnick <[email-masked]>
Date: Mon, 19 Aug 2013 15:48:36 -0500

Speaking in my capacity as responsible AD for this WG and document, and 
the one who is going to have to judge the consensus of this Last Call 
and report to the IESG.

> argue that the change is wrong because of our charter.

To reinforce this point: Nowhere does the charter "disallow major 
protocol changes"; words to that effect do not appear in the charter. It 
does say that features in current use cannot be removed, but it also 
says that errors can be corrected. In this case the WG concluded that 
fixing the interoperability problem fell under the auspices of 
"correction of errors". The chairs agreed, and I saw no reason to disagree.

>> isn't true anymore and also, the RRtype is allocated, what's the fuss? )

This issue *was* considered and extensively discussed on the spfbis 
list. AFAICT, the conclusion the WG came to was *not* based on the 
argument that "it's so hard and takes ages to get an RR type". (Yes, the 
original decision to use TXT included that argument, but that was not 
the basis for the decision in the current WG.) And I don't know that 
anyone in the WG would disagree that "the use of the TXT record is a 
hack". The conclusion was that it was a hack that we are stuck with due 
to the current deployment profile. I think you will have to find 
something that the WG missed in that discussion to be convincing that a 
substantial change is needed.

There is no doubt the consensus in the WG was rough on the above two 
issues, but it was, by my reading, solid.

>> set far too optimistic deadlines for adaptation before declaring failure.

I think you're going to need substantially more explanation (and perhaps 
some data) to make a convincing case that RFC 6686 needs to be 
reconsidered, thereby affecting this last call. The above states a 
conclusion, but provides no data or explanation. I don't know how to 
evaluation this.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Pete Resnick <[email-masked]>
Date: Mon, 19 Aug 2013 15:55:11 -0500

My apologies: A typo rendering a sentence incoherent that I missed 
before hitting "Send":

On 8/19/13 3:48 PM, Pete Resnick wrote:
> I think you're going to need substantially more explanation (and 
> perhaps some data) to make a convincing case that RFC 6686 needs to be 

Of course, I meant, "I don't know how to *evaluate* this."

pr

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Aug 2013 13:59:39 -0700

> Of course, I meant, "I don't know how to *evaluate* this."

 From earlier exchanges about this concern, the assertion that I recall 
is that 7 years is not long enough, to determine whether a feature will 
be adopted.  That is, failure to gain deployment traction after 7 years 
from the time of publication should not be taken as a sufficient waiting 
period.

I do not recall anyone (else) showing support for that view, but 
certainly not any substantial constituency.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Aug 2013 14:04:10 -0700

On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker <[email-masked]> wrote:

> From earlier exchanges about this concern, the assertion that I recall is
> that 7 years is not long enough, to determine whether a feature will be
> adopted.  That is, failure to gain deployment traction after 7 years from
> the time of publication should not be taken as a sufficient waiting period.
>
> I do not recall anyone (else) showing support for that view, but certainly
> not any substantial constituency.
>
>
Moreover:

What is the premise for seven years being "not long enough"?  And what does
constitute "long enough"?  And upon what is that last answer based?

It would be wonderful if the boundaries for this test were written down
somewhere, so that we would've had that information when we did the
research for RFC6686.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Aug 2013 14:06:07 -0700

On 8/19/2013 2:04 PM, Murray S. Kucherawy wrote:
> Moreover:
>
> What is the premise for seven years being "not long enough"?  And what
> does constitute "long enough"?  And upon what is that last answer based?
>

Well, they were written down 15 years ago, but they haven't gained 
traction yet, though I remain hopeful.

d/

---

From: Hector Santos <[email-masked]>
Date: Mon, 19 Aug 2013 17:10:27 -0400

Hi,

I'm having a hard time with both sides of the argument, especially the 
supposed existence of an "interop problem" which seems to only highlight 
how to "procedurally" stump the SPF type advocates with a "error 
correction" standpoint.   What is that error by the way?

I don't believe there was an adequate answer from the advocates of 
removing the SPF RR type and the repeated assertion that its been 
discussed at length has not been convincing it was appropriately 
addressed. It all seem to be a "Shut up" approach to the problem (always 
suggest that its been discussed already). This seems to be one of the 
reasons why the issue will not go away.

My take is that the initial MARID design expectations were being met. 
This fact is a very important design consideration in all this; the 
original expectation for a TXT/SPF migration, although very slowly, 
there were some deployments administratively (publishers) and 
technically (processors). I would like to point out the lack of a 
majority does not/should not represent a lack of interest.

In my estimation, the WG did receive positive support expressing sincere 
technical interest in adding support for the SPF record type primarily 
because there was some level of adoption discovered during the "interop" 
report work.  Please include us (SSI) as having interest in 
enabling/adding SPF record support.

I recommend the following to be considered to basically allow 
implementators to decide:

1) Continue with the TXT/SPF migration plan, fix up this plan,

This will allow coders to add the optimized logic for usage.  It will 
also allow for new problem solving seeds to be laid down. It will 
hopefully get the DNS software vendors to finally add direct support for 
unnamed TYPE support (query and passthru) not only for SPF but for 
future DNS application protocols.

Finally, which is what I have been trying to get - why hasn't the IETF 
taking this issue (unnamed type support) very serious?

This is an integration DNS issue - not just an SPF issue. If the DNS 
vendors don't address this, this, to me, would be the only logical and 
feasible reason to remove the SPF type or even bother with any new RR 
type concept.  The interop problem cited to exist within RFC 4408 is not 
convincing to me.

Overall, as an early adopter, the only reason my package doesn't have 
SPF support was purely for short term optimizations and lack of servers 
with unnamed type processing support - no mas.   If we remove SPF 
support, then we lost it forever.  I don't think we have viewed a 
possible long term solution from an integrated protocol standpoint.

--
HLS

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Aug 2013 17:41:39 -0400

I'm not going to copy the spfbis WG list on this, because this is part
of the IETF last call.  No hat.

> > adopted.

> constitute "long enough"?  And upon what is that last answer based?

I have two observations about this.  First, EDNS0, which is of
significantly greater benefit to DNS operators than the mere addition
of an RRTYPE, took well over 10 years to get widespread adoption.
Second, we all know where IPv6 adoption stands today, and that has
certainly been around longer than 7 years.  So I think it _is_ fair to
say that adoption of features in core infrastructure takes a very long
time, and if one wants to add such features one has to be prepared to
wait.

But, second, I think all of that is irrelevant anyway.  The plain fact
is that, once 4408 offered more than one way to publish a record, the
easiest publication approach was going to prevail.  That's the
approach that uses a TXT record.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Aug 2013 14:47:14 -0700

On 8/19/2013 2:41 PM, Andrew Sullivan wrote:
>    So I think it _is_ fair to

As long as the generic topic is being commented on...

The difference between a "slow" adoption rate and an adoption rate of 
essentially zero is fundamental.    So yes, a pure single number of 
years can be misleading and needs some sense of whether the is any 
progress at all.

There also needs to be some care about marking the start of the clock, 
given that some technologies have multiple components needed before they 
are worth adopting, and an initial, incomplete set might be published 
before a sufficient set is available.

d/

---

From: Pete Resnick <[email-masked]>
Date: Mon, 19 Aug 2013 16:47:55 -0500

I will let the document shepherd/editor address particular points in 
this and other messages, but on one procedural point:

On 8/19/13 4:10 PM, Hector Santos wrote:
> removing the SPF RR type...

That's an appropriate issue to raise during Last Call, and I expect the 
shepherd to elaborate on why the WG came to its conclusion, and you to 
follow up with more explanation if you still think it is inadequate. 
However:

> ...and the repeated assertion that its been discussed at length has 
> not been convincing it was appropriately addressed. It all seem to be 
> a "Shut up" approach to the problem (always suggest that its been 
> discussed already). This seems to be one of the reasons why the issue 
> will not go away. 

The above is *not* appropriate to raise. The first part is attributing 
motives to folks, which is out of line. Even if the motives of folks 
asserting these things *were* malicious, I am expected to call the 
consensus on the basis of the technical arguments and to ignore the 
motives, and that is what I plan to do. And the last sentence above is 
trying to divine the psychological state of the IETF as to why or why 
not it continues to discuss an issue, an equally inappropriate and 
unproductive thing to do during Last Call.

Let's stick to issues and not delve into these areas please.

pr

---

From: David Conrad <[email-masked]>
Date: Mon, 19 Aug 2013 14:54:44 -0700

Hi,

> use Type 99 than there are with SPF records in Type TXT.

Given the abysmal state of implementation of middleboxes _today_, this isn't surprising.  I'm unsure this sad state applies for all future time to come.

> might want to review the previous WG discussion on the topic.

+1

However, despite the operational issues mentioned above and the fact that this has been discussed to death, I also strongly oppose the deprecation of the SPF record. AFAICT, no one is arguing that overloading TXT in the way recommended by this draft is a good idea, rather the best arguments appear to be that it is a pragmatic "least bad" solution to the fact that (a) people often implement (poorly) the very least they can get away with and (b) it can take a very long time to fix mistakes on the Internet. 

Of course, both (a) and (b) can be improved over time.  The argument that "it's already been X years and only Y% of implementers have supported SPF so we should throw in the towel now" seems specious to me since:

1) the SPF type code has been allocated -- it isn't going away or going to be reused: deprecation gains nothing from a DNS perspective;
2) pretty much every implementation of name servers supports SPF (to one degree or another);
3) there exist implementations of DNS frontend UIs that support SPF and since the semantics are identical to TXT, future implementation would seem to be trivial if a UI supports TXT; and
4) deprecation of SPF imposes additional complexity on every other protocol implementation that uses TXT at the zone apex either now or in the future.

In the past, the IETF/IESG has frowned on 'squatting' on port numbers, addresses, etc., regardless of the potential operational implications of accepting that squattage. I personally feel the use of TXT in this context is only marginally different than squatting. In my view, deprecating SPF only makes sense if the protocol that would use SPF is not going to see further deployment.  Since as far as I know, the point of 4408bis is to clarify implementation requirements for future implementations, deprecation makes no sense to me.

Regards,
-drc

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Aug 2013 18:38:43 -0400

On Monday, August 19, 2013 14:54:44 David Conrad wrote:
> > Operationally, there are far more problems associated with actually trying
> > to use Type 99 than there are with SPF records in Type TXT.
> 
> Given the abysmal state of implementation of middleboxes _today_, this isn't
> surprising.  I'm unsure this sad state applies for all future time to come.
> However, despite the operational issues mentioned above and the fact that
> this has been discussed to death, I also strongly oppose the deprecation of
> the SPF record. AFAICT, no one is arguing that overloading TXT in the way
> recommended by this draft is a good idea, rather the best arguments appear
> to be that it is a pragmatic "least bad" solution to the fact that (a)
> people often implement (poorly) the very least they can get away with and
> (b) it can take a very long time to fix mistakes on the Internet.
> 
> Of course, both (a) and (b) can be improved over time.  The argument that
> "it's already been X years and only Y% of implementers have supported SPF
> so we should throw in the towel now" seems specious to me since:
> 
> 1) the SPF type code has been allocated -- it isn't going away or going to
> be reused: deprecation gains nothing from a DNS perspective; 2) pretty much
> every implementation of name servers supports SPF (to one degree or
> another); 3) there exist implementations of DNS frontend UIs that support
> SPF and since the semantics are identical to TXT, future implementation
> would seem to be trivial if a UI supports TXT; and 4) deprecation of SPF
> imposes additional complexity on every other protocol implementation that
> uses TXT at the zone apex either now or in the future.
> 
> In the past, the IETF/IESG has frowned on 'squatting' on port numbers,
> addresses, etc., regardless of the potential operational implications of
> accepting that squattage. I personally feel the use of TXT in this context
> is only marginally different than squatting. In my view, deprecating SPF
> only makes sense if the protocol that would use SPF is not going to see
> further deployment.  Since as far as I know, the point of 4408bis is to
> clarify implementation requirements for future implementations, deprecation
> makes no sense to me.

Possibly because your 'a' and 'b' strawman don't reflect the working group's 
rationale.  As previously mentioned, it's in the archives.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 19 Aug 2013 22:58:10 -0000

>AFAICT, no one is arguing that overloading TXT in the
>way recommended by this draft is a good idea, rather the best arguments appear to be that it is a pragmatic
>"least bad" solution to the fact that (a) people often implement (poorly) the very least they can get away
>with and (b) it can take a very long time to fix mistakes on the Internet. 

Neither of those are the reason the WG dropped type 99 records.  The
actual reason has been discussed at length, and was most recently
described earlier today in this thread.

Once again, I really don't understand what the point is here.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Mon, 19 Aug 2013 16:42:42 -0700

Hi Hector,
At 14:10 19-08-2013, Hector Santos wrote:
>I'm having a hard time with both sides of the argument, especially 
>the supposed existence of an "interop problem" which seems to only 
>highlight how to "procedurally" stump the SPF type advocates with a 
>"error correction" standpoint.   What is that error by the way?

In a message dated February 27, 2012, the SPFBIS Chairs commented 
that the discussion about Issue #9 (SPF RRTYPE) has revealed an 
interoperability concern in the existing RFC (4408).

 From RFC 6686:

   "RFC 4408 itself included a faulty transition plan, likely because of
    the late addition of a requirement to develop one -- it said:

       An SPF-compliant domain name SHOULD have SPF records of both RR
       types.  A compliant domain name MUST have a record of at least
       one type.

    which means both can claim to be fully compliant while failing
    utterly to interoperate."

The consensus of the SPFBIS WG was that this is an interoperability 
issue and it would have to be corrected.  That is what was considered 
as an error correction.

>addressed. It all seem to be a "Shut up" approach to the problem 
>(always suggest that its been discussed already). This seems to be 
>one of the reasons why the issue will not go away.

I personally do not think that it is appropriate to ask any working 
group participant to "shut up".  I welcome hearing arguments and I 
expect a working group to carefully consider them.

Regards,
S. Moonesamy (as document shepherd)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Aug 2013 00:16:01 +0000

On Aug 19, 2013, at 5:10 PM, Hector Santos <[email-masked]> wrote:
> This will allow coders to add the optimized logic for usage.  It will also allow for new problem solving seeds to be laid down. It will hopefully get the DNS software vendors to finally add direct support for unnamed TYPE support (query and passthru) not only for SPF but for future DNS application protocols.

It would help if you would go review the working group discussion on this point; if you had done so, I do not believe you could make this point with a straight face, because it was soundly refuted by the working group.   I tried to make the same point to the working group, and they successfully argued me around.   Although I'm sure you're aware that I am quite stubborn, it's possible that they would not succeed in arguing you around as they did me.  But you ought at least to do us the service of allowing them to try by reviewing the discussion yourself.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Aug 2013 11:27:25 +1000

> approach that uses a TXT record.

Except you are trying to unring a bell.  The SPF type exists and
is supported in nameservers, resolver libraries and in SPF specific
libraries.  Support is integrated into SMTP servers.  Basically it
is all there.  Deployment is happening.  More and more SMTP servers
are making SPF requests before TXT requests.

There was no rush to migrate to the new type.  Suddenly there is a
"oh we have not moved fast enough" so we need to abandon the migration
for lots of really spurious reasons.

* RFC 4408 allows to publish records that might not be read by a
client.  This isn't actually bad.  At some point you have to drop
support for legacy users.  RFC 4408 *allows* this to happen.  The
worst that happens is a forgery isn't detected but we don't guarentee
to stop all forgeries.

* SPF and TXT records may get out of sync.  If we really need to do
something about this we can request that nameserver vendors keep these
records in sync but in reality the SPF record will be the one that
get used more and more and TXT record will not be looked up at all
if we just let the migration continue.

* SPF lookups fail or are slow.  So do TXT lookups.  Most of these
are due to misconfigured nameservers that return the wrong SOA
record as they are configured to server a parent zone rather than
the delegated zone or load balancers which are not RFC 1034 compliant
as they don't respond to anything other than a limited set of types.

* Nameservers don't support SPF.  Most currently shipping nameservers
do support SPF and have for years.  Some OS vendors are slow to
pickup new nameservers which doesn't help.  Of those that don't
support SPF moving from experimental to standard will/should help
with getting the support added.

* Resolver libraries don't support SPF lookups.  Such libraries are
not RFC 1034 compliant as support for lookups of unknown types is
a explictly listed requirement.  Most resolver libraries are capable
of looking up unknown types though they can only present them as a
blob of data.

* Registrars don't support type SPF records.  Shop around there are
those that do.

TXT was described as legacy in RFC 4408.  The spf specific libraries
look for SPF first then TXT if a SPF RR is not present which is
exactly what you would expect when TXT is described as legacy.

You also have a problem that "SPF record" means two things if we
stop the migration.  The TXT record with "v=spf1" at the start and
the type SPF record that is deprecated.

There are other problems like undoing all the changes to support
type SPF.  You need to modify all the servers that now support SPF
to warn / fail to load if they see a SPF record in a zone.

Note it doesn't help that companies charge extra to support SPF
over TXT as you well know.

RFC 4408 treated the SPF type as a foot note.  All the examples
were done using TXT not SPF with the exception of the single example
showing identical TXT and SPF records.  When all the examples are
done with TXT how do you expect people to know that they should be
using type SPF?

Lots of people were not aware of the SPF type.  Named now warns
when both TXT and SPF versions of SPF records are not present and
it could be made into a failure unless the test is explicitly
downgraded to a warning or disabled.

The code could also be extended to enforce consistancy between the
two types of records when present.  I'm willing to write the code
for named.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Aug 2013 22:22:09 -0400

Again, I'm not the shepherd on this, but I was involved in the
consensus call in the WG when we determined that the WG wanted to
deprecate use of RRTYPE 99.  (Note that this "deprecation" means just
that users of SPF stop publishing that record.  There's nothing in the
draft to remove the RRTYPE, as that would be absurd.)

On Tue, Aug 20, 2013 at 11:27:25AM +1000, Mark Andrews wrote:
> Deployment is happening.  More and more SMTP servers

I think those are the two central premises that are up for dispute.
RFC 6686 made the determination about the former claim, and therefore
that premise is not up for debate: deployment appears not to be
happening.  If people wish to argue with the conclusions of RFC 6686,
that's fine, but it seems that one at least needs to write an
anti-6686 document in that case.  The draft currently up for last call
is relying on the conclusions of RFC 6686 as a premise, and is not
itself arguing whether RRTYPE 99 deployment is or is not happening.

The fact that SPF processors are making SPF queries before TXT queries
is in fact part of the reasoning for why RRTYPE 99 ought to be
deprecated.  If many clients make a query and only a tiny number of
zones have that type published (or are likely ever to publish the
type), it's simply wasteful to continue using that type.  If this
seems a familiar line of argument, it's because it's one you see in
the spfbis list archives when this issue was decided by the WG.
 
> over TXT as you well know.

I'm not sure whether that's supposed to be a swipe at my employer, but
just so we're clear: Dyn (my employer) supports the SPF RRTYPE in its
enterprise-focussed offerings.  There's no extra charge.

The front end for the basic DNS service (many people know this as
DynDNS or Dyn's Standard DNS or other such trade names) is intended to
be simple and self-service.  It's cheap, and the margins don't allow
us to provide a lot of personalized support.  Dyn found that people
who were good candidate customers for that self-service system knew
how to do things with TXT, did not know about or care about the SPF
type, and were confused by having two types for one purpose.  For
practical purposes, it was necessary to support SPF over TXT (since
some clients didn't check the SPF type).  So, one type it was, and TXT
at that.  This all happened long before I worked at Dyn, but I assure
you that the commercial pressure for adding TYPE 99 support to the
basic platform (actually, it's just the front end) is just as
non-existent today as it was when that decision was made.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 20 Aug 2013 04:49:15 +0200

Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Mon, Aug 19, 2013 at 03:59:50PM -0400 Quoting John R Levine ([email-masked]
> As you saw when you read the WG archives, there is a significant
> interop bug in rfc 4408 in the handling of SPF and TXT records,
> which (again after painful and extension discussion) we decided the
> least bad fix was to get rid of SPF records.  I don't see anything
> in your note about how else you think we should address the interop
> bug.

It is in the archives, but for your convenience, and in haste: 

SPF MUST be published. TXT MAY be published to help in migration. If both,
they MUST align. [0]

The lookup order should be : Ask for SPF, if not found, ask for TXT,
if not found, return ANY. Long-term, one may disregard the TXT fallback.
If TXT and SPF differ (and TXT happens to look like SPF syntax), assume
that migration is in place, discard TXT and use SPF.

And before the whining on query rate starts: The amount of queries is
presently uninteresting from a DNS operations perspective. Does matter
much less than the squatting on TXT. Besides, we've got caching in DNS,
which scales very well.

Caching in itself does introduce some pits to fall in, especially
regarding TTL in migration states. If deemed suitable, some
recommendations on TTL can be discussed. These should however be limited
to the unique situation that is trying to publish the same record
twice. My naïve hunch is to either recommend publishing both with the
same TTL or possibly TXT with a significantly shorter. The latter is
probably only interesting in short-term migration states.

This discussion is however best had on the spfbis mailing list, after
the -19 draft is sent back.
 
> In your case it doesn't matter, since your TXT and SPF records make
> no usable assertions, but a lot of people use SPF right now as part
> of their mail stream management.

Off-topic: They do make usable assertions. It is just that my email policy
seems to differ from what you think prudent. I believe I'm free to have
a differing policy.[1]

Praeterea censeo, Carthaginem esse delendam.
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Don't hit me!!  I'm in the Twilight Zone!!!

[0] Please note that my besserwisser.org records are SPF only. 
    The fact that there is argumentation with a funny prefix in
    some TXT records is simply "some use" of TXT records.

[1] Mail from me should be authenticated by my PGP signature, not by
    which IP address that happened to deliver it to your MX node.

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 20 Aug 2013 05:01:52 +0200

> expect a working group to carefully consider them.

The repeated assertions of "This has been discussed already" are in effect
"shut up", but slightly more polite. I complied until last call. As was
recommended by wg chairs.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Yes, but will I see the EASTER BUNNY in skintight leather at an IRON
MAIDEN concert?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Aug 2013 13:18:56 +1000

> draft to remove the RRTYPE, as that would be absurd.)

Recommending that people not publish RRTYPE 99 does not address the
problem.  You need to forceable stop people using RRTYPE 99 or you
need to continue the migration by deploying more software that looks
up type SPF then type TXT if SPF is not available.

Those are the only solutions to the so called problem of publishers
and checkers not interoperating with each other.  
 
> itself arguing whether RRTYPE 99 deployment is or is not happening.

When you only do a point measurement and don't have any long term
trends the data is meaning less.  Lots of zones were setup pre RFC
4408 with no campain to transition them to RFC 4408 status.  Similarly
it takes several years for new support to make its way into production.
You have to write the libraries.  You have to integrate the new
libraries into the servers.  You have to get those servers deployed
which is often only done on hardware replacement.

> the spfbis list archives when this issue was decided by the WG.

So the solution is to educate.  The long term goal is to get to
type 99 only.  The complaints about delays could be removed with
draft-wkumari-dnsop-hammer and addressing the bigger problem of
broken nameservers draft-andrews-dns-no-response-issue or have TLD
operators actually do what was requested of them in RFC 1034 and
periodically CHECK delegations which would address some of
misconfiguration issues.

> enterprise-focussed offerings.  There's no extra charge.

There is a extra charge over basic support which support A, AAAA,
CNAME, MX, TXT, SRV, NS, LOC, PTR compared to the premium product
which supports A, AAAA, CERT, CNAME, DHCID, DNAME, DNSKEY, DS,
IPSECKEY, KEY, KX, LOC, MX, NAPTR, NS, NSAP, PTR, PX, RP, SOA, SPF,
SRV, SSHFP, TXT.

http://dyn.com/dns/dns-comparison/

> non-existent today as it was when that decision was made.

So rather than do what RFC 4408 said to do and support the SHOULD Dyn
made it impossible for the non enterprise customer to do RFC 4408
properly.

Mark

---

From: David Conrad <[email-masked]>
Date: Mon, 19 Aug 2013 21:57:26 -0700

John,

On Aug 19, 2013, at 3:58 PM, John Levine <[email-masked]> wrote:
> Neither of those are the reason the WG dropped type 99 records.  

My apologies for trying to provide a high-level summary of what I believe the arguments to be.  My understanding of the reasons the WG decided to deprecate the SPF RR:

1) the low level of deployment of the SPF RR "both on the publishing side and the validation side" relative to TXT RRs

This corresponds to (a): people implement/deploy TXT because it is currently sufficient, both from what people put into their zone data as well as what middlebox and DNS UI implementors bother supporting.  I believe it is sufficient because the migration strategy proposed in RFC 4408 was in error.

2) a "race condition" or "interoperability problem" resulting from what is documented in RFC 6686, Appendix A, #4.

This corresponds to (b): there was a mistake in 4408 and fixing that mistake takes a long time.

> Once again, I really don't understand what the point is here.

To quote from "http://www.openspf.org/FAQ/TXT_abuse" (a page on one of the websites referenced in RFC 6686):

"The Right Thing To Do is to get our own RRtype, and although it took a long time to get it, we have it assigned."

Regards,
-drc

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Aug 2013 01:07:41 -0400

On Monday, August 19, 2013 21:57:26 David Conrad wrote:
> >> way recommended by this draft is a good idea, rather the best arguments
> >> appear to be that it is a pragmatic "least bad" solution to the fact
> >> that (a) people often implement (poorly) the very least they can get
> >> away with and (b) it can take a very long time to fix mistakes on the
> >> Internet.> 
> My apologies for trying to provide a high-level summary of what I believe
> the arguments to be.  My understanding of the reasons the WG decided to
> deprecate the SPF RR:
> 
> 1) the low level of deployment of the SPF RR "both on the publishing side
> and the validation side" relative to TXT RRs
> 
> This corresponds to (a): people implement/deploy TXT because it is currently
> sufficient, both from what people put into their zone data as well as what
> middlebox and DNS UI implementors bother supporting.  I believe it is
> sufficient because the migration strategy proposed in RFC 4408 was in
> error.
> 

According to the history of the page, I wrote that in 2006.  Don't confuse 
engineering and marketing.  Despite the revisionist claims to the contrary, 
the SPF community pushed pretty hard on type SPF deployment, but it didn't 
work out very well.  Most open source libraries have given up on type SPF 
query be default, despite having supported it initially.

Support for type SPF in SPF verifiers is more likely declining than increasing.  
At least for the open source implementations capable of supporting it, the 
code has been there for half a decade.  It's mostly been turned off by default 
for operational reasons.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Mon, 19 Aug 2013 22:12:18 -0700

>preferred while maintaining support for TXT.

I read the SPFBIS charter ( 
https://datatracker.ietf.org/wg/spfbis/charter/ ) 
again.  The charter violation the above may be referring might be about:

  "Specifically out-of-scope for this working group:

   * Removal of existing features that are in current use."

There is a message from the Responsible Area 
Director at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html 
which might shine some light about that part of the charter.

Both RR Type 16 and RR Type 99 are in use on the 
Internet.  Tony Hansen mentioned during the IETF 83 session that:

   "when you write a protocol, there is definite harm if there is a
    choice in what you publish and what you look for.  He is of
    the view that there is a definite bug in RFC 4408."

Fixing that bug falls within the scope of the SPFBIS charter, specifically:

   "Changes to the SPF specification will be limited to the correction
    of errors, removal of unused features, addition of any enhancements
    that have already gained widespread support, and addition of
    clarifying language. "

The fourth paragraph (see quoted text) states 
that the conclusions from that where RFC 6866 
were flawed and rushed.  The explanation given is 
because the working group declared failure too 
soon.  The SPFBIS WG discovered a bug during the 
review of the SPF specification.  One of the main 
considerations for the decision was to fix the 
bug.  The working group had to choose one RRTYPE 
as the conclusion was that it was the appropriate 
way to fix the bug and ensure interoperability.

The comments posted up to now for the Last Call 
points to a disagreement about the choice of RRTYPE.

Regards,

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 Aug 2013 14:14:27 +0900

so, according to your message, one lesson i might take from this is, if
i want to deploy a new hack which needs an rrtype, not to use txt in the
interim.  i will be caught in a mess which will appear to be of my own
making.  is that somewhat correct?

randy

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Aug 2013 22:16:40 -0700

> recommended by wg chairs.

There is a fundamental difference between telling someone to shut up and 
asking the person to familiarize themselves with the group's history 
before speaking up.

It's a question of who is being required to carry the primary burden for 
making their case.  In the current circumstance, the burden is on the 
person lodging the concern, namely you, rather than on the group.

The alternative is, effectively, a denial of service attack on the 
group's progress, by requiring that it be (potentially constantly) 
required to re-visit old and resolved topics.

Since there is, in fact, an extensive -- possibly even complete -- 
public archive of discussions, placing the burden on the person lodging 
the concern is singularly reasonable.

As others have attempted to point out, this reduces to requiring that 
someone raising a concern during the last call start with the group's 
context and, therefore, either point out what the group missed or 
explain how it assessed reality incorrectly or otherwise made a 
problematic engineering choice.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Aug 2013 22:21:51 -0700

> making.  is that somewhat correct?

Whether it's what he meant, it's not the correct lesson.  There are 
probably two realistic lessons:

      The first is that there now a number of other apps using TXT 
records, with no problems, because they are stored under scoping nodes 
(underscore-prefaced names).  This approach might be aesthetically 
displeasing, but it works just fine.

      The second is that, unfortunately, deploying a new RR that gains 
widespread, end-to-end support remains problematic, assurances to the 
contrary notwithstanding.

d/

---

From: David Conrad <[email-masked]>
Date: Mon, 19 Aug 2013 22:27:12 -0700

> making.  is that somewhat correct?

Not exactly. 

Given the situation at the time (specifically, the difficulty getting new RR types -- a problem since fixed), I believe the use of TXT was appropriate. Unfortunately, the migration strategy away from TXT was flawed. My personal belief is that the rationale to migrate away from TXT remains valid and the appropriate course of action is to fix the migration strategy, not permanently encode what everyone agrees is a hack into a proposed standard.

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 08:33:58 +0200

On 20 aug 2013, at 07:21, Dave Crocker <[email-masked]> wrote:

>     The first is that there now a number of other apps using TXT records, with no problems, because they are stored under scoping nodes (underscore-prefaced names).  This approach might be aesthetically displeasing, but it works just fine.

That can not be said generally. Reason for this is that the RR with an underscored prefix MIGHT end up in a different zone than the record without. This implies that two records with the same owner and different RRType MUST be in the same zone, while a name without and one with prefix MIGHT NOT, where also one of the zones is signed and the other is not.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Aug 2013 00:14:21 -0700

On 8/19/2013 11:33 PM, Patrik Fältström wrote:
> Reason for this is that the RR with an underscored prefix MIGHT end up in a different zone than the record without.

Patrik,

Please clarify.  I don't know what you mean by the 'with' and 'without' 
references.

And as long as I'm asking for more explanation, given the number of 
years of use the construct has had and for the number of different 
applications, where has the problem (whatever you mean specifically) 
been seen?

d/

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 09:43:18 +0200

On 20 aug 2013, at 09:14, Dave Crocker <[email-masked]> wrote:

> Please clarify.  I don't know what you mean by the 'with' and 'without' references.

The two following records MUST be in the same zone:

foo.example. IN X RDATAX
foo.example. IN Y RDATAY

The two following MIGHT NOT be in the same zone:

foo.example. IN X RDATAX
_bar.foo.example. IN TXT RDATAY

> And as long as I'm asking for more explanation, given the number of years of use the construct has had and for the number of different applications, where has the problem (whatever you mean specifically) been seen?

When using DNSSEC if the _bar.foo.example record in the 2nd example above is unsigned, while the foo.example in the first example is.

   Patrik

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Aug 2013 09:30:13 -0400

On 8/19/2013 7:42 PM, S Moonesamy wrote:>
> issue and it would have to be corrected.  That is what was considered as
> an error correction.

I have a few questions and points:

May I ask why was the above was not an area for clarification as oppose 
as the presumed stated technical reason for removal?

There was adequate information for the expected and original optimal 
migration plan but it could of been further codified and clarified. It 
would of been on par with BIS level of work.  Issue #9 should not have 
been a reason for removal.  I reported issue #25 [1] regarding the 
complexity of the recommended parallel processing approach.  I believe 
most folks agreed the ideal and optimal migration approach was:

     Query SPF type first,
     Fallback to TXT secord.

It was common sense, at least to me.

Second, I was under the impression interop reports (RFC 6686) were not 
making any conclusions or recommendations?  Is that a correct basic 
understanding of interop reports?  They were observations, collection of 
available data and while it might be eventually used to rethink a 
protocol design, I don't think the above RFC 4408 statement is a serious 
"error" in the functional description to justify removal. There are 
other parts of 4408 which helped clarify the migration path.

But overall, a correction (not removal) would of suffice. It would of 
been on par for BIS-like corrections and protocol updates.

Third, I believe removal required a more deeper IETF discussion about 
the initial presumed engineering expectation that DNS servers (all top 
DNS servers, including and especially Microsoft DNS servers) would 
eventually directly support a new registered SPF type or at the very 
least support RFC 3597 (Handling of Unknown DNS Resource Record (RR) 
Type) [2].

If this is no longer the expectation, then it would make sense to remove 
the SPF type but also be aware that in general, this will also  nix (not 
help) any future idea for successfully adopting new RR types.
It would be added statement that TXT based applications are acceptable. 
  I think the DNS community continues to have a problem with this.

>> (always suggest that its been discussed already). This seems to be one
>> of the reasons why the issue will not go away.
>

SM, Pete, thank you for the opportunity to clarify my point. For the 
record, there was no intent to imply it occurred but quite frankly when 
it is repeatedly stated, this deeply divided issue has not be resolved 
at any point,  it does have an intimidation factor.  As Mr. Crocker 
stated, the burden is on the those who oppose the removal. But my 
question was always why was the decision made to remove in the first 
place done when in fact it was quite obvious it would not have industry 
wide endorsement. The burden should of been to justify removal. Now it 
has become difficult to effectively add it back. This is why I posed the 
question in two forums to get community input over the last few years. 
It was quite obvious to me that the DNS community would be against this 
removal.  So in this vain, it was prematurely removed in the WG without 
early IETF/IESG/DNS concerns adequately dealt with.  Unfortunately, we 
were advise to raise the issue again in LC, but by that point, all the 
IETF procedural moves were made making it it a very high burden to add 
something that should not been removed in the first place.

The only reason our own early adoption package did not support the SPF 
type was because we could not; the Microsoft DNS server (NT 4.0 at the 
time) had not directly support the SPF type but more importantly it did 
not support RFC 3597.  Unfortunately, not even MS DNS 5.0 which did add 
direct support for other new RR types (SRV, DNSSEC, AAAA, etc).

In my engineering opinion, the implications of the SPF type removal are 
wide spread as it implies a no confidence in the future of DNS servers 
to support safe, transparent passthru, recursive queries of unnamed types.

If such is the case with the IETF DNS community,  then it makes 
engineering sense to remove the SPF type but also keep in mind new RR 
types are also unrealistic as well. All future DNS DOMAIN policy based 
applications will be TXT only based which may be the acceptable reality 
today.  It wasn't yester-years (during MARID).  The endorsement of DKIM 
as an IS specification is testament of this TXT based solution 
acceptability in the market place.

To me, that would be the reason for removal. Otherwise, if we still have 
confidence in the future of RFC 3597 support in DNS servers across the 
board out of the box, then we should correct and clarify the SPF/TXT 
query method migration path in RFC 4408-bis.

As stated a number of times in the SPF WG, I would support SPF type in 
our implementation once Microsoft DNS server supported at the very least 
unnamed RR type processing.  It can't be provisional software, i.e. 
custom, that would not cut it. It needs to be out of the box for wide 
network query support.

Thanks

--
HLS

[1] http://www.ietf.org/mail-archive/web/spfbis/current/msg00586.html
[2] http://tools.ietf.org/html/rfc3597

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Aug 2013 10:16:27 -0400

On 8/20/2013 1:12 AM, S Moonesamy wrote:

> There is a message from the Responsible Area Director at
> http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html which
> might shine some light about that part of the charter.
>
> Both RR Type 16 and RR Type 99 are in use on the Internet.  Tony Hansen
> mentioned during the IETF 83 session that:
>

This doesn't seem to be correct. My apology if I don't follow or see the 
logic.   The only real issue as it was since day zero in MARID was the 
infrastructure support for recursive passthru queries which is what RFC 
3597 (Handling of Unknown DNS Resource Record (RR) Type).  Without this, 
which allows for servers to delay/plan direct new RR type support yet 
still not error out on an unnamed type, there COULD NOT be any 
reasonable expectation to even only suggest a dual query migration 
approach, either in serial or parallel. It is very important to consider 
the mindset when it was first considered and written for RFC 4408 
because to me, that is the mindset that has changed.

If we don't think the infrastructure, the DNS vendors primarily, will 
support RFC 3497, then it seems proper to me to finally forget the idea.

But if we still think its desirable and possible, then I would prefer to 
keep the protocol feature/option, corrected of course, and allow 
implementers the design choice to support it.

The way I see it, if more implementations did begin to add support of a 
clarified BIS specification, that doesn't mean they may enabled it 
(default ON) out of the box.  I would want to initially offer the lowest 
overheard operational setup out of the box.  It will still be a long 
term migration path, shorter if we can encourage the major DNS vendors 
to add at least RFC 3597 support.  Without, no new RR type will work 
across the board.

> The fourth paragraph (see quoted text) states that the conclusions from
> that where RFC 6866 were flawed and rushed.  The explanation given is
> because the working group declared failure too soon.  The SPFBIS WG
> discovered a bug during the review of the SPF specification.  One of the
> main considerations for the decision was to fix the bug.  The working
> group had to choose one RRTYPE as the conclusion was that it was the
> appropriate way to fix the bug and ensure interoperability.
>
> The comments posted up to now for the Last Call points to a disagreement
> about the choice of RRTYPE.

I hope I am reading this incorrectly.  It may be too procedural oriented 
to me at this point.

I would like to see a simple just distinctive consensus on what the 
entire IETF/DNS community believes is the future of DNS servers offering 
unnamed RR type processing because that is the main barrier for any kind 
success. We knew this as far back as MARID.  I don't quite understand 
why this key point seems to be left out, instead MARID was deemed off 
topic. That was an error because if there is no future in unnamed RR 
type support, then it really doesn't matter and the problem is solved. 
TXT only will be the only fast entry point for new DNS DOMAIN policy 
applications.

If the community still believes it possible, then clarifying and 
codifying the SPF/TYPE lookup procedure seems to me to be the only real 
correction to make here.

Thanks

--
HLS

[1] http://tools.ietf.org/html/rfc3597

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2013 14:45:48 -0000

Newsgroups: iecc.lists.ietf.ietf
From: John Levine <[email-masked]>
Subject: Re: [spfbis] prefixed names, was Last Call: <draft-ietf-spfbis-4408bis-19.txt>
Summary:
Expires:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Sender:
Followup-To:
Distribution: 
Organization: 
Keywords: 
Cc: 
Cleverness: some

>_bar.foo.example. IN TXT RDATAY

Since prefixed names have never been used for anything other than
providing information about the unprefixed name, what conceivable
operational reason could there be to put a zone cut at the prefix?

This impresses me as one of those problems where the solution is
"don't do that."

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Aug 2013 10:46:46 -0400

> applications, where has the problem (whatever you mean specifically)

Quite apart from the DNSSEC example that Patrik sent, underscore
labels also cause problems and confusion when aliases are involved.
The alias stuff is a corner case, of course, but it's still a basic
problem with the approach of specifying policy for a target name at a
different name than the target itself.  This trade-off might be a
legitimate one (I certainly think it's preferable to the strategy SPF
adopted, of stepping all over the TXT RRTYPE at a given name), but it
won't do to dismiss the problem with a point-and-laugh argument.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dotzero <[email-masked]>
Date: Mon, 19 Aug 2013 15:03:06 -0400

The issue Måns Nilsson raises was discussed extensively on the SPFbis
list prior to as well as during last call on the list and I believe
the appropriate decision was reached by the working group. If there is
any doubt in the minds of the IESG regarding whether the working group
reached the correct decision, I would urge those IESG members to
review the threads in the archives related to this issue.

Several related issues, including a race condition, were identified
and the solution to go with TXT only records is IMHO the correct one
under the circumstances. The relatively small uptake of Type 99
records in the wild (both on the publishing side AND on the validation
side) in comparison to the implementation for TXT records made a
compelling case for the decision of the working group.

With regard to the limitations of the working group charter, some
significant change was required to eliminate the race condition
regardless of what that change would be. The decision of the working
group (IMHO - I do not want to put words into anyones mouth) was to go
with the approach which had the least impact on what is arguably a
very large installed existing base on both the sender AND the
validator sides of implementation.

Based on this I would ask that tehe IESG move
draft-ietf-spfbis-4408bis-19.txt to Proposed Standard.

Michael Hammer

On Mon, Aug 19, 2013 at 11:05 AM, Måns Nilsson
<[email-masked]> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlISNDEACgkQ02/pMZDM1cXK+gCfYQ1Mv1CHjy9DDn7sA7DC7dF3
> b48An1b49Zqf/du3dvN6pmj6in+CEujB
> =soFG
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Aug 2013 01:12:55 +1000

In message <[email-masked]>, "John Levine" writes:
> References: <[email-masked]> <55459829-933F-4157-893A-F90552D444
> [email-masked]> <[email-masked]> <D2148A40-2673-40C7-8349-0A65D
> [email-masked]>
> Sender:
> Followup-To:
> Distribution: 
> Organization: 
> Keywords: 
> Cc: 
> Cleverness: some
> 

When you have "_users" and you want to move the users out of the
hosts namespace and have whom ever deals with people manage that
part of the namespace.

> This impresses me as one of those problems where the solution is

There are good reasons to split off administrative control.  "don't
do that" isn't a answer.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Aug 2013 08:46:57 -0700

...
> There are good reasons to split off administrative control.  "don't

Exactly right.  For some of the 'underscore' uses, maintenance of the 
information in that subordinate node is best performed by a team that is 
separate from the regular DNS operations people.

DKIM is an easy example, since the records often are better handled by 
the email operations folk.

So I'm continuing to miss the 'problem' here.  Being able to separate 
administration of the underscore-based attribute information is a 
feature, not a bug.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Aug 2013 08:54:02 -0700

> won't do to dismiss the problem with a point-and-laugh argument.

Use of underscore names does impose some limitations.  Occasionally 
those limitations are noteworthy for real-world operations, but 
experience across a range of applications so far has not created any 
show-stoppers.

One of the more serious problems about using the underscore construct is 
that arguments against it sometimes are based on an insistence for 
pure-and-complete original DNS capabilities, rather than attending to 
the real-world utility.  It would be nice to have the construct impose 
no additional constraints, but 'nice' isn't the same as 'necessary', 
when evaluating pragmatic trade-offs.

In other words, the specific technical limitations being noted are 
unfortunate but (so far) not serious.

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Aug 2013 12:08:44 -0400

> unfortunate but (so far) not serious.

You should explain that to my employer's support department.

In any case, I don't think this topic is directly relevant to the
SPFBIS discussion, so I'll not comment on it further.

A

-- 
Andrew Sullivan
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Aug 2013 10:02:57 -0700

Hi Hector,
At 06:30 20-08-2013, Hector Santos wrote:
>May I ask why was the above was not an area for clarification as 
>oppose as the presumed stated technical reason for removal?

The SPFBIS WG had a session at IETF 83.  The minutes for that session 
is at 
http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt 
Item C on the agenda is about "SPF RR Type and TXT RR (issue 
#9)".  Andrew Sullivan, as SPFBIS Chair, explained that:

   'The were people on the mailing list in favor of using the TXT RR
    appeared to be a modest majority and there were people who argued
    for SPF RR Type on the grounds of DNS hygiene.  The Chair explained
    that it appears as an empirical matter, overwhelmingly, the TXT RR
    is used but RRTYPE 99 does not qualify under the unused provision
    of the SPFBIS charter.'

Pete Resnick, as Area Director, commented that:

   'the deal with the IESG, as a general statement, the working can removed
    what is unused and put in what is widely deployed. He pointed out that
    saying that TXT RR is part of an experiment is contrary to the agreement
    made with the IESG.  His opinion is that either way, the proposal is stuck
    with TXT RR and that it is not an issue.  The only issue is whether the
    proposal can remove the SPF RRTYPE as unused.'

On February 26, 2012, Barry Leiba, as a participant, posted a message 
( http://www.ietf.org/mail-archive/web/spfbis/current/msg00654.html ) 
which I will quote:

   "These two statements make a pretty compelling case that there is, indeed,
    an error in RFC4408.  There are, of course, multiple ways to resolve it,
    and I have no immediate opinion on which is best."

My opinion, as one of the SPFBIS WG Chairs, was that there was an 
error.  As Barry Leiba mentioned, there were several possible ways to 
fix that.  The SPFBIS Chair stated at the meeting that:

   "The conclusion reached by the Chair was that the document will say
    SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99."

That statement was posted to the SPFBIS mailing list ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html 
).  Nobody disagreed.

>migration plan but it could of been further codified and clarified. 
>It would of been on par with BIS level of work.  Issue #9 should not 
>have been a reason for removal.  I reported issue #25 [1] regarding 
>the complexity of the recommended parallel processing approach.  I 
>believe most folks agreed the ideal and optimal migration approach was:
>
>     Query SPF type first,
>     Fallback to TXT secord.
>

Both Issue #9 and Issue #25 (see SPFBIS tracker)  were 
well-discussed.  Was every technical point carefully considered?  I 
don't think so as it is possible that a technical point may have been 
missed.  There is an opportunity for anyone to comment during the 
Last Call if the person believes that a technical point has been 
missed or was not addressed appropriately by the working group.  In 
my opinion the SPFBIS WG carefully considered all the comments which 
were made in reaching its decision.

>Second, I was under the impression interop reports (RFC 6686) were 
>not making any conclusions or recommendations?  Is that a correct 
>basic understanding of interop reports?  They were observations, 
>collection of available data and while it might be eventually used 
>to rethink a protocol design, I don't think the above RFC 4408 
>statement is a serious "error" in the functional description to 
>justify removal. There are other parts of 4408 which helped clarify 
>the migration path.

 From the Introduction Section of RFC 6686:

   "In line with the IESG's request to evaluate after a period of time,
    this document concludes the experiments by presenting evidence
    regarding both deployment and comparative effect of the two
    protocols.  At the end, it presents conclusions based on the data
    collected."

In my opinion RFC 6686 does make conclusions (see Section 6 of RFC 
6686).  There is some background information about the RRTYPE issue 
in Appendix A.

>But overall, a correction (not removal) would of suffice. It would 
>of been on par for BIS-like corrections and protocol updates.

Andrew Sullivan, as SPFBIS WG Chair, mentioned that "We have to do 
_something_, though any action would introduce a backward 
incompatibility ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03595.html ).

>Third, I believe removal required a more deeper IETF discussion 
>about the initial presumed engineering expectation that DNS servers 
>(all top DNS servers, including and especially Microsoft DNS 
>servers) would eventually directly support a new registered SPF type 
>or at the very least support RFC 3597 (Handling of Unknown DNS 
>Resource Record (RR) Type) [2].

There were comments about RFC 3567 during the working group 
discussions (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00545.html 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00820.html ).

>If this is no longer the expectation, then it would make sense to 
>remove the SPF type but also be aware that in general, this will 
>also  nix (not help) any future idea for successfully adopting new RR types.
>It would be added statement that TXT based applications are 
>acceptable.  I think the DNS community continues to have a problem with this.

Noted.

>record, there was no intent to imply it occurred but quite frankly 
>when it is repeatedly stated, this deeply divided issue has not be 
>resolved at any point,  it does have an intimidation factor.  As Mr. 
>Crocker stated, the burden is on the those who oppose the removal. 
>But my question was always why was the decision made to remove in 
>the first place done when in fact it was quite obvious it would not 
>have industry wide endorsement. The burden should of been to justify 
>removal. Now it has become difficult to effectively add it back. 
>This is why I posed the question in two forums to get community 
>input over the last few years. It was quite obvious to me that the 
>DNS community would be against this removal.  So in this vain, it 
>was prematurely removed in the WG without early IETF/IESG/DNS 
>concerns adequately dealt with.  Unfortunately, we were advise to 
>raise the issue again in LC, but by that point, all the IETF 
>procedural moves were made making it it a very high burden to add 

There are two SPFBIS WG Chairs.  The way we work is: I read the 
mailing list messages, the other Chair reads the mailing list 
messages, each chair reaches his own conclusion and we discuss about 
it.  Once the Chairs agree a message is posted to the WG mailing 
list.  Let's assume that the Chairs did not carefully consider the 
comments or their determination was incorrect.  There is a Last Call 
where the matter can be raised again.  That is the advice that was 
given.  There is indeed a high burden as the person raising the issue 
again will have to read the mailing list messages to determine 
whether they have been carefully considered.

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Aug 2013 10:30:41 -0700

Hi Hector,
At 07:16 20-08-2013, Hector Santos wrote:
>This doesn't seem to be correct. My apology if I don't follow or see 
>the logic.   The only real issue as it was since day zero in MARID 
>was the infrastructure support for recursive passthru queries which 
>is what RFC 3597 (Handling of Unknown DNS Resource Record (RR) 
>Type).  Without this, which allows for servers to delay/plan direct 
>new RR type support yet still not error out on an unnamed type, 
>there COULD NOT be any reasonable expectation to even only suggest a 
>dual query migration approach, either in serial or parallel. It is 
>very important to consider the mindset when it was first considered 
>and written for RFC 4408 because to me, that is the mindset that has changed.

This would be a process issue then as the SPFBIS Chairs determination 
was made on the basic of the text from the SPFBIS Charter which was 
cited.  A person can raise an objection (I am okay with that as 
that's part of the work) with substantive comments to support the objection.

>I hope I am reading this incorrectly.  It may be too procedural 
>oriented to me at this point.
>
>entire IETF/DNS community believes is the future of DNS servers 
>offering unnamed RR type processing because that is the main barrier 
>for any kind success. We knew this as far back as MARID.  I don't 
>quite understand why this key point seems to be left out, instead 
>MARID was deemed off topic. That was an error because if there is no 
>future in unnamed RR type support, then it really doesn't matter and 
>the problem is solved. TXT only will be the only fast entry point 
>for new DNS DOMAIN policy applications.
>
>codifying the SPF/TYPE lookup procedure seems to me to be the only 
>real correction to make here.

My reading of  the SPFBIS Charter is that the working group was not 
tasked to work on the future of DNS servers.  That does not mean that 
arguments about the future of DNS servers are not relevant.

There are several questions:

  (a) Was there an error in RFC 4408?

  (b) What was the error in RFC 4408?

  (c) Why was there an error in RFC 4408?

  (d) What should be done about the error?

There isn't anything that can be done about question (c) except not 
to repeat the same mistake.

Is there disagreement on the answers to questions (a) and (b)?

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Aug 2013 17:16:56 -0400

>From a pure protocol point of view the SPF record does have one major
advantage over TXT and that is in the use of wildcard records.

In short a wildcard on a TXT record for SPF is going to have impact on
every other scheme that overloads TXT, of which there are many. SPF does
have a mechanism to resolve the ambiguity but that does not stop the record
sets from getting to be larger than will fit in DNS UDP responses.

This has not been much of a problem because most of the other TXT overloads
don't have a use for a wildcard. There is not much point in a wildcard DANE
record. But it could be an issue.

So keeping SPF records does actually have a utility since it allows
wildcarded records to be isolated from other protocols and avoiding the
wildcard record set bloat issue.

The criteria to use to decide is not the proportion of SPF records
published as TXT vs SPF but what the validators look for. If at this point
there is little to no takeup by the validators for the SPF RR then it is
time to call time on a failed experiment. If there was a significant
support base for SPF RR validation then it is a harder call.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Aug 2013 18:48:36 -0700

> SPFBIS discussion, so I'll not comment on it further.

The construct has been standardized multiple times, going back at least 
13 years, is very widely deployed and very heavily used.  In other 
words, it is very fully incorporated into Internet infrastructure services.

In the face of that, any support group that spends its time complaining 
about the construct is ignoring pragmatics and is, instead, paying 
attention to other issues.

For a support group, that means the issue is not technology or 
operations, but rather organizational management.

I'd be glad to assist your employer in helping its support team to 
reassess its priorities.

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Aug 2013 00:00:04 -0400

No hat.

> advantage over TXT and that is in the use of wildcard records.

This is an extremely interesting point, and I'm ashamed to admit I
hadn't really thought about it from quite this perspective.  I say
that even though the draft contains some text that attempts to deal
with wildcards and the WG discussed the issue from a slightly
different perspective.  I think it is worth considering.  Note,
however, that …

> record. But it could be an issue.

…it wouldn't be an issue for most of the cases where TXT is
overloaded, because (partly due to the mess that SPF caused) most of
the TXT overloads we see are now scoped using underscore labels, where
the wildcard at a superordinate place in the FQDN isn't going to
matter.  Phill's is still a valuable observation, and one I think the
WG actually didn't consider in every dimension.
 
> published as TXT vs SPF but what the validators look for. 

The WG had a hard time coming up with really good data about what
validators look for, but to the extent we were able to draw
conclusions about that the evidence was that virtually nobody is
looking for SPF records.  This is mentioned at the end of section 3.1
of RFC 6686.  If someone else with some busy nameservers wants to
provide different evidence now, it wouldn't hurt.  We were unable to
find anyone among the participating validators in the SPFBIS WG who
was willing to argue in public that they felt the SPF lookup was more
valuable to them, but we did have some large participants who said
they did _not_ do the TYPE99 lookup except under unusual circumstances
(the draft author, who is also the maintainer of an important SPF
library, has already made this point elsewhere in this thread).

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2013 00:17:57 -0700

On Aug 20, 2013, at 9:00 PM, Andrew Sullivan <[email-masked]> wrote:
> The WG had a hard time coming up with really good data about what validators look for, ... If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt.

Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack:

2011/07/30 08:07:51 spf: 2, txt: 1, 200.000000%
2011/08/10 21:28:41 spf: 4, txt: 121, 3.305785%
2011/08/14 21:30:11 spf: 1, txt: 45, 2.222222%
2011/08/16 17:20:40 spf: 0, txt: 5, 0.000000%
2011/08/17 00:53:42 spf: 1, txt: 1, 100.000000%
2011/08/19 01:10:53 spf: 0, txt: 6, 0.000000%
2011/08/21 03:09:09 spf: 27, txt: 45, 60.000000%
2011/09/13 04:25:21 spf: 30, txt: 113, 26.548673%
2011/09/15 16:19:41 spf: 3, txt: 16, 18.750000%
2011/09/15 17:16:35 spf: 0, txt: 3, 0.000000%
2011/09/22 18:35:07 spf: 6, txt: 22, 27.272727%
2011/09/26 19:08:48 spf: 0, txt: 7, 0.000000%
2011/09/30 01:02:42 spf: 1, txt: 7, 14.285714%
2011/10/10 03:53:19 spf: 42, txt: 157, 26.751592%
2011/10/20 00:39:06 spf: 2, txt: 14, 14.285714%
2011/10/31 19:08:55 spf: 5, txt: 141, 3.546099%
2011/11/02 20:37:05 spf: 0, txt: 16, 0.000000%
2011/11/15 17:15:38 spf: 8, txt: 196, 4.081633%
2011/11/30 19:04:48 spf: 47, txt: 335, 14.029851%
2011/12/12 22:18:55 spf: 1, txt: 294, 0.340136%
2011/12/25 16:04:50 spf: 16, txt: 611, 2.618658%
2011/12/29 17:58:19 spf: 1, txt: 2, 50.000000%
2012/01/12 01:15:17 spf: 2, txt: 52, 3.846154%
2012/01/18 22:24:14 spf: 0, txt: 60, 0.000000%
2012/01/30 00:45:27 spf: 2, txt: 121, 1.652893%
2012/02/02 17:18:54 spf: 54, txt: 288, 18.750000%
2012/02/10 23:59:02 spf: 0, txt: 102, 0.000000%
2012/02/23 00:52:47 spf: 20, txt: 201, 9.950249%
2012/03/19 03:17:46 spf: 118, txt: 580, 20.344828%
2012/03/24 18:33:15 spf: 2, txt: 46, 4.347826%
2012/04/13 16:41:10 spf: 121, txt: 1743, 6.942054%
2012/05/19 18:20:14 spf: 54, txt: 631, 8.557845%
2012/06/07 13:52:26 spf: 82, txt: 961, 8.532778%
2012/07/05 02:48:39 spf: 26, txt: 339, 7.669617%
2012/07/05 18:24:30 spf: 0, txt: 4, 0.000000%
2012/07/07 19:21:02 spf: 3, txt: 25, 12.000000%
2012/07/17 14:48:32 spf: 3, txt: 156, 1.923077%
2012/08/07 18:19:36 spf: 7, txt: 269, 2.602230%
2012/08/19 04:38:08 spf: 23, txt: 198, 11.616162%
2012/08/31 21:23:20 spf: 27, txt: 190, 14.210526%
2012/10/21 07:45:13 spf: 185, txt: 1285, 14.396887%
2012/12/07 21:59:04 spf: 74, txt: 704, 10.511364%
2012/12/11 18:28:28 spf: 0, txt: 24, 0.000000%
2012/12/31 07:51:05 spf: 52, txt: 436, 11.926606%
2013/01/08 00:30:31 spf: 10, txt: 119, 8.403361%
2013/02/02 01:30:47 spf: 22, txt: 341, 6.451613%
2013/02/16 06:44:53 spf: 20, txt: 143, 13.986014%
2013/02/28 01:58:33 spf: 11, txt: 153, 7.189542%
2013/03/05 02:38:51 spf: 5, txt: 75, 6.666667%
2013/03/08 23:47:17 spf: 0, txt: 99, 0.000000%
2013/03/09 02:21:46 spf: 1, txt: 1, 100.000000%
2013/03/20 01:29:03 spf: 46, txt: 1232, 3.733766%
2013/03/24 06:22:59 spf: 15, txt: 212, 7.075472%
2013/03/26 06:03:50 spf: 0, txt: 11, 0.000000%
2013/03/31 23:17:16 spf: 8, txt: 208, 3.846154%
2013/04/06 05:19:48 spf: 37, txt: 587, 6.303237%
2013/04/07 21:53:19 spf: 1, txt: 37, 2.702703%
2013/04/16 18:50:43 spf: 13, txt: 279, 4.659498%
2013/04/22 05:52:43 spf: 3, txt: 163, 1.840491%
2013/04/29 17:56:04 spf: 14, txt: 440, 3.181818%
2013/05/22 16:26:40 spf: 20, txt: 606, 3.300330%
2013/05/23 12:08:25 spf: 1, txt: 9, 11.111111%
2013/05/23 12:30:12 spf: 0, txt: 1, 0.000000%
2013/05/28 19:14:02 spf: 21, txt: 380, 5.526316%
2013/07/01 02:29:15 spf: 51, txt: 2246, 2.270703%
2013/07/01 15:02:05 spf: 2, txt: 16, 12.500000%
2013/07/07 04:50:19 spf: 0, txt: 109, 0.000000%
2013/07/24 01:09:39 spf: 36, txt: 1395, 2.580645%
totals: spf: 1389, txt: 19435, 7.146900%

(the numbers are queries since the name server last restarted/dumped stats)

Will look for better data than my measly little name server.

Regards,
-drc

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 21 Aug 2013 12:00:56 +0200

Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S Moonesamy ([email-masked]
 
> tasked to work on the future of DNS servers.  That does not mean
> that arguments about the future of DNS servers are not relevant.

The codification of a pessimistic view of the ability of the DNS installed
base to adapt to new RRtypes is - in itself - a statement that influences
the future of DNS. That this was not completely understood in terms of
influence weight is one of the reasons for this debate.
 
>  (a) Was there an error in RFC 4408?

Yes. 
 
>  (b) What was the error in RFC 4408?

The TXT rrtype was not properly decommissioned; it lacked definitiveness,
and neither publication instructions nor selection/query algorithm
satisfy this (originally intended, I suppose and believe) sunset view
of the TXT record rôle vis à vis SPF.

>  (d) What should be done about the error?

4408bis needs a better defined depreciation statement for TXT,
accompanied by publication and  query methods that will ensure the
continous phasing-out of SPF data in TXT records.

A clarification here will help in making DNS UI vendors doing the right
thing. I'm quite confident that presently, the UI vendors sleep soundly
after reading 4408 and continuing to ignore SPF/99. That is not 
desirable. 
 
> Is there disagreement on the answers to questions (a) and (b)?

Apparently. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I'm using my X-RAY VISION to obtain a rare glimpse of the INNER
WORKINGS of this POTATO!!

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Aug 2013 12:15:21 +0200

> Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack:
:
:
> Will look for better data than my measly little name server.

I have been looking at the queries to one of the nameservers that Frobbit runs (which is authoritative for quite a number of zones, although not GoDaddy), and a tcpdump for a while today gives the following data:

$ /usr/sbin/tcpdump -nr dns.pcap | grep 'SPF?' | wc -l
reading from file dns.pcap, link-type EN10MB (Ethernet)
tcpdump: pcap_loop: truncated dump file; tried to read 271 captured bytes, only got 95
1105
$ /usr/sbin/tcpdump -nr dns.pcap | grep 'TXT?' | wc -l
reading from file dns.pcap, link-type EN10MB (Ethernet)
tcpdump: pcap_loop: truncated dump file; tried to read 94 captured bytes, only got 18
2819

I.e. 2819 queries for TXT while there was 1105 for SPF resource record.

Now, I have no idea whether all of those queries for TXT was only for the SPF usage of TXT of course, but this gives it was at least 28% of (TXT+SPF)-queries that was for SPF.

Deprecating something that is in use that much just does not make any sense.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Aug 2013 12:26:51 +0200

Patrik,

First, I appreciate that you and Dave are bringing data to the table. 
However, in this case, it is not in dispute that queries are happening. 
What *is* in dispute is whether there are answers.  I must admit I am
having a difficult time understanding the logic, even so.  The *hard*
part about this was supposed to be implementation of the record in the
application software.  Can the shepherd answer this question:

  * To what extent has that happened?

The easy part was supposed to be people actually using the SPF record,
once it was out there.  And so your data doesn't indicate what sort of
answers you're getting.

And another thing. Randy, is it your position that WGs shouldn't create
new TXT records due to transition issues?

Eliot

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Aug 2013 12:42:55 +0200

On 21 aug 2013, at 12:26, Eliot Lear <[email-masked]> wrote:

> The easy part was supposed to be people actually using the SPF record, once it was out there.  And so your data doesn't indicate what sort of answers you're getting.

These are logs on one of my authoritative servers, and the queries you see are the queries sent _TO_ the server. So of course I also have the responses I give to the one those queries.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Aug 2013 13:33:39 +0200

So your point is that their conclusions that nobody has the record
installed is false?

Eliot

---

From: manning bill <[email-masked]>
Date: Wed, 21 Aug 2013 04:55:33 -0700

regarding adoption…  it would be interesting to take a second snapshot from each of these servers in about six months
to see if the trend has changed (modulo PAFs observations that not all TXT == SPF).   In the mean time, declare a suspension of
last call to gauge if the presumption of failure of the SPF RR merits this drastic action.

/bill

On 21August2013Wednesday, at 3:26, Eliot Lear wrote:

> Patrik,
> 
> First, I appreciate that you and Dave are bringing data to the table.  However, in this case, it is not in dispute that queries are happening.  What *is* in dispute is whether there are answers.  I must admit I am having a difficult time understanding the logic, even so.  The *hard* part about this was supposed to be implementation of the record in the application software.  Can the shepherd answer this question:
> 	• To what extent has that happened?
> And another thing. Randy, is it your position that WGs shouldn't create new TXT records due to transition issues?
> Eliot
>

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Aug 2013 08:51:31 -0400

On Wednesday, August 21, 2013 12:00:56 Måns Nilsson wrote:
> Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1)
> to Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S
> Moonesamy ([email-masked]

Translated:

RFC 4408 was in error because it didn't abandon it's installed base.  I gather 
this is an error you propose to rectify.

Scott K

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Aug 2013 23:32:33 +1000

I object to the removal of the SPF record.

Name servers already have access controls down to the granuality
of TYPE.  If this draft proceeds as currently described it is forcing
name server vendors to access controls at the sub TYPE granuality.

With SPF lookup first I can specify the SPF policy using SPF and
leave TXT free for other uses without having to worry about the
records being misinterpeted.

SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF.
This is similar to not proceeding to A/AAAA lookups on MX lookup
failures. 

I would also suggest that there be a sunset date published for the
use of TXT for SPF.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Aug 2013 09:39:28 -0400

No hat

> However, in this case, it is not in dispute that queries are happening. 

Actually, that _was_ in question.  Remember, part of the justification
for ditching TYPE99 is not only that publishers don't use it, but also
that if they did there'd be no benefit.

The evidence the WG produced was that there were hardly any validators
querying for SPF.  The WG originally had somewhat stronger claims in
the draft, and I objected because I felt our sample wasn't good
enough.  The data that Patrik and David have presented suggest that
there might indeed be more to the story, but again there are some
issues with the samples.

There are two additional things that would help make sense of these
numbers.  First, the raw number of queries isn't very interesting, if
mail transactions all turn out to be with the same parties.  We can't
count the same party asking for TYPE99 twice as two validators.
Second, how many of these TYPE99 queries arrive within the same time
frame (yes, I'm waving my hands)?  If the TYPE99 queries are being
issued at the same time as the TXT record, that's an indication that
the query source actually has no preference, and just wants the answer
that comes fastest.

The evidence that the WG looked at suggested that really only Yahoo
preferred TYPE99, and that they stopped preferring it.  There was one
large mail system (I can't recall who) that sent TYPE99 queries, but
actually sent both SPF and TXT at the same time in an effort to get
the quickest response possible.  As Scott has noted elsewhere in this
thread, the SPF processing is often a blocking operation for mail
systems, so latency added by two lookups in that processing is a big
deal (particularly for very large systems).

>   * To what extent has that happened?

I'm not the shepherd, but it is undeniable that most current-era
shipping DNS servers support RRTYPE 99.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Aug 2013 09:44:26 -0400

Speaking as the SPFBIS co-chair…

> last call to gauge if the presumption of failure of the SPF RR merits this drastic action.

I think this would have been a fair request for the LC of RFC 6686,
which was presenting data about the state of the world at the time.
We had a heck of a time getting people to review that document, to
provide data, or to analyse the data.  I think it's unfair to the WG
to have refused to pitch in, and now to tell the WG that it has to sit
on its hands and then do some more work later, particularly because
these two data sets are hardly representative ones.  If we're going to
undertake a large scale data gathering experiment, I'll be all for it
as soon as we have some really large mail system operators involved.
(We did have those in SPFBIS, please note.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 21 Aug 2013 16:03:18 +0200

> (We did have those in SPFBIS, please note.)

Just wondering, could OARC's recent DITL data help? (perhaps if only to
see whether another large-scale targeted effort is needed)

I definitely see TYPE=99 queries on our servers, but I can't see the
answers.

Jelte

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 21 Aug 2013 16:13:16 +0200

On Tue 20/Aug/2013 07:27:12 +0200 David Conrad wrote:
>> one lesson i might take from this is, if i want to deploy a new
>> hack which needs an rrtype, not to use txt in the interim.

Nor the same format, IMHO.

> My personal belief is that the rationale to migrate away from TXT
> remains valid and the appropriate course of action is to fix the 
> migration strategy, not permanently encode what everyone agrees is a 
> hack into a proposed standard.

Normally, it's easier to have new births than to revive dead horses.

The proposed standard is what currently works.  By the time DKIM keys
are transmitted in binary, SPF will have a better spec too.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Aug 2013 16:17:21 +0200

My conclusion is that a statement that nobody queries for it is false.

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2013 16:22:50 +0000

> My conclusion is that a statement that nobody queries for it is false.

I am curious if the folks who did the analysis of query rates know the answers to the following questions:

1. Per unit of mail delivered (as opposed to per domain), for what percentage of delivered mail for which SPF TXT records exist do SPF RRtype records _also_ exist?   I wasn't clear on whether an attempt was made to come up with an answer to this question.

2. Per unit of mail received, for what percentage of received mail does the receiver currently issue SPF RRtype queries.

The reason I ask these questions is that the rationale for the decision made by the working group was that the data supported it, and I think that was a good rationale, but only if the data _actually_ supports it.   But I don't think that the data was analyzed on the basis of units of mail delivered, but rather on the basis of number of queries seen.

The reason I think the distinction is important is that as several people have observed, there are some heavy hitters in this discussion—Yahoo and Google, for example.   If the heavy hitters  all already publish the SPF RRtype, that might make a difference.

Actually, I just checked.   Right now, none of them seem to publish SPF RRtype records.   Yahoo doesn't even publish a TXT record containing SPF information.   An argument could be made that if we really wanted to push the adoption of SPF RRtypes, getting Google, Yahoo and Hotmail to publish SPF RRtype records would actually make it worthwhile to query SPF first, because most queries probably go to those domains.

I think the people who are pushing for a different outcome than the spfbis working group arrived at would do a lot to make their case if they could use their collective influence to get these three domain owners to publish SPF RRtype records.   This is a really easy thing to do; if it can't be done, that's a pretty clear indication that the SPF RRtype is doomed.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Aug 2013 12:54:11 -0400

On Wednesday, August 21, 2013 09:39:28 Andrew Sullivan wrote:
...
> shipping DNS servers support RRTYPE 99.

The operational issues I've encountered with actually trying to use RRTYPE99 
in the wild weren't caused by a lack of support in current-era shipping DNS 
servers.  Sometimes it's not even anything directly related to the DNS.  I 
recall cases where it appeared that firewalls were the root of the problem (I 
don't recall details, sorry).  Solving the DNS servers must support unknown 
RRTYPE/SPF type problem only gets you started.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Aug 2013 13:02:33 -0400

> I object to the removal of the SPF record.

This is not a shock.  You were in the rough when we discussed it in the WG 
too.

> name server vendors to access controls at the sub TYPE granuality.

It's primarily an issue for applications.  To the DNS, it's exactly what it 
is, a TXT record.

> records being misinterpeted.

Unless you have some specific reason to be concerned about accidentally 
starting an unrelated TXT record with "v=spf1 ", I can't imagine you don't 
have more important things to worry about.  This being a "problem" is a great 
theory, but it just doesn't happen in practice.

> This is similar to not proceeding to A/AAAA lookups on MX lookup

Except that it's quite common for a SERVFAIL on TYPESPF to occur for a domain 
that has an actual SPF record due to various operational issues.  SERVFAIL on 
type SPF doesn't reliably tell you anything about what a type TXT lookup would 
produce.  So it's similar, but only superficially so.

> I would also suggest that there be a sunset date published for the

Do you also suggest creation of an Internet police force to enforce this?  
What would be be mandatory minimum sentence?

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 21 Aug 2013 13:20:23 -0400

> once it was out there.  And so your data doesn't indicate what sort of

Eliot, we will add SPF type support in our implementation once the 
infrastructure is ready. For us, as a windows shop, namely Microsoft 
DNS servers.

So the better question I believe would be:

     If the DNS servers begin to support RFC 3597, would you add
     or enable SPF type99 support?  Would you support new RR types
     based on this support presumption?

Of course, the existing base would be low or marginal simply because 
for optimization and lower overhead reasons, it was not added or 
disabled in existing packages.

But I believe the interest was and still is there to support in 
general new RR types once the infrastructure is ready, especially in 
the DNS community.  The question to ask is if it is reasonable to 
believe DNS servers will be improved to support this industry desire 
or need.  If not, then its reasonable to remove SPF type in RFC 
4408bis, and for that matter, forget about all future new RR type 
proposals.  TXT will be the fast entry record of choice.  All recent 
mail related DNS protocols have been TXT, including the new DMARC and 
I don't see that changing (the same folks are producing them).

--
HLS

---

From: S Moonesamy <[email-masked]>
Date: Wed, 21 Aug 2013 10:04:15 -0700

At 04:55 21-08-2013, manning bill wrote:
>regarding adoption…  it would be interesting to 
>take a second snapshot from each of these servers in about six months
>to see if the trend has changed (modulo PAFs 
>observations that not all TXT == SPF).   In the 
>mean time, declare a suspension of
>last call to gauge if the presumption of failure 
>of the SPF RR merits this drastic action.

The IETF chartered the SPFBIS WG to deliver:

   (i)   A document describing the SPF/Sender-ID experiment and its
         conclusions to the IESG for publication.

   (ii)  A standards track document defining SPF, based on RFC4408
         and as amended above, to the IESG for publication.

There is a message from the Responsible Area 
Director ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html 
) and the SPFBIS Chairs ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html 
) about (i).  The SPFBIS  WG was asked to make a 
good-faith effort and that is what the working group did.

The editor of RFC 6686 did a good job.  The IESG 
approved the publication of the draft.  The 
working group worked on its second deliverable 
(ii) after that.  There wasn't any concern about 
the TXT RR as the matter was considered as 
resolved in RFC 6686.  I asked DNSEXT about the 
SPF RRTYPE in the (IANA) DNS Parameters registry 
( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html 
).  It generated long threads on several IETF 
mailing lists.  It was unusual to have that 
amount of comments after the end of a WGLC.

Suspending the Last Call for six months is a 
drastic action.  I would ask the Responsible Area 
Director to consider that if the SPFBIS WG did 
not make a good-faith effort or if there is an 
issue with the process that was followed.  My 
opinion is that the SPFBIS WG made a good-faith 
effort.  There are at least three Area Directors 
reading the SPFBIS mailing list.  They did not flag any process-related issue.

>see whether another large-scale targeted effort is needed)

Yes.  Someone also has to do the work.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Aug 2013 10:31:39 -0700

Patrik,

> My conclusion is that a statement that nobody queries for it is

Assuming that your conclusion is based on pragmatics and not
mathematical purity -- that is, that it is concerned with significant
operational effort, rather than a stray implementation here or there,
which counts as "noise" in any legitimate statistical analysis -- what
is the basis for your conclusion?

In other words, please explain how your objection is based on real-world
utility rather than something more abstract and detached from practical
operations.

 From your posting to the dnsext working group:

> On 8/20/2013 11:58 AM, Patrik Fältström wrote: In general I do
> believe, for example when looking at IPv6 and DNSSEC and similar
> technologies, that the lifetime of RFC 4408 is too short to
> deprecate any of the proposed records that are in use, specifically
> as RFC 4408 explicitly do allow use of both.

On its face, this sort of thinking means that, in practical terms,
nothing can ever be deprecated.

It also requires a rather willful ignorance of the essential community
operations differences between SPF and IPv6 and DNSSec.  There is
massive effort to increase use of the latter.  There is massive apathy
about the former.

That is, the metric of essentially no adoption or use is matched by no
vector of change.

So if you really insist on pursuing your objection, please find some
arguments that are anchored in relevant, real-world analytic legitimacy.

d/

---

From: "John Levine" <[email-masked]>
Date: 21 Aug 2013 17:44:32 -0000

>Actually, I just checked.   Right now, none of them seem to publish SPF RRtype records.
>Yahoo doesn't even publish a TXT record containing SPF information.   An argument could
>be made that if we really wanted to push the adoption of SPF RRtypes, getting Google,
>Yahoo and Hotmail to publish SPF RRtype records would actually make it worthwhile to
>query SPF first, because most queries probably go to those domains.

This would require some reason why it is worth them spending time and
money to do something that has no operational benefit whatsoever.

If they start publishing type 99, something will break, because when
you change something in large systems, something always breaks.  Some
mail systems somewhere with bugs in type 99 handling that they never
noticed will start making mail fail.  For doing that, will anyone's
mail work better?  No.  Will their DNS work better?  No.

As I have mentioned a couple of times already, even though Yahoo
doesn't publish SPF (I believe due to political issues related to the
history of Domainkeys and DKIM), they do check SPF.  They used to
check both TXT and type 99, and stopped checking type 99.  What
argumment is there to spend money to revisit and reverse that
decision?

Arguments about DNS purity, and hypothetical arguments about other TXT
records that will never exist are unlikely to be persusasive.

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Aug 2013 20:13:53 +0200

> is the basis for your conclusion?

As I did show, the numbers comes directly from tcpdump on my auth DNS server, where I checked how many do query for TXT and SPF(*). I do not understand the question. What else do you want?

As a few others have said, 4408 do have an error that makes it impossible to use RFC 4408 for migration from TXT to SPF which was the original intent. I do not understand how the conclusion, given the number of SPF queries that is made, on how to fix the problem with RFC 4408 is to deprecate the SPF RRtype.

And to your question on deprecation, yes, to me one do need much more arguments to deprecate something. Specifically when originally the intent was to migrate to what is now to be deprecated.

And this is why I am objecting to 4408bis to be published as an RFC.

If you had an RFC without issues that really did talk about a migration strategy (including having examples using SPF records and not TXT which one should migrate from) and still people did not migrate, then we would have a different discussion.

But we are not there. A proper migration strategy to SPF has not been published.

   Patrik

(*) I have now removed TXT version of the SPF record for frobbit.se to see whether the number of queries for SPF RRType go up or not.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2013 18:21:12 +0000

> money to do something that has no operational benefit whatsoever.

Sorry, I wasn't trying to make an argument for you to refute.   I'm saying that if the people who want to change the outcome of the spfbis consensus are serious, this would be a good way to show that they have community support for their position.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Aug 2013 11:29:54 -0700

> But we are not there. A proper migration strategy to SPF has not been published.

Oh.  Now I understand.

You are trying to impose new requirements on the original work, many 
years after the IETF approved it.

Thanks.  Very helpful.

d/

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 21 Aug 2013 14:44:41 -0400

> approach that uses a TXT record.

For the record I think SPF RRtype retirement is not in the good-idea category, but nor is it
in the bad-idea category,  it falls in the we need-to-do-something-that-works. 

Most of the recent arguments against SPF type have come down to the following (as far as I can tell): 
	a) I can not add SPF RRtype  via my provisioning system into my DNS servers
	b) My firewall doesl not let SPF Records through 
	c) My DNS library does not return SPF records through or does not understand it, thus the application can not receive it.
	d) Looking up SPF is a waste of time as they do not get through, thus we only look up TXT

So what I have taken from this is that the DNS infrastructure is agnostic to RRtype=99 but the 
edges have problems. 
As to the arguments 7 years is not long enough to reach conclusion and force the changes through the
infrastructure and to the edges. The "need" for SPF has been blunted by the "DUAL SPF/TXT" strategy and 
thus we are basically in the place where the path of lowest-resistence has taken us. 

What I want the IESG to add a note to the document is that says something like the following: 
"The retirement of SPF from specification is not to be taken that new RRtypes can not be used by applications, 
the retirement is consequence of the dual "quick-deploy" strategy. The IETF will continue to advocate application 
specific RRtypes applications/firewalls/libraries SHOULD support that approach."

	Olafur

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Aug 2013 20:45:02 +0200

On 21 aug 2013, at 20:29, Dave Crocker <[email-masked]> wrote:

> You are trying to impose new requirements on the original work, many years after the IETF approved it.
> 
> Thanks.  Very helpful.

Dave, I do not appreciate the tone of your message.

I explain as part of a last call of a message to the IETF mailing list why I object to publication of an I-D as an RFC.

If the IESG comes to the conclusion that the document should be published fine. If they say it should not. Fine.

That is the IETF process.

I should have staid on the DNS mailing list as I said originally, where I promised people I should not discuss SPF anymore on the main IETF list because I knew the pushback from you and a few others would be exactly like this. I was convinced to give my view on SPF to the IETF list so that it was known correctly to the last call process. A process I have always trusted and believed it. And still trust and still believe in.

This is my last posting in this thread.

   Patrik

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Aug 2013 14:50:54 -0400

On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote:
> >>> is
> >> does
> For the record I think SPF RRtype retirement is not in the good-idea
> category, but nor is it in the bad-idea category,  it falls in the we
> need-to-do-something-that-works.
> 
> Most of the recent arguments against SPF type have come down to the
> following (as far as I can tell): a) I can not add SPF RRtype  via my
> provisioning system into my DNS servers b) My firewall doesl not let SPF
> Records through
> 	c) My DNS library does not return SPF records through or does not
> understand it, thus the application can not receive it. d) Looking up SPF
> is a waste of time as they do not get through, thus we only look up TXT
> 
> So what I have taken from this is that the DNS infrastructure is agnostic to
> RRtype=99 but the edges have problems.
> As to the arguments 7 years is not long enough to reach conclusion and force
> the changes through the infrastructure and to the edges. The "need" for SPF
> has been blunted by the "DUAL SPF/TXT" strategy and thus we are basically
> in the place where the path of lowest-resistence has taken us.
> 
> What I want the IESG to add a note to the document is that says something
> like the following: "The retirement of SPF from specification is not to be
> taken that new RRtypes can not be used by applications, the retirement is
> consequence of the dual "quick-deploy" strategy. The IETF will continue to
> advocate application specific RRtypes applications/firewalls/libraries
> SHOULD support that approach."

I'm a bit unsure that continue is the right word.  DKIM moved to the TXT with 
underscore approach and, IIRC, never considered a new RRTYPE, nor did anyone 
ever suggest they should.  DMARC, which has had a BoF and for which a WG is 
being considered will do the same (there's no variant of proposed charter text 
floating around that would allow them to consider otherwise).  

I agree with that the notion of a statement that SPF is what it is for a 
variety of reasons and shouldn't be considered as a precedent for the future 
might be a reasonable thing to add.  I don't think the IETF has been very 
consistent about what one ought to do instead.

Scott K

---

From: Pete Resnick <[email-masked]>
Date: Wed, 21 Aug 2013 13:58:56 -0500

AD hat squarely on my head.

> years after the IETF approved it.

That's not an appropriate response. It is certainly not helpful to me as 
the consensus caller. And it is rude.

It's perfectly reasonable to say, "This would constitute a new 
requirement and I don't think there is a good justification to pursue 
that line." The sarcasm is not reasonable.

Please stop.

pr

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Aug 2013 12:17:18 -0700

> the consensus caller. And it is rude.

Since you've made this a formal process point, I'll ask you to 
substantiate it carefully and also formally.  The implication of your 
assessment is that IETF participants must not comment on the utility of 
comments by others.

I don't recall that being a proscribed behavior, since it has nothing to 
do with personalities.  So, please explain this in a way that does not 
sound like Procrustean political correctness.

For the record, I entirely acknowledge that my note has an edge to it 
and yes, of course alternate wording was possible.  However the thread 
is attempting to reverse extensive and careful working group effort and 
to ignore widely deployed and essential operational realities, including 
published research data.

A bit of edge is warranted for such wasteful, distracting and 
destabilizing consumption of IETF resources.  In fact an important 
problem with the alternate wording, such as you offered, is that it 
implies a possible utility in the thread that does not exist.

d/

---

From: Pete Resnick <[email-masked]>
Date: Wed, 21 Aug 2013 14:46:11 -0500

On 8/21/13 2:17 PM, Dave Crocker wrote:
> assessment is that IETF participants must not comment on the utility 
> of comments by others.

That's not what I said, and in fact if you look at the line immediately 
following what you quoted, you will see that I said:

>> that line."

It is not your complaint about the imposition of new requirements that 
is problematic, or your point that it is not useful to continue that 
line of discussion. Talk about the utility of a comment all that you 
want. It is the sarcasm and the rudeness that I am saying is 
unreasonable. Especially coming from a senior member of the community, 
the only purpose it seems to serve is to bully others into not 
participating in the conversation. If you think that the conversation 
has gone on too long, you're perfectly within rights to ask the manager 
of the thread (in this case, myself or the chairs), in public if you 
like, to make a call and say that the issue is closed. But again, the 
tactics displayed above are not professional and not reasonable 
rhetorical mode.

> I don't recall that being a proscribed behavior, since it has nothing 
> to do with personalities.  So, please explain this in a way that does 
> not sound like Procrustean political correctness.

I am not sure what the first sentence means. And I'm sorry that you 
believe that my stance on this is Procrustean. But the fact is that rude 
comments of this sort do not contribute to consensus-building in the least.

> is attempting to reverse extensive and careful working group effort 
> and to ignore widely deployed and essential operational realities, 
> including published research data.

I appreciate your input that you believe that some or all of the 
objectors are ignoring operational realities. Perhaps they are. But the 
fact is that Last Call is a time for the community to take a last look 
at WG output. If senior members of the community (among which there are 
several in this thread) are suspicious of the output, it *is* important 
to make sure that their concerns are addressed. Maybe they simply don't 
have all of the information. But maybe the WG has missed something 
essential in all that careful work. Both have historically happened many 
times.

> implies a possible utility in the thread that does not exist.

It is far more distracting and destabilizing for the IETF to come out of 
a Last Call with experienced members of the community suspicious that a 
bad result has occurred, especially if the tactic used to end the 
discussion was sarcasm to chase people away from the discussion. You are 
looking at only the little picture. The consensus might end up on the 
rough side, but  having the conversation has utility in and of itself.

I find your "edge" much more disruptive to the conversation, making it 
much more adversarial than explanatory, and damaging the consensus that 
might be built. I think that lowers the utility of the output tremendously.

pr

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 21 Aug 2013 22:05:37 +0200

Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting Scott Kitterman (scott@kitterma
> this is an error you propose to rectify.

Well, almost. 4408 sort of blunders about like the elephant in a china
shop wrt. query method and depreciation. 
	(As I have been sternly lectured off-list that I do not understand
	the SPF payload and therefore am in no position to discuss the
	DNS usage, I'd like to assert that the payload syntax matters
	marginally, if at all, for the discussion about which DNS records
	to use and how.)

Specifically, 4408 section 3.1.1 should be updated to: 

* A domain SHOULD use SPF and MAY use TXT. The latter is only suitable if
  SPF is impossible to publish. 

* If it is possible to use SPF as a result of having modern provisioning
  systems, SPF MUST be used and consequently, TXT SHOULD NOT be used. (I'd
  like MUST here, but I'm not certain it flies.) If SPF and TXT coexist, 
  they MUST agree wrt content. 

* The notion of a sunset date as introduced by Mark Andrews, is interesting. 

Section 4.1.1 in 4408 should be altered to direct implementations to
FIRST look for SPF and then _perhaps_ (I'm open for discussion) ask for
TXT, thus creating an incentive to improve performance by serving SPF
rather than TXT. After a possible sunset, TXT MUST NOT be queried for. 

The preference for SPF vs TXT that is present in 4408 is to be kept
unaltered.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!!

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Aug 2013 16:52:59 -0400

On Wednesday, August 21, 2013 22:05:37 Måns Nilsson wrote:
> to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting
> Scott Kitterman (scott@kitterma
> > > Apparently.
> > 
> > Translated:
> > 
> > RFC 4408 was in error because it didn't abandon it's installed base.  I
> > gather this is an error you propose to rectify.
> 

This is the point where you abandon the installed base.  Particularly given 
the charter, I think this is an inappropriate approach.

>   they MUST agree wrt content.

draft-schlitt-spf-classic-02, which became RFC 4408, had this MUST when it was 
approved by the IESG.  Since at the time of IESG approval, the RRTYPE for SPF 
hadn't been allocated yet, they - by necessity - approved a paper design.  
Fortunately the RRTYPE was allocated sufficiently before AUTH48 that we were 
able to experiment with running code and determine that this MUST was 
operationally extremely problematic, so it was removed as part of the AUTH 48 
review.

> rather than TXT. After a possible sunset, TXT MUST NOT be queried for.

The performance implications are more generally constraining on the receive 
side in high volume mail systems.  Adding a second set of sequential DNS 
queries is a non-starter.  It's much more efficient to go straight to TXT where 
99%+ of the time I'll get a correct answer [there are a minute number of 
domains that publish SPF only, but virtually all type SPF publishers also 
publish TXT].  I think you're putting the performance implications on the 
wrong end of the conversation.

Let's say we get to this magical sunset date, whose behavior do you think it 
will influence if they are finding the TXT queries still useful (if they aren't, 
they won't do it and you don't need the sunset date)?

> The preference for SPF vs TXT that is present in 4408 is to be kept

Here's a related conundrum that I haven't seen operationally (due to limited 
RRTYPE SPF deployment, but I have seen similarly for real in the fallback to 
v=spf1 records in the SenderID RFCs).  It's an example of why you can't ignore 
the payload.  One of the widely used features of SPF is the "include" 
mechanism.  It allows a sender to authorize the hosts of a third party to send 
mail on its behalf.  It also allows SPF records to be chained together to 
publish more information while staying in the standard UDP packet limit.  
Here's an example for the latter from Microsoft's current SPF record:

v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com ...

A key aspect of "include" is that the targe domain MUST have an SPF record.  
If it doesn't, it's a "permerror" - permanent error.  Let's imagine for a 
moment that example.com has this record published in RRTYPE SPF:

v=spf1 a include:example.org -all

Then let's consider example.org and imagine that, like most SPF participants 
today, they have their record published in RRTYPE TXT only:

v=spf1 a -all

A receiver, as you suggest, checks RRTYPE SPF when they get mail from 
example.com.  Their SPF verifier processes the "include" mechanism and 
determines it needs to do a lookup for example.org's SPF record.  They query 
RRTYPE SPF and they get ANSWER: 0 in return.  Should this verifier:

1.  Return a "permerror" because the target domain of an "include" doesn't 
exist?

2.  Press on and query RRTYPE TXT, get an SPF record back, and finish the 
transaction without error?

RFC 4408 doesn't help us here because it's treatment of the TXT/SPF 
coexistence model is not complete.  

I have said before that I don't think an effective transition model exists nor 
can it be created.  I think Olafur Gudmundsson's suggestion that 4408bis 
document this use of TXT as an architectural wart and move on is a good one.

I think this is a symptom of the larger problem that most initial development 
work in this space is done outside the IETF and only brought to the IETF when 
it's reasonably well baked.  This is true for SPF, DK -> DKIM, and DMARC, all 
of which use TXT.  I would encourage those who want this to be different in the 
future to make contact with the people involved in DMARC (I wasn't) and ask 
them what it would have taken to get them to consider a new RRTYPE in their 
design.  Whatever those barriers are, that's what needs to be addressed.  
Focusing to trying to "fix" SPF shouldn't be the priority.  It is what it is.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Aug 2013 14:40:43 -0700

> unreasonable. Especially coming from a senior member of the community,

OK.  No sarcasm in IETF postings.  Good luck with that.

More seriously...

You might have noticed that there have been a variety of folk making 
unrealistic or misguided suggestions and that they have been receiving 
entirely muted and exploratory -- albeit negative -- responses.

The implication that I think you've missed here is the obligation that 
should hold for a 'senior' participant who is lodging concerns.  The 
current thread is being tenaciously pursued by another "senior" member 
and former AD and the line of objections and requirements being put 
forward are studiously ignoring the considerable efforts of the working 
group and the considerable practical field history.

As such, they represent their own form of disrespect.

The alternative phrasing you suggest makes sense for average, random, 
problematic criticism.  But as I indicated in the previous note, the 
phrasing suffers from implying a degree of legitimacy that is not 
warranted for this thread, from another 'senior' participant.

I realize you don't agree with that view, but I'll again note that I'm 
not aware of any formal rule that my posting violated and certainly not 
any pattern of IETF practice.  (Of course I can read the Code of Conduct 
to the contrary, but having done that, I felt that each of its relevant 
points had a counter in this case.)

I, too, preferred a far more constructive tone to the thread, and 
attempted to contribute that initially.  But persistent 
unreasonableness, when it can't be attributed to ignorance, warrants an 
explicit note.  So I gave it.

Taking this thread seriously, even to the extent of treating it with a 
cautiously respectful tone, encourages a persistent silliness in the 
IETF that is strategically destructive, because it communicates our 
tolerance for having experienced participants waste people's time and 
effort.

> participating in the conversation.

You think I could bully Patrik?  Good luck with that, too.

 >If you think that the conversation

The thread itself does not have a professional premise, Pete.  The 
record needs to reflect at least one comment to that effect.

> comments of this sort do not contribute to consensus-building in the least.

The thread has its own responsibility to attempt consensus building.  It 
wasn't doing that.  In fact, in its way, it has represented a classic, 
continuing of bullying against DNS pragmatics.

> objectors are ignoring operational realities.

I didn't say that.  This current exchange is about a specific thread. 
It is now your turn to be more careful in what you assert.

> Perhaps they are. But the
> to make sure that their concerns are addressed.

Only after determining that their concerns are reasonable.

> Maybe they simply don't

Again, you are missing the point that we'd already done through quite a 
bit of that, with no apparent effect.

> bad result has occurred,

As an abstraction, your point is of course entirely valid.  But your 
premise is that a reasonable discussion is possible and that the 
suspicions can be allayed.  We already had solid indications that 
neither were achievable.

d/

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Aug 2013 07:48:31 +1000

> It's primarily an issue for applications.  To the DNS, it's exactly what it 

No.  It isn't.  By overloading TXT you prevent thing like this which
existed before SPF was even dreamed up.

	update-policy {
		grant key-one subdomain example.net ANY
		deny key-two domain example.net SPF
		grant key-two domain example.net ANY
	};

	or

	update-policy {
		grant key-one subdomain example.net ANY
		grant key-two domain example.net TXT
	};

Overloading a type is bad on so many levels which is why it was
argued that SPF needed its own type.  TXT is good for prototyping
and that is about all.

	update-policy {
		grant key-one subdomain example.net ANY
		deny key-two domain example.net TXT/v=spf1
		grant key-two domain example.net ANY
	};

	update-policy {
		grant key-one subdomain example.net ANY
		deny key-two domain example.net TXT/v=spf1
		grant key-two domain example.net TXT!v=spf1
	};

> theory, but it just doesn't happen in practice.

It's about being able to hand someone update control and not having to
worry about them stuffing up the SPF records.
 
> produce.  So it's similar, but only superficially so.

And the worst that happens is that you let some *additional*
potentially spoofed email through.  This WG seems to treat this
as a catastrophic errror when it isn't.  This whole debate is
because this working group treats not stopping one additional
forgery as a catastrophic errror.

Note also that it will be the publishing site to blame for having
a non RFC 1034 compliant server (it didn't respond to SPF queries)
or misconfigured zone (returns wrong SOA in the negative response 
which can't happen when they have a SPF record).

> What would be be mandatory minimum sentence?

You just code the cut off date into the code that does the verification
and stop making TXT queries.  You code the date into the code that
checks for missing SPF records and change the complaint.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Aug 2013 18:13:06 -0400

In this conversation between Pete and Dave, there's one point that's
come up which has come up often enough that I want to call it out

> You think I could bully Patrik?  Good luck with that, too.

Let's take this out of the context of the discussion at hand, and be
more general -- because, as I said, I'm reacting not to the statement
as it stands, but to how often I've seen it made (twice within the
last few weeks alone).

The form is this:
Point: You behaved badly toward [person X].
Counterpoint: Well, [person X] has been around, he can handle it.

Often, there's a further response that agrees that, indeed, [person X]
can take it, so all is OK.

No.  All is not OK.
What this argument leaves out is consideration of everyone *else*
who's reading this exchange and putting themselves in the shoes of
[person X].  Many of them are looking at what to expect from engaging
in IETF discussions, many of them are not old-timers with thick skins
and an understanding of IETF rhetoric, and many of them will be put
off of participating because they see how we treat those who do
participate.

Again, remember: I'm not talking about this particular discussion, so
let's not fixate on whether or not being abrupt, sarcastic, abusive,
offensive, profane, or whatever... is appropriate for this
conversation.  The general point is that the new people whom we want
to draw in as productive participants will be watching how we treat
each other and deciding whether they want to wade into that pool.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Aug 2013 23:25:06 +0100

On 08/21/2013 11:13 PM, Barry Leiba wrote:
>   The general point is that the new people whom we want

Yes, that is a factor that merits attention.
But not the only nor an always-overriding one.
For example brevity matters, technical correctness
wins, humour is important and can be cruel.

I can't myself think of a good justification for
sarcasm, (well, maybe [1]:-) but I can understand
that sometimes people make mistakes. And sometimes
the same people make the same mistakes many times.
We're not here to make them better though. Calling
'em on it is a good way to handle it I think.
 Generalising to the point where we are all expected
to be politically correct clones would not. (Yes,
I'm exaggerating what you're saying there:-)

S.

[1] https://en.wikipedia.org/wiki/List_of_Father_Ted_characters
and search for sarcastic:-)

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Aug 2013 08:25:14 +1000

> > It's primarily an issue for applications.  To the DNS, it's exactly what it 

I can hand update of A and AAAA records to the machine.
I can hand update of MX records to the mail adminstrator.
I can hand update of SPF records to the mail adminstrator.
I can hand update of TXT records to ??????

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 22 Aug 2013 00:26:35 +0200

Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 04:52:59PM -0400 Quoting Scott Kitterman (scott@kitterma
> the charter, I think this is an inappropriate approach.

As I'm thinking about migration here, let's be generous. Allow publication
of TXT too, even if SPF is possible, but then not alone.
 
> operationally extremely problematic, so it was removed as part of the AUTH 48 

Hence my comment about perhaps flying. 
 
> queries is a non-starter.  

Why? There is caching. DNS queries are cheap. The problem of overloading TXT is 
IMNSHO so bad that it is worth the cost of additional queries; especially
if we can collaborate on text to stimulate migration by constructing
and specifying algorithms that are faster when using SPF rrtype only.

> It's much more efficient to go straight to TXT where 

(ITYM TODAY it is much more efficient and that might change)

> coexistence model is not complete.  

Indeed, and I was inexact in endorsing current text. What I meant was this sentence: 

   2. If any records of type SPF are in the set, then all records of
      type TXT are discarded.

	(section 4.5, record selection process) 

> can it be created.  

I think this stems from two things, both fixable; 

* The somewhat confused "migration" model of 4408 creating a "cheap
  escape" for vendors and users.

* The lack of normative language stating that SPF MUST be used. 

> I think Olafur Gudmundsson's suggestion that 4408bis 

I happen to think that this wart is malign and will create undesirable
growth, as has been proven with a number of other spam-stomping systems
using TXT. Short of amputation I think we can justify a lot more surgery
than the present make-up.

> design.  Whatever those barriers are, that's what needs to be addressed.  

I agree. 

> Focusing to trying to "fix" SPF shouldn't be the priority.  It is what it is.

SPF is a flagship case for the "use a TXT record and continue to IPO"
fast and sloppy crowd. It needs correcting. Badly.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
All of life is a blur of Republicans and meat!

---

From: S Moonesamy <[email-masked]>
Date: Wed, 21 Aug 2013 15:32:16 -0700

Hello,

Lars Eggert mentioned [1] the following:

   "cool off, take the intensity out of the discussion, and try
    to provide data/facts for your different standpoints, so the
    rest of us who are sitting on the sidelines watching the
    fireworks can form an opinion."

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/diversity/current/msg00222.html

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Aug 2013 19:07:25 -0400

>I can hand update of TXT records to ??????

No one because it has multiple uses.  This is true whether SPF exists or not.  SPF use of RRTYPE TXT for SPF records makes that neither better nor worse.

You could publish:

example.com IN TXT v=spf1 redirect=_spf.example.com
_spf.example. com IN TXT v=spf1 [actual content here]

Then delegate _spf.example.com to the mail administrator.  Problem solved.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Aug 2013 19:12:27 -0400

>		grant key-two domain example.net TXT!v=spf1

This can be solved other ways.  See my repky to your later message.

>forgery as a catastrophic errror.

I prefer to design things for reliability rather than ignore interoperability problems. 

>which can't happen when they have a SPF record).

Or some firewall in a box in between. Blame is not so easy to determine. 

>checks for missing SPF records and change the complaint.

Is there an example of this kind of approach working? 

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 21 Aug 2013 16:16:12 -0700

Hi Eliot,
At 03:26 21-08-2013, Eliot Lear wrote:
>First, I appreciate that you and Dave are bringing data to the 
>table.  However, in this case, it is not in dispute that queries are 
>happening.  What *is* in dispute is whether there are answers.  I 
>must admit I am having a difficult time understanding the logic, 
>even so.  The *hard* part about this was supposed to be 
>implementation of the record in the application software.  Can the 
>shepherd answer this question:
>To what extent has that happened?

There is a thread about libspf2 querying for RRTYPE 99 first ( 
https://lists.exim.org/lurker/message/20110812.094310.3a53c0f6.gl.html#exim-users 
).

I'll also mention 
http://support.godaddy.com/groups/domains-management-and-services/forum/topic/spf-type-99/ 
and http://features.cpanel.net/responses/ability-to-create-spf-type-99-records

Here are a few messages on the SPFBIS mailing list about RRTYPE 99:

http://www.ietf.org/mail-archive/web/spfbis/current/msg00555.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg03778.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg03781.html

The SPFBIS WG Chair asked a question about what to conclude given the 
SPFBIS Charter ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03779.html ).

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Aug 2013 09:31:03 +1000

> Then delegate _spf.example.com to the mail administrator.  Problem solved.

No, it is NOT solved.  You have to trust *everyone* with the ability
to update TXT not to remove / alter that record.  You can't give someone
you don't trust the ability to update TXT.

With a published SPF record and SPF lookup first stopping on success
or lookup failure (SERVFAIL) you can give update control of TXT to
someone you don't trust enough to not remove / alter the SPF TXT
record.

You keep telling us the TXT is just another record in the DNS.  Well
the DNS is managed at the granuality of the TYPE.  4408bis is forcing
sub-type management to be developed and deployed to maintain the
status quo.  TXT is no longer "just another record in the DNS" with
4408bis as it currently stands.

And to Google your motto is "Do No Evil".  Publishing a TXT SPF record
without publish a SPF SPF record is "Evil" as it encourages other to
do the same.

Mark

---

From: Hector Santos <[email-masked]>
Date: Wed, 21 Aug 2013 20:32:26 -0400

> floating around that would allow them to consider otherwise).  

Consider that those specifications were written by the same author and 
group of folks. In no special meaning in any way, they all have had 
the same engineering mindset when it came the DKIM, VBR, ADSP and now 
even yet another DMARC proposed protocol. Same engineers, same 
engineering synergism.   Thats not a negative commentary. This is 
desirable in an integrated world, but it can also locked down certain 
views as it has this case.

DKIM learned from the SPF success with TXT. I specifically recall the 
WG decision discussion and it made practical sense. It allowed for an 
immediate entry point and fast proof of concept industry wide by using 
a TXT-based protocol, not only for DKIM but also for its original 
companion protocol ADSP (formerly SSP).  Overall, I had sense a 
growing change in TXT-based protocol acceptability with many folks who 
otherwise were against it and this was quite apparent to me being 
highly considerate and cognizant of the technical design issue.

It was for this reason I asked the question in the DNSEXT list and 
IETF before LC about where the industry stood in regards to TXT based 
solutions. I always had  several ideas of my own for TXT-based DNS 
proposals such as DSAP (DKIM Signature Authorization Protocol) and a 
few others and if the IETF/DNS community was going to changed its 
belief and now endorse the TXT ideas, I didn't want to propose 
anything that would be controversial such as a new RR type, although 
that would most likely appease the DNS folks.

> consistent about what one ought to do instead.

I don't agree with the SPF exception. If you believe in the future 
infrastructure to support new RR types, then there is no sensible 
reason to remove the SPF type and migration path from an updated 
RFC-4408BIS document.

I don't see any harm in keeping the migration path IFF there is 
confidence a supportive infrastructure will be available in the future.

--
HLS

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Aug 2013 17:46:58 -0700

Scott,

> Then delegate _spf.example.com to the mail administrator.  Problem solved.

Wouldn't this cause an extra lookup that you were arguing was prohibitive for large scale mail providers?

Regards,
-drc

---

From: John Leslie <[email-masked]>
Date: Wed, 21 Aug 2013 23:02:02 -0400

NB: I have read the rest of the thread; but this is what deserves a reply:

>> AD hat squarely on my head.

   (There may have been a miscommunication here -- what particular AD
function Pete was speaking in; but to me, at least, it becomes clear
in context.)

>> That's not an appropriate response.

   Dave has every right to disagree on that; but I quite agree with
Pete. It is decidedly not helpful, not productive, and tends towards
escalating a discussion which has no need of escalation.

>> It is certainly not helpful to me as the consensus caller.

   Dave has no right to disagree with this. We pay Pete the big bucks
to call consensus on difficult issues like this. We need to understand
it will be hard sometimes.

   I'm sure Dave has read Pete's draft on the meaning of consensus.
I'm less sure he remembered it as he responded here.

   If this is the sort of response given to somewhat-valid questions
raised about the draft being proposed, Pete will eventually have to
say there _is_ no consensus. :^(

>> And it is rude.

   Pete's opinion. (I happen to share it.)

   Consensus process works _much_ better if we respect the opinions
of others -- even when we "know" they're wrong.

> Since you've made this a formal process point,

   Pete has _not_ done this.

> I'll ask you to substantiate it carefully and also formally...

   I see no reason Pete has any obligation to do so. If he chooses
to, I ask him to not do it on this list. ("Please don't feed the
troll" comes to mind.)

> destabilizing consumption of IETF resources...

   Dave's opinion. (I happen to not share it.)

   Consensus process _also_ works better if we respect Dave's
opinion here.

   I suggest we all remember that we don't have to change others'
opinions here (were such a thing possible). We have only to bring
them to the point where they agree they can live with the result.

--
John Leslie <[email-masked]>

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Aug 2013 23:20:25 -0400

On Thursday, August 22, 2013 09:31:03 Mark Andrews wrote:
> > >In message <[email-masked]>, Mark Andrews
> > >
> > >writes:
> > >> > It's primarily an issue for applications.  To the DNS, it's exactly
> > >
> > >what it
> > >
> > >> > is, a TXT record.
> > >
> > No one because it has multiple uses.  This is true whether SPF exists or
> > not.  SPF use of RRTYPE TXT for SPF records mak es that neither better
> > nor worse.
> > 
> > You could publish:
> > 

Your goal seems to be pretty much the opposite of the task the working group 
was given.  You say so even more clearly here:

http://www.ietf.org/mail-archive/web/spfbis/current/msg03948.html

Unless you come with something new, I think I'm done.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 21 Aug 2013 21:12:37 -0700

Hi John,
>say there _is_ no consensus. :^(

An Area Director may say that. :-(

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 22 Aug 2013 00:23:56 -0400

On Thursday, August 22, 2013 00:26:35 Måns Nilsson wrote:
...
> fast and sloppy crowd. It needs correcting. Badly.

Which IPO was that?

BTW, in 2003 the choice was use TXT or nothing.  So it was a crowd that wanted 
to accomplish something and did it the only way it was possible.  Considering 
use of TXT wasn't an important factor in the DKIM last call, I conclude that 
this isn't really about using TXT.

Scott K

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 22 Aug 2013 10:01:03 +0200

Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Thu, Aug 22, 2013 at 12:23:56AM -0400 Quoting Scott Kitterman (scott@kitterma
> this isn't really about using TXT.

It indeed is -- but SPF is as I wrote above a flagship case. SPF was the
first, is the most deployed (as its supporters repeatedly assert, wringing
their hands, trying to sound apologetical and/or defaîtistic) case of
tragedy in the commons that is "automated data processing of content
in comments" and when its proponents try to codify the behaviour of
stampeding into the commons by removing the SPF rrtype, enough is enough.

Are we THERE yet?

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 22 Aug 2013 10:36:29 +0200

> specific RRtypes applications/firewalls/libraries SHOULD support that approach."

So what makes you think the above 4 points will not be a problem for the
next protocol that comes along and needs (apex) RR data? And the one
after that?

While I appreciate the argument 'this works now, and it is used'
(running code, and all that), I am very worried that we'll end up with
what is essentially a free-form blob containing data for several
protocols at the zone apexes instead of a structured DNS.

So if this approach is taken, I suggest the wording be much stronger, in
the hope this chicken/egg problem (with 5 levels of eggs. or chickens)
will be somewhat mitigated at some point. Preferably with some
higher-level strategy to support that goal.

Jelte

---

From: Pete Resnick <[email-masked]>
Date: Thu, 22 Aug 2013 09:22:41 -0500

> OK.  No sarcasm in IETF postings.  Good luck with that.

Luckily, again, that's not what I said or intended.

Some evidence to the contrary, the IETF is a human endeavor. It involves 
interactions among people. So there will be sarcasm, and humor, and loss 
of temper, and comments with all sorts of embedded meanings. Sometimes 
these things lighten the mood, make the conversation more interesting, 
cause people to think about things in different ways, and contribute to 
the interaction. Sometimes they can have seriously problematic effects. 
Sometimes it will be unclear. And, even though some of our ranks appear 
to want it to be otherwise, there are no nice engineering specs for 
this. It's all very contextual, and is going to depend on the speakers 
and the listeners and the topic of conversation. Social interactions are 
complicated that way.

But there is something going on in the present thread, and in particular 
the mode of communication I objected to here, that I think warrants 
pushback:

> forward are studiously ignoring the considerable efforts of the 
> working group and the considerable practical field history.
>

I used the word "bullying" with regard to your particular message for a 
very specific reason. Bullying is normally using one's position of power 
to intimidate. I want to circle back a bit to the particulars of the SPF 
discussion:

The SPFBIS WG came to the conclusion regarding deprecating the use of RR 
99 through a very long discussion. There was an extensive review of 
data. (Indeed, there was some initial reluctance in the WG to do as much 
research into the numbers as was eventually done, and I think in the end 
everyone was glad that the WG did do as much work as it did on the 
topic.) There was an extensive discussion of the implications of all of 
the choices. And, with some rough edges, the WG pretty solidly convinced 
itself that it had chosen the right path. And not just that: The WG 
convinced both chairs that they had chosen the right path (one of the 
chairs being the chair of DNSEXT). And they convinced the responsible 
AD. And during WGLC they even convinced the responsible AD for DNSEXT, 
who was originally quite opposed, that the decision was well-considered 
and the correct one in the end. And I believe none of these folks were 
convinced because opposing views were kicked out of the conversation; 
data was presented and explanations were made, and they were convinced. 
Solid consensus was reached, such that as the eventual consensus caller, 
I am quite sure that I'm going to have to see a very carefully reasoned 
new argument in order for me to think that something was missed by this 
WG. Anyone currently outside of the consensus has a pretty high bar to 
clear; they are at a significant disadvantage in the conversation if 
they have an important point to make.

So, now at the point of IETF LC, the correct thing to happen is to let 
folks make their objections, point them to places in the prior 
conversation where the WG, the chairs, the ADs, and assorted other folks 
became convinced, and see if their arguments have some new subtlety that 
was missed earlier. And try to explain. Remember, these folks are 
already at a disadvantage; they've got an uphill climb to convince 
anyone else (especially, me and the rest of the IESG) that this 
long-considered conclusion is incorrect. IMO, that's the time to cut 
them as much slack as possible, because if they do have a serious 
objection hidden in among things that we've seen before, we *all* should 
want to hear it.

But that's not what's gone on. Some folks have simply dismissively said, 
"Go read the archive", without pointers. I found that 
less-than-collegial, and the more dismissive folks I dropped a private 
note asking them to cool it. The dismissiveness AFAICT simply encourages 
people to post more comments without looking at the previous 
conversation. But your note went above and beyond. The sarcasm was sharp 
and directed. It seemed intent on ridiculing. And coming from someone 
who is already on the side of the called consensus (the side that "has 
already won", though I dislike that formulation), directed to another 
senior member of the community with a great deal more experience in the 
DNS end of the world who has (perhaps unjustified or poorly-informed) 
worries that something was missed, I think it was pretty seriously 
ill-spirited and bullying. The *presumption* was that the person was 
"studiously ignorant", that he was being willfully blind of the prior 
conversation and refused to see the obvious. And the response has the 
side effect that anyone else who thinks they may see something that was 
missed had better back off lest they suffer similar attack.

Yes, coming to consensus on contentious issues is hard work. And now in 
the days of the IETF stovepiping, with cross area review not happening 
like it did in the past, contentious issues that cross areas and WGs are 
all the harder to get consensus around. And all I say is, "Tough." We 
have a Last Call process because we expect that not everyone can 
participate cross-area as much as we'd like, and we do want to do a 
final raking-over-the-coals to make sure nothing was missed. We need to 
figure out how to do that better, not use intimidation tactics that will 
cause the final review to not take place at all.

So, I think there's a significant difference between the time used 
(perhaps wasted) by people who are not up to speed and the "disrespect" 
that that implies, and the use of argument tactics by folks who have the 
presumption of having "won the argument". I'm much more willing to cut 
the former more slack.

---

That's all I really want to say on this topic. I won't begrudge you if 
you want to answer any of the above and defend yourself publicly, but 
I'll take any other comments I have to private email. I need to spend 
some time now going through the thread and make sure that all of the 
arguments being brought up *have* in fact been previously answered (a 
job made more difficult because folks were dismissive instead of 
providing pointers to early WG discussion where the arguments were 
answered) and summarize some conclusions. That way the people who think 
they still have objections have a chance to say, "No, Pete, you missed 
my point. There *is* a new argument hiding in there." And then I can 
make some judgments on that. That is, push the discussion to conclusion, 
not just shut it down.

pr

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 22 Aug 2013 10:39:55 -0400

> next protocol that comes along and needs (apex) RR data? And the one

There are two reasons, mail is a legacy application with lots of old cruft around it. 
New protocols on the other hand can start with clean slate, and the use of the protocol is
optional unlike email. 
With a new protocol you can tell someone "you can not use Vendor X as it does not support Y" 
and they will put up a system that works, for email there is installed base and enterprise policies to use
Vendor X then SPF RR can not be used. 

> higher-level strategy to support that goal.

I agree 

	Olafur

---

From: Scott Brim <[email-masked]>
Date: Thu, 22 Aug 2013 10:53:55 -0400

On Thu, Aug 22, 2013 at 10:22 AM, Pete Resnick <[email-masked]>wrote:

> Some folks have simply dismissively said, "Go read the archive", without
> pointers.

Pete, I like your position, but I believe "go read the archive" or the
equivalent will continue to be a standard response unless someone is
responsible for giving a more thorough response. Who do you think that
should be?

---

From: Thomas Narten <[email-masked]>
Date: Thu, 22 Aug 2013 11:01:04 -0400

> each other and deciding whether they want to wade into that pool.

It's not just new people watching and being turned off.  There are
plenty of old timers who get turned off and I doubt I'm alone in
thinking very carefully these days whether I want to wade into any
particular discussion.

Thomas

---

From: Pete Resnick <[email-masked]>
Date: Thu, 22 Aug 2013 10:02:20 -0500

OK, direct question; I'll take the (short) time to give a direct answer.

> responsible for giving a more thorough response. Who do you think that 

It would be a bummer if it is entirely left to the AD/consensus caller 
or the chair/shepherd, but unfortunately "the buck stops here", as they 
say. Eventually, it should be everyone's responsibility to help their 
colleagues. But obviously my rose-colored glasses are especially rosy 
today, other evidence to the contrary notwithstanding.

pr

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 22 Aug 2013 10:15:56 -0700

> protocols at the zone apexes instead of a structured DNS.

With or without SPF, we're long past the point where worrying about that is
worthwhile.  Try a TXT lookup for ut.edu or banctec.com, for example.

When I did one of the surveys for RFC6686, it recorded the TXT RRs returned
for various domain queries.  The top ten in terms of record counts returned
back then (most have been cleaned up now):

+-----------+----------------------+
| count(id) | domain               |
+-----------+----------------------+
|        43 | wncy.com             |
|        43 | b93radio.com         |
|        43 | wtaq.com             |
|        29 | dealdirectsendz.info |
|        23 | voamn.org            |
|        18 | ut.edu               |
|        15 | aaronline.com        |
|        10 | dwgsecurity.com      |
|         9 | emergogroup.com      |
|         9 | banctec.com          |
+-----------+----------------------+

The top three were loaded with "google-site-verification=<hash>" records.
ut.edu and banctec.com have a mix of things.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 22 Aug 2013 17:18:49 -0000

>next protocol that comes along and needs (apex) RR data? And the one

SPF is ten years old now.  It would be helpful if you could give us a
list of other protocols that have had a similar issue with a TXT
record at the apex during the past decade.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Aug 2013 15:23:02 -0400

> responsible for giving a more thorough response. Who do you think that

If you've had the most fleeting look at this:
https://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/

... then you'll know what *my* answer to that question is.  Happily,
this document has an excellent shepherd (see the Most Excellent(tm)
shepherd report:
https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/shepherdwriteup/
), who has been posting summaries and pointers throughout the
conversation.

Perhaps said shepherd could give even better pointers; if so, a quiet
message to him asking for specifics would surely be met with cheerful
diligence.

Barry

---

From: <[email-masked]>
Date: Fri, 23 Aug 2013 01:52:54 +0100

> I can't myself think of a good justification for sarcasm, (well, maybe [1]:-)

good sarcasm is like good protocol design - many can recognise it, some can appreciate it, few can truly understand its nuances, and even fewer can create it.

You're just not one of them.

Lloyd Wood
http://sat-net.com/L.Wood/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Aug 2013 20:12:49 -0700

Pete, et al,

On 8/22/2013 7:22 AM, Pete Resnick wrote:
> So, now at the point of IETF LC, the correct thing to happen is to
> let folks make their objections, point them to places in the prior
> conversation where the WG, the chairs, the ADs, and assorted other
> folks became convinced, and see if their arguments have some new
> subtlety that was missed earlier. And try to explain. Remember,
> these folks are already at a disadvantage; they've got an uphill
> climb to convince anyone else (especially, me and the rest of the
> IESG) that this long-considered conclusion is incorrect. IMO, that's
> the time to cut them as much slack as possible, because if they do
> have a serious objection hidden in among things that we've seen
> before, we *all* should want to hear it.
...
> So, now at the point of IETF LC, the correct thing to happen is to
> let folks make their objections, point them to places in the prior
> conversation where the WG, the chairs, the ADs, and assorted other
> folks became convinced, and see if their arguments have some new
> subtlety that was missed earlier. And try to explain.

That's certainly a kind and gentle view of the obligations for handling
LC comments.  Kind and gentle on the folks making the comments.  Not so
kind or gentle or useful on the folks who have been spending months (or
years) doing the work of developing the document.

Therefore, I'm going to posit that your model is, in fact, critically
flawed.  (And on review I see there's an apt pun in that wording...)

In pragmatic terms, the current operational model for a LC (and IESG)
review tends to enforce no rules or limits to what can be challenged or
suggested, while simultaneously expecting those who have been doing the
work to then be responsible for educating the commenter and defending
decisions in the document, at the level of re-arguing resolved issues.
Your admonition that "these folks are already at a disadvantage"
encourages this sense of obligation.

However this is direct contradiction to our published rules for Last Call:

    RFC 2418, Working Group Guidelines and Procedures
    Section 8, Review of documents

    "It is important to note
    that a Last-Call is intended as a brief, final check with the
    Internet community, to make sure that no important concerns have been
    missed or misunderstood. The Last-Call should not serve as a more
    general, in-depth review."

Note that last sentence.  It's the essential point, if we are to have
any real /respect/ for the extended effort already put into developing
the document.  It contrasts completely from the burden that is regularly
placed on such folk these days.

In other words, those making comments have obligations too, but that is
not being discussed here, except to make excuses for them.  And it is
the fundamental flaw with your line of thinking.

In practical terms, that thinking suggests that rather than treat it as
a joke, we take seriously and tolerate behavior matching the cliche "I
haven't read the spec, but I have some criticisms of your work."

Besides mostly being incredibly wasteful, to the point of abuse, your
model serves as its own disincentive for bringing work to the IETF; the
hassle factor is just too damn high and, worse, the outcome too damn
unpredictable.

For all that we tout the occasional bit of added insight -- and I'm
entirely in favor of those rare moments -- they are drowned out by the
more predictable and dominant demands to re-explore old topics or new
silly ones or to argue religious technical preferences.

> But that's not what's gone on. Some folks have simply dismissively
> said, "Go read the archive", without pointers.

Last Call is for catching oversights and errors.  It is not for
educating folk who chose not to track the working group. If someone
cares enough to press for specific choices, they need to show up when
the work is being done.  If they don't care that much, then I'm sorry
but "we discussed that" or "go read the archives" is in fact an entirely
sufficient and complete response.  That is, if the IETF has any real
respect for the work that was done developing the document.

[For completeness, I'll note that this is an issue where it makes sense
to handle Individual Submissions quite differently.  Here there is no
archive of IETF group work, and so it is reasonable to demand of the
authors a handling of Last Call comments that really does look more like
education and marketing. But not for working group documents.]

> The dismissiveness AFAICT simply encourages people to post more
> comments without looking at the previous conversation. But your note
> went above and beyond. The sarcasm was sharp and directed. It seemed
> intent on ridiculing.

That's quite a lot to lay onto my brief "very constructive" statement.
Which isn't to say you are wrong; although the intensity of your
reaction really goes considerably beyond the worth of such a single,
brief comment, particularly one lacking an explicitly ad hominem
component and especially given that it really was in response to a
strikingly inappropriate and unconstructive demand.

But let's look at the specifics of the current situation.

Comments during last call can come from folk who either have or lack
knowledge about the IETF and/or the document's topic.  The comments can
be exploratory, in the sense of seriously seeking improvement, or they
can be pushing the speaker's agenda, with no concern other than for
winning their point.  That last is typically marked by a lack of
responsiveness to points of substance, along with an effort to look for
any line of attack that might win.

In all cases, of course, starting with moderated and serious responses
is appropriate.  And, of course, one would always wish that that
continues.

However, by and large, all of the comments to the SPFbis effort have
been either naive, or represented an agenda, or both.

And in this case that prompted my sarcasm, we had a highly knowledgeable
critic refraining from serious discussion and, instead, pressing a very
old and sustained and counter-productive agenda about DNS RRs. And he
did it through several iterations.  In other words, it was a religious
effort, not a technical exploration, jumping around to find any line of
attack that would prevent deprecating a patently useless RR (and one, in
fact, that has been deemed to create an interoperability problem.)

My sarcasm was prompted by the degree of disrespect and silliness in
that final suggestion.  From a highly experienced IETF participant.

> And coming from someone who is already on the side of the called
> consensus (the side that "has already won", though I dislike that
> formulation)

You /should/ dislike it, because it entirely misses the style of attack
against the work that is quite common during LC.

And since it is by now easy to forget my earlier statement, I'll repeat
that I am entirely in favor of LC and the constructive comments that do
get made there.  I am not criticizing the construct of LC but rather the
unreasonable demands on document creators that result from LCs' current
lack of limits on critics.

LC should not be treated as a right of passage, to test the patience of
folks who have developed a document.

It should be exactly what RFC 2418 says it should be.

d/

---

From: <[email-masked]>
Date: Fri, 23 Aug 2013 04:21:55 +0100

> folks who have developed a document.

rite?

Lloyd Wood

---

From: Dave Cridland <[email-masked]>
Date: Fri, 23 Aug 2013 08:37:24 +0100

> > folks who have developed a document.

Right - right or rite?

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 23 Aug 2013 11:17:40 +0200

> record at the apex during the past decade.

I don't know of any (at least ones that are used in the global dns
namespace), and I would like to still not know of any in 2033.

SPF may be a lost cause, let's try and make that the only one.

Jelte

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Aug 2013 12:31:40 +0200

On Aug 22, 2013, at 21:23, Barry Leiba <[email-masked]> wrote:

> Most Excellent(tm)

(This may not have helped much in this case, but:)

Why is it that IETF last-calls do not contain a direct reference the shepherd writeup?
Shouldn't those be required first reading for anyone commenting?

Grüße, Carsten

PS.: The last-call does contain a direct reference to
http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ballot/
which is 404 at this point in the procedure.

---

From: "John Levine" <[email-masked]>
Date: 23 Aug 2013 14:34:02 -0000

>SPF may be a lost cause, let's try and make that the only one.

Since we agree that the issue you're worried about has not arisen even
once in the past decade, could you clarify what problem needs to be
solved here?

R's,
John

---

From: Scott Brim <[email-masked]>
Date: Fri, 23 Aug 2013 14:06:36 -0400

On Thu, Aug 22, 2013 at 11:12 PM, Dave Crocker <[email-masked]> wrote:

> the document.

Remember the discussion about how "last call" is more like the middle of a
document's evolution, and we should admit that in our process
documentation?  This is closely related.  If, in reality, people are
frustrated at the attempted rapid pace of last calls, then we should allow
for that.  We have time.  We don't have to be like the ones we all know who
sneer at anyone presuming to get in the way of their code going into
production.  Simple comments and questions -- your "educating everyone who
tracked the wrong group" -- can be dealt with easily through referral.
 Even substantial ones can be directed to specific discussion threads.
 Real issues can be considered.  It's only too late if we say it is, in our
processes, and if an issue is substantial, it should never be too late.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 23 Aug 2013 11:43:41 -0700

Hello,

This message has a Bcc to an IETF participant.

In my write-up for the Responsible Area Director I mentioned that:

   "There was an intermediate conclusion about the topic of whether the SPF
    protocol should use the SPF RRTYPE or the TXT resource record.  It was
    followed by an objection.  After discussion of the topic at the IETF 83
    SPFBIS WG session the conclusion reached was that the decision would be
    not to publish RRTYPE 99 and and not to query RRTYPE 99.  The WG
    consensus about the RRTYPE can be described as particularly rough.  The
    topic of obsoleting the SPF RRTYPE generated a lot of controversy near
    the end of the WGLC.  There were a very high number of messages about
    the topic on the SPFBIS mailing list and the DNSEXT mailing list as some
    DNSEXT WG participants were not aware of RFC 6686."

The WGLC announcement [1] for draft-ietf-spfbis-4408bis-14 was sent 
on April 9, 2013 and it was mentioned that the WGLC will close on 
April 24.  I posted my review as document shepherd on April 23 [2] 
and looked into the IANA Considerations Section of the draft as there 
is a question in the write-up about whether the IANA Considerations 
are clear and complete.  Something unusual occurred.  A very high 
number of messages were posted about on a thread about the DNS 
Parameters registry [3].  Most of the comments were submitted after 
the end of the WGLC.  On April 25, the Responsible Area Director [4] 
commented that:

   "This discussion should have happened at SPFBIS *chartering* time, as it is
    crystal clear from the charter that existing features currently 
in use in SPF
    are not going away. Indeed, the TXT record was specifically 
mentioned in the
    charter."

In another message he commented [5] that:

  "If you think SPFBIS was being superficial in its treatment of this topic
   and can identify an argument that was missed, fine."

The thread was left to run in case an argument was missed.  The 
SPFBIS WG Chairs [6] posted a message on April 30 about "the planned 
deprecation of the SPF RRTYPE and whether TXT is an appropriate thing 
to use and if it is whether the SPF use of it is ok".

There is the following text in the write-up:

  "Some WG participants have mentioned that they may express extreme
   discontent about the decision to obsolete the SPF RRTYPE during
   the Last Call."

That is a notification to the Responsible Area Director and the other 
members of the IESG about the matter.

I reviewed the discussion about the RRTYPE several times in doing the 
write-up and after that to determine whether the following is correct:

   "The WG consensus about the RRTYPE can be described as particularly rough."

I did not find any problem in the process followed to reach that 
conclusion.  I read the messages posted on the IETF mailing list [7]; 
there are around a 100 messages.  I didn't notice any messages about 
an issue with the above statement.

Regards,

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03497.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg03507.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg03681.html
7. http://www.ietf.org/mail-archive/web/ietf/current/msg81609.html

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Aug 2013 12:46:28 -0700

On 8/23/2013 11:06 AM, Scott Brim wrote:
> We don't have to be like the ones we all know who sneer at anyone
> presuming to get in the way of their code going into production.

Since this is such a fundamental point, I'm sending this reply to emphasize:

    The concern I expressed had nothing at all to do with this.

What prompted my note that in turn prompted Pete's was a form of 
counter-productive LC behavior that I consider to be abusive and since 
it was from a highly experienced participant, inexcusable.

Serious questions and suggestions from serious reviewers/critics are 
/essential/ to IETF quality assurance and I have as little patience for 
the sneering you describe as anyone else.

d/

---

From: Hector Santos <[email-masked]>
Date: Fri, 23 Aug 2013 16:23:24 -0400

> the sneering you describe as anyone else.

My particular concern is that you using this "abusive" argument 
increasingly against people leading to a next public suggestion to 
justify invoking IETF moderation, if necessary.

Once a well respected senior member as yourself speaks as such, people 
do listen and its extremely intimidating to constantly see this 
threatening form of excommunications and moderation against folks.  If 
one responds, then they are risk of getting labeled abusive, and hence 
moderation is invoked.

In my opinion, I don't see highly debated issues like the SPF typ99e 
issue all the time with last calls. At least I don't or I don't get 
involved with it if its not related to my work.  This rarity suggest 
that the IETF LC system still works and that we are simply 
experiencing a real divided technical infrastructure design issue that 
was highly predictable to be a conflict outside the working group. 
Pete suggested as much with fewer cross area reviews occurring within 
the IETF.  I agree that this is one of those diversity improvements 
areas.  Not enough cross area peer review before the WGLC and IETF LC 
takes place.  The goal is to minimizes these contentious engineering 
issues.

I have been involved with the SPF protocol before MARID, during MARID, 
an early adopter and also involved in the SPFBIS efforts.  It is my 
assessment the SPFBIS WG
did not receive adequate cross area reviews and DNS industry input 
*before* the removal decision was made, which was practically 
immediate and expected before the first draft was even written. 
Instead, the same "already discussed" arguments was used and the 
removal decision was implemented in the draft.

In my opinion, there was significant concerns about the removal within 
the WG and outside the WG, yet the decision was made to pull it anyway 
at the IETF meeting.  This immediately put the burden on everyone to 
reverse or at least get a better discussion going about keeping the 
migration path and also get a better handle of whats going on with the 
dearth in the supportive infrastructure for the handling of unknown RR 
types.

In my opinion, it would be better to seek the input from DNS vendors 
to see what the future is regarding new RR types and passthru handling 
of unknown types (RFC 3597). I request reaching out to folks in 
Microsoft DNS product management to determine what has fell through 
the cracks.  If there is continued lack of interest, then the SPF 
type99 removal is reasonable to me.

You seem to think that this was already done. I don't think so. 
Perhaps you believe that the infrastructure will never be ready to 
support new RR types.  If so, that is important to know.

--
HLS

---

From: S Moonesamy <[email-masked]>
Date: Fri, 23 Aug 2013 14:42:10 -0700

Hi Dave,

I read the messages on this thread.  I suggested to the participant 
to comment.  I am okay with the comments which were made.  I had an 
off-list exchange before the message that generated the other 
thread.  The exchange was not antagonistic.

Some people read "please read the archives" as a requirement.  That 
led to a misunderstanding.  During a Last Call someone has to figure 
out what the issues are and whether they have been addressed or 
not.  The misunderstandings do not make the work easier.

Regards,
S. Moonesamy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Aug 2013 19:09:53 -0400

On Fri, Aug 23, 2013 at 3:46 PM, Dave Crocker <[email-masked]> wrote:

> counter-productive LC behavior that I consider to be abusive and since it
> was from a highly experienced participant, inexcusable.
>
> /essential/ to IETF quality assurance and I have as little patience for the
> sneering you describe as anyone else.

I think you were out of line because the type of issues being raised are
precisely the type of issues that are appropriate to raise in IETF last
call, indeed are the reason for having an IETF wide last call in the first
place.

If I see a WG railroading a scheme that I think is botched architecturally
then of course IETF LC is the place to raise it. Adding in a requirement,
sure.

In this case the issues being raised are a repeat of the arguments made
from ten years ago and I don't have much sympathy for them given the way
the folk raising them behaved then and in particular their total lack of
concern for the deployment issues raised by the group.

But I don't criticize them on the process question, IETF LC is exactly the
place to raise this issue. It is one area kibitzing on the work of another.
That is an IETF layer issue for sure.

-- 
Website: http://hallambaker.com/

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 25 Aug 2013 21:27:03 +1000

I experienced rude respondings in IETF list and in  one WG list, I don't
beleive that it is culture of IETF participants, but it seems that some
people should understand to be polite and reasonable in such organisation
business. Finally, the rude responding is not controled by the chair of
thoes lists, therefore, thoes lists can be rude lists from time to time.

AB

On Thu, Aug 22, 2013 at 5:46 AM, Pete Resnick <[email-masked]>wrote:

>>> requirement and I don't think there is a good justification to pursue that
>>> line."
>>>
>>
> It is not your complaint about the imposition of new requirements that is
> problematic, or your point that it is not useful to continue that line of
> discussion. Talk about the utility of a comment all that you want. It is
> the sarcasm and the rudeness that I am saying is unreasonable. Especially
> coming from a senior member of the community, the only purpose it seems to
> serve is to bully others into not participating in the conversation. If you
> think that the conversation has gone on too long, you're perfectly within
> rights to ask the manager of the thread (in this case, myself or the
> chairs), in public if you like, to make a call and say that the issue is
> closed. But again, the tactics displayed above are not professional and not
> reasonable rhetorical mode.
>
> For the record, I entirely acknowledge that my note has an edge to it and
>> yes, of course alternate wording was possible.  However the thread is
>> attempting to reverse extensive and careful working group effort and to
>> ignore widely deployed and essential operational realities, including
>> published research data.
>>
>
> I appreciate your input that you believe that some or all of the objectors
> are ignoring operational realities. Perhaps they are. But the fact is that
> Last Call is a time for the community to take a last look at WG output. If
> senior members of the community (among which there are several in this
> thread) are suspicious of the output, it *is* important to make sure that
> their concerns are addressed. Maybe they simply don't have all of the
> information. But maybe the WG has missed something essential in all that
> careful work. Both have historically happened many times.
>
>> destabilizing consumption of IETF resources.  In fact an important problem
>> with the alternate wording, such as you offered, is that it implies a
>> possible utility in the thread that does not exist.
>>
>
> It is far more distracting and destabilizing for the IETF to come out of a
> Last Call with experienced members of the community suspicious that a bad
> result has occurred, especially if the tactic used to end the discussion
> was sarcasm to chase people away from the discussion. You are looking at
> only the little picture. The consensus might end up on the rough side, but
>  having the conversation has utility in and of itself.
>
> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
> >

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 26 Aug 2013 10:48:28 +0200

> once in the past decade, could you clarify what problem needs to be

prevented, not solved. I would like to prevent someone from having to
submit a draft specifying that in the case of TXT, the (name, class,
type)-tuple should be extended with the first X octets from the RDATA
fields, somewhere in the future, because client-side demuxing is getting
too buggy and it seems like a good idea to select specific records in
the DNS itself.

Jelte

---

From: "John R Levine" <[email-masked]>
Date: 26 Aug 2013 10:08:37 -0400

> too buggy and it seems like a good idea to select specific records in

Could you point to anyone, anywhere, who has ever said that the odd 
history of the SPF TXT record means that it is perfectly fine to do
something similar in the future?

On the other hand, please look at all of the stuff that people outside 
of the IETF do with apex TXT records, and try and say with a straight face 
that SPF as as much as 1% of the multiplexing problem.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 26 Aug 2013 16:43:57 +0200

> something similar in the future?

Three of the four points on the list that triggered my first message in
this particular thread were:

- no <this new rrtype> support in my provisioning system
- no <this new rrtype> support in my firewall
- no <this new rrtype> support in my DNS Library

Those aren't things that'll magically disappear, even with universal
deployment of 3597.

Some, and maybe all of these, might be generally solved if
draft-levine-dnsextlang takes off, though I have serious doubts about
the second, and some doubts about the first.

Until such time, I'd personally prefer to see some explicit notion that
the odd history of the SPF TXT record should not be seen as a precedent
and best practice, rather than hope that this is implicit.

> of the IETF do with apex TXT records, and try and say with a straight
> face that SPF as as much as 1% of the multiplexing problem.
> 

There may be a reason those are not standardized. And not just because
there are too many grumpy people here shouting 'get off my lawn'. Or at
least not all of them :)

Jelte

---

From: "John R Levine" <[email-masked]>
Date: 26 Aug 2013 10:49:01 -0400

Sorry if that last one came across as dismissive.

> and best practice, rather than hope that this is implicit.

I'd have thought that the debate here and elsewhere already documented 
that.  Since it's not specific to SPF, perhaps we could do a draft on 
"overloaded TXT considered harmful" to get it into the RFC record.

Regards,

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 26 Aug 2013 16:55:46 +0200

> "overloaded TXT considered harmful" to get it into the RFC record.

It certainly documents there are some persistent people walking around
the dns world ;)

That draft may not be a bad idea.

Jelte

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 26 Aug 2013 17:15:59 +0200

> That draft may not be a bad idea.

It has been pointed out to me that rfc5507 already exists. I'll shut up now.

Jelte

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Aug 2013 02:21:13 -0400

--On Monday, August 26, 2013 10:49 -0400 John R Levine
<[email-masked]> wrote:

>> Until such time, I'd personally prefer to see some explicit
>> notion that the odd history of the SPF TXT record should not
>> be seen as a precedent and best practice, rather than hope
>> that this is implicit.
> 
> I'd have thought that the debate here and elsewhere already
> documented that.  Since it's not specific to SPF, perhaps we
> could do a draft on "overloaded TXT considered harmful" to get
> it into the RFC record.

With the help of a few others, I've got a I-D in the pipe whose
function is to create an IANA registry of structured protocol
uses for TXT RR data and how to recognize them.  I hope it will
be posted later this week.  Its purpose is to lower the odds of
"overloaded" sliding into "different uses for forms that are not
easily distinguished".  Other than inspiration, its only
relationship to the current SPF discussion is that some
SPF-related information is a candidate for registration (whether
as an active use or as a deprecated one).

It already contains some text that warns that overloading TXT is
a bad idea but that, because it happens and has happened,
identifying those uses is appropriate.  Once it is posted, I/we
would appreciate any discussion that would lead to consensus
about just how strong that warning should be and how it should
be stated.

best,
   john

---

From: Pete Resnick <[email-masked]>
Date: Tue, 27 Aug 2013 15:33:54 -0500

I probably should have sent out this message over the weekend, but I was 
hoping I would complete a bigger message soon. Since I'm still working 
on that, a quick note to level set:

I have been reading all of the Last Call responses as they have come in. 
I am in the process of reviewing the comments and making a summary of 
the issues and responses. I have asked SM as document shepherd to do the 
same. (Being far more diligent than I, SM has completed his review 
already and is waiting on me.) We will be comparing notes and posting a 
summary of the issues and how they were addressed, along with whether we 
think they are resolved. That will give folks who disagree with my 
assessment one last chance to say, "Pete, you completely misunderstood 
what my objection / response was saying and you should re-evaluate your 
consensus determination on this issue." After that all shakes out, I'll 
make the final call on consensus.

An important thing to note is that I am seeing scant little I would call 
a "new argument" since late last week, so I would suggest that you are 
probably not adding to my understanding of the consensus by continuing 
to post. I'd like to think that everyone would be able to notice that 
things have gotten repetitive, both the folks who are repeating things 
as well as the folks who think they have to keep answering, but there 
does seem to be a bit of "getting the last word in" going on. Doing so 
isn't likely to add to my understanding or sway my opinion of the 
consensus (since I'm making a list of independent issues and their 
answers, not counting posts), but it does make it take longer for me to 
get through my review. So I'd recommend posting judiciously, at least 
until you see my summary.

Thanks,

pr

---

From: Dan Schlitt <[email-masked]>
Date: Thu, 29 Aug 2013 12:30:07 -0400

I did not participate in the original working group that developed SPF. 
However I had a number of long phone conversations with one of the folks 
who was active in the group. A good part of those conversations involved 
the use of the TXT record. I objected to overloading that RR. In 
response there was a bit of disparagement of namedroppers folks who 
joined in the discussions. In the end I was told that TXT worked and 
that was that.

I did join in the current working group and when the subject of the TXT 
and SPF records came up I commented that I believed it was inappropriate 
to overload the TXT record and that the SPF record was the correct way 
to go and a transition plan should be worked out. It became clear that 
there was a group that were determined to use the TXT record and get rid 
of the SPF record. So I didn't see much benefit in pushing my view in 
the WG.

As the manager of a modestly large network I found the TXT record as a 
useful tool in management of the network. Such a use was even suggested 
by other system managers. That was a time when the Internet was a 
friendlier place. Today I might do things differently and not make some 
of the TXT records visible on the public Internet. But they would still 
be useful for internal management.

The discussions in the working group made it clear that there were 
design problems with SPF. It would have benefited from a well focused 
problem statement and a related requirements statement. Most of the 
problems are internal to the framework.

It is a sender policy and there is no corresponding receiver policy 
framework. There were those who wished to add in things that essentially 
were a receiver policy.

The design feature that has a wider impact on the Internet is the use of 
the DNS. The working group was dominated by the internals of the 
framework and had little concern with broader questions. Internally the 
TXT record was their choice.

I believe that it is unwise to have a standards track protocol which 
overloads the TXT record. It is this last call which has a broader look 
at the proposed standard that is the place to make this judgment.

As far as the current use of the SPF RR is concerned I have the feeling 
that the members of the working group had a rather optimistic view of 
the actual use of the sender policy. It is not on the standards track. 
Having a standards track version should encourage more use of the 
framework. If the standard said use the SPF record that would increase 
its use. A transition plan which allowed the current installed base to 
continue on would allow a standard with out disruption.

It would be a shame to lose all the other work on the framework so, if 
the current version of the document can't for some reason be changed, it 
should be published as informational. It should be edited so that it 
describes the current use of the framework with suggestions for improved 
opperation.

I do think that the folks who were tasked with leading the working group 
should be given credit for the job that they did. It was not the easiest 
working group to deal with. There were time when I feared that it would 
drop into the disfunctional state as, for example usefor. They avoided 
that and got the work back on track.

/dan

-- 

Dan Schlitt
[email-masked]