Subject: consensus call on MUST/SHOULD language for TXT records

From: Andrew Newton <[email-masked]>
Date: Fri, 3 Sep 2004 17:33:48 -0400

The debate over the MUST/SHOULD/MAY language with regard to compliance 
and publication of TXT and SPF2 record types does not seem to be 
getting the attention of the full working group.

Despite lack of agreement on the outcome, there is agreement on the 
stated positions.  In the words of Olafur:
1) Specify everyone to be compliant at all times.
2) Specify clearly full complaint state and tolerate non-compliant 
state during phase-in.

Position 1 is predicated on the notion that a future RFC will deprecate 
the (use of the) TXT record in favor of the SPF2 record.  Position 2 
demands that the TXT record be discouraged from use in the current 
-protocol document.

Rather than wordsmithing the actual MUST/SHOULD/MAY language directly 
(and endlessly), we ask the participants state their preference on 
these positions.

-your co-chairs

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 03 Sep 2004 18:19:20 -0400

Andrew Newton wrote:
> and publication of TXT and SPF2 record types does not seem to be getting 
> the attention of the full working group.
> 
> 2) Specify clearly full complaint state and tolerate non-compliant state 
> during phase-in.
> 
> (and endlessly), we ask the participants state their preference on these 
> positions.
> 

I am not sure how #1 differs from #2? Are you suggesting that if we 
adopt position #1, someone not having SPF RR records would be ignored?

Yakov

---

From: Daniel Quinlan <[email-masked]>
Date: 03 Sep 2004 15:21:11 -0700

> demands that the TXT record be discouraged from use in the current 

I think Position 3 needs to be mentioned:

3) Remove SPF2 record and specify the use of TXT going forward.

and Position 4:

4) Schedule the deprecation of TXT now, not later.

Option 3 is so much superior to 1 and 2 from my perspective (MTA and
spam filter software) that will be doing many DNS queries, that it's
barely worth prioritizing 1 vs. 2.

That being said, in order of preference:

  3 >> 4 >> 2 >> 1

Put another way:

 - Doubling query volume is bad; inability to schedule in advance the
   end of querying both records is bad.
 - TXT is easier to deploy than SPF2 and no significant technical
   argument favors SPF2 over TXT aside from puritanism.

Daniel 

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 18:28:57 -0400

> 2) Specify clearly full complaint state and tolerate non-compliant

I would favor position 2.  I think the recommended document should
describe where we want to be in the long run, whether or not we can
get there quickly.  While I strongly suspect Sender ID will undergo
future revisions anyway, why intentionally adopt a standard that will
have to be superseded?

David

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 3 Sep 2004 15:59:13 -0700 (PDT)

> (and endlessly), we ask the participants state their preference on 

I take middle position:

 1.5) Specify everyone to be compliant at all times and tolerate
      non-compliance as a matter of fact (current reality) for a given 
      period of time (next 4 years say).

P.S. Did I hear right that next version of Windows is coming early 2006?
     I assume Microsoft people present here are going to work on 
     making sure that it will support "unknown" and yet undefined dns data
     types as well as preferably support new SPF data type directly...

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: [email-masked] (Wietse Venema)
Date: Fri, 3 Sep 2004 19:14:29 -0400 (EDT)

> future revisions anyway, why intentionally adopt a standard that will

I second this. The document should bless the usage of TXT records
during the initial deployment phase. It does not need to define
the time schedule for the txt -> spf transition.

	Wietse

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 03 Sep 2004 19:25:28 -0400

>       period of time (next 4 years say).

"be conservative in what you do, be liberal in what you accept from 
others" (John Postel, RFC 793)

Yakov

---

From: Daniel Senie <[email-masked]>
Date: Fri, 03 Sep 2004 19:41:17 -0400

>       period of time (next 4 years say).

Please be sure ALL such timeout dates are listed in drafts as a period of 
time from when the draft is published as an RFC. Dates should NEVER be set 
in a draft as pointing to a specific date on the calendar, nor from the 
date a draft appears in the drafts repository.

We've run into issues before where "deadlines" were set and then acted upon 
before drafts were approved. Please let's not ever do that again.

---

From: "Mark C. Langston" <[email-masked]>
Date: Fri, 3 Sep 2004 16:33:44 -0700

> 2) Specify clearly full complaint state and tolerate non-compliant 

I'm more comfortable with option 2, as it provides time for transition
and experimentation.

-- 
Mark C. Langston            GOSSiP Project          Sr. Unix SysAdmin
[email-masked]   http://sufficiently-advanced.net    [email-masked]
Systems & Network Admin      Distributed               SETI Institute
http://bitshift.org       E-mail Reputation       http://www.seti.org

---

From: Max Kanat-Alexander <[email-masked]>
Date: Fri, 03 Sep 2004 16:39:43 -0700

> 3) Remove SPF2 record and specify the use of TXT going forward.

	I agree.

	Barring that this solution (#3) is adopted, I believe that the
specification should require full compliance from the start. There are
(relatively) very few Sender ID implementations now, and there will be
many in the future. Requiring compliance now means a hope for 99%
interoperation, where as making compliance optional means a fight that
we're putting in the future when we *do* desire compliance.

	"MUST" means something very significant to developers and managers,
whereas making compliance optional means "Let's make it work in some
hacked way, even in our brand-new implementation, because we're under
time pressure to implement this feature that our customers want."

	-Max
-- 
Maxwell Kanat-Alexander
2nd Level Tech Support Engineer, USA
Kerio Technologies, Inc.
2041 Mission College Blvd. Suite 100
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
Web: http://www.kerio.com/support.html

---

From: Andrew Newton <[email-masked]>
Date: Fri, 3 Sep 2004 20:36:21 -0400

> adopt position #1, someone not having SPF RR records would be ignored?

My interpretation of the thread is "might be ignored".

-andy

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 23:43:22 -0400

I vote for position 1, future RFC should deprecate TXT record AFTER a SPF RR is approved and
implemented in DNS servers.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Andrew Newton
> Sent: Friday, September 03, 2004 5:34 PM
> To: IETF MARID WG
> Subject: consensus call on MUST/SHOULD language for TXT records
>
>
>

---

From: Graham Murray <[email-masked]>
Date: Sat, 04 Sep 2004 05:53:02 +0100

> (and endlessly), we ask the participants state their preference on 

I think we should require full compliance from the start. Having taken
that stance, I would question the need for having 2 RR types. It is
acknowledged (in the current documents) that the use of TXT is a
transitional, but if we require everyone to publish SPF2 (or whatver
name is used) RR then I do not think we need to publish or check TXT
records. I would also support the alternative given by Daniel
Quinlan's response of dropping SFP RR and using TXT as this would lead
to less deployment problems than using a new RR - though I understand
and appreciate the arguments for having a new RR.

---

From: <[email-masked]>
Date: Sat, 4 Sep 2004 09:10:51 -0400

> My interpretation of the thread is "might be ignored".

I did not infer that implication myself.

And after careful consideration I am going to have to change my vote to (2), I cannot accept
condoning of ignoring published SPF records (regardless of RR type).

Sorry for any confusion.

Terry Fielder

> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, September 03, 2004 11:43 PM
> To: 'Andrew Newton'; 'IETF MARID WG'
> Subject: RE: consensus call on MUST/SHOULD language for TXT records
>
>
>

---

From: Roy Badami <[email-masked]>
Date: Sat, 4 Sep 2004 18:33:55 +0100

>>>>> "Andrew" == Andrew Newton <[email-masked]> writes:

    Andrew> 1) Specify everyone to be compliant at all times.
    Andrew> 2) Specify clearly full complaint state and tolerate
    Andrew> non-compliant state during phase-in.

As long as support for SPF2 records is mandatory for compliance on
both the publishing and checking side, I'm neutral as to what the
documents should say about use of TXT records as an altertive.  The
discussion of the TXT record could even be relegated to an informative
annexe.

People will make a pragmatic decision to publish and check for TXT
records as long as the pragmatic need to do so remains.  I see no
pressing need to mandate that pragmatism (though I see ow harm in
doing so if people want to).

      -roy

---

From: Mark Lentczner <[email-masked]>
Date: Sat, 4 Sep 2004 12:45:52 -0700

> 2) Specify clearly full complaint state and tolerate non-compliant 

My preference is for position 2.

I am also strongly against other options with explicit phase-in periods 
and sunset-dates.  As has been eloquently argued by Doug Crocker, such 
language in RFCs has a bad track record of working out, and so is best 
dispensed with.

Options which drop the new SPF2 RR type altogether are not likely to 
sit well with the rest of the IETF community, specifically the DNS-EXT 
folks.  The will reasonably argue that DNS has a well designed 
extension mechanism in the allocation of RR types, and it should be 
used, rather than overloading the TXT type.

Options which drop the TXT RR type are not practical as there are some 
significant barriers to using a new RR type in some software 
environments.

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 04 Sep 2004 21:47:25 -0400

Mark Lentczner wrote:

> Options which drop the new SPF2 RR type altogether are not likely to sit 
> well with the rest of the IETF community, specifically the DNS-EXT 
> folks.  The will reasonably argue that DNS has a well designed extension 
> mechanism in the allocation of RR types, and it should be used, rather 
> than overloading the TXT type.
> 
> significant barriers to using a new RR type in some software environments.
> 

Even within option two, we can specify that the RR type be looked at 
first, and the TXT second, if the RR is not found. This would clearly 
show that the RR type is prefered over TXT, but TXT is tolerated.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 04 Sep 2004 21:39:53 -0400

> My interpretation of the thread is "might be ignored".

Then I support #2 simply because I don't see how position #1 will be 
practical.

Yakov

---

From: "Michael R. Brumm" <[email-masked]>
Date: Sat, 4 Sep 2004 23:25:04 -0600

> 2) Specify clearly full complaint state and tolerate non-compliant 

I vote for #2.

Michael R. Brumm

---

From: Dave Crocker <[email-masked]>
Date: Sun, 5 Sep 2004 15:24:48 +0800

Andrew,

AN> 1) Specify everyone to be compliant at all times.
AN> 2) Specify clearly full complaint state and tolerate non-compliant
AN> state during phase-in.

 The concept of "phase-in" for Internet services -- especially ones
 that modify mission-critical, established services -- is measure in
 5-10 year increments.

 For the purposes of IETF standards specification and -- even more
 importantly -- for operations planning, this is the same as saying
 "forever".

 So, the accurate semantics of the choices are:

 1) Specify everyone to be compliant at all times
 2) Specify clearly full compliant state, but tolerate non-compliance
 forever

 The second choice does, of course, lead the a small question: why
 bother with the concept of compliance?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: wayne <[email-masked]>
Date: Mon, 06 Sep 2004 01:55:50 -0500

> 2) Specify clearly full complaint state and tolerate non-compliant

I know the chairs asked to not discuss the IPR issue any more, but the
SenderID license seems to rule out option 2.  According to section
1.2, a "Licensed Implementation" must be complaint with all required
portions of the SenderID.

While the SenderID license only directly references marid-pra and
marid-core, the marid-core I-D has a normative reference to the
marid-protocol I-D and section 3 of marid-core requires you to use the
check_host function.

So, if marid-protocol says that check_host MUST query the SPF RR and
an implementation doesn't, then it is not confromant and the
implementation does not qualify to use the SenderID license.  If you
are in a situation such as Jim Lyon described at the iterim meeting
where you are in a pure Microsoft network, the Windows API doesn't
even have the ability to query for new RR types, you are kind of out
of luck.  As Jim described it, you can't even code up raw UDP packets
because they won't make it out of the network.

The problems of the license requiring conformance was brought up by
Dan Quinlan back in June, if I recall correctly.  This is just one
example of such a problem.

So, if we are planning on supporting SenderID, it appears that we MUST
allow everyone to always be conformant at all times.  This means that
we MUST NOT require implementations to query SPF RRs.

-wayne

---

From: <[email-masked]>
Date: Mon, 6 Sep 2004 13:35:05 -0400

On Mon, 06 Sep 2004 01:55:50 -0500, wayne <[email-masked]> wrote:
>...

The standard can be written in such a way that senders MUST publish
SPF records and MAY publish TXT records, while receivers MUST check
SPF records and MAY check TXT records.

Only the receiving MTA is covered by the patent license.  Compliant
implementations will have to check SPF records.  If the recursive DNS
server an implementation talks to is broken, that probably doesn't
mean the MTA implementation is non-conformant.

But it would be kind of amusing if Microsoft sued everyone with a
broken DNS server.  (I know they are always looking for new ways to
get people to upgrade...)

David

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 06 Sep 2004 14:16:07 -0400

> SPF records and MAY check TXT records.

One way to doing is to specify that RR records are checked first, and 
TXT records checked second.

Yakov

---

From: Ryan Ordway <[email-masked]>
Date: Tue, 07 Sep 2004 14:46:07 -0700

> 2) Specify clearly full complaint state and tolerate non-compliant 

	My vote is for 1. I believe allowing non-compliance
is an invitation for non-compliance.

-- 
HELO, my name is root... you have SIGKILLed my father... prepare to vi!