Subject: consensus statement on record syntax and type

From: Andrew Newton <[email-masked]>
Date: Fri, 25 Jun 2004 14:41:26 -0400

Based on constructive working group discourse, the co-chairs of MARID 
observe the following:

1) There is consensus within the MARID working group for the use of SPF 
syntax over other encoding schemes.  While this consensus is not 
unanimous or overwhelming, it is rough consensus.  The working group's 
rough consensus on this issue derives from several considerations; 
among them is the belief that MARID's output should focus on the 
short-term needs of MTA authentication (consistent with the charter of 
the group), and that open-ended extensibility for email policy within a 
MARID record may lead to problems of interoperability.  The co-chairs 
also note that there were no practical or obvious examples of 
extensions to a MARID record that could not be represented by the SPF 
syntax.

2) The consensus for the use of SPF syntax does not preclude continuing 
work on the PRD and SUBMITTER concepts.  The co-chairs note that there 
has been very constructive discourse on these concepts and that the 
working group should continue to refine these ideas for use with 
MARID's output.

3) Despite the working group's consensus for the use of SPF syntax, the 
co-chairs find that there is no consensus for declaring the SPF 
specification finished.  The co-chairs observe that there are still 
many unanswered questions regarding extensibility in SPF, specifically 
how and if SPF modifiers should refer to other policy frameworks and 
the need to more clearly define default behavior and safe-guard against 
side-effects caused by unknown SPF modifiers and mechanisms.  The 
co-chairs note that such semantics of extensibility are not specific to 
any type of syntax or encoding.

4) Finally, the co-chairs observe that the MARID working group has a 
very strong consensus, though not unanimous, on the reuse of TXT 
records for initial deployment and on a reuse of TXT syntax in the long 
term.  The consensus is centered around the belief of most participants 
that a MARID record in TXT form will generally be small enough as to 
not require DNS over TCP.  The co-chairs find that the working group 
has not come to consensus on the use of a record prefix vs TXT records 
at the zone apex and has not reached consensus on how to address 
domains with wildcard MX records.

It should be noted that none of the above findings preclude the future 
re-chartering of MARID to define a new DNS record type and/or a new 
encoding for that record.

To meet the tight deadline this working group as set for itself to have 
a candidate for a proposed standard by the end of August, 2004, we 
propose the following schedule of activities:

   - Due 2004-07-02: Decide if CSV is complimentary, parts to be 
incorporated, or dropped.
   - Due 2004-07-08: Decide how MARID output will work with already 
deployed SPF records (v=spf2?).
   - Due 2004-07-31: Refine SPF syntax and extensibility semantics.
   - Due 2004-07-31: Fold in PRD and SUBMITTER.

-andy & mtr

---

From: John Leslie <[email-masked]>
Date: Fri, 25 Jun 2004 16:42:14 -0400

NB Speaking only for myself -- not any other CSV authors:

> extensions to a MARID record that could not be represented by the SPF 

   If by this, the chairs mean to stop attempting to include an XML
syntax, I personally agree that it appears to be the only way to
complete our work for RFC2822 headers on schedule.

   If the chairs mean something else, I must beg that they be more
explicit what they mean by "SPF syntax".

> working group should continue to refine these ideas for use with 

   I quite agree.

> specification finished...

   I quite agree.

> records...

   I agree that TXT records are essential to SPF. (CSV, of course,
could function without them.)

>   - Due 2004-07-02: Decide if CSV is complementary, parts to be 

   A most reasonable date: I think we should look for initial agreement
during the Monday jabber; plus a few days on the list to see if there's
any wild objection.

   But personally, I think the middle ground is unwise: it should be
edited into shape separately, or dropped. Any parts which the working
group would prefer not to include can be removed (or perhaps footnoted
to refer to different documents). I feel confident that -- with the
single exception of whether to query for SRV or query for the SPF
TXT record -- consensus could be reached on schedule. I have no such
confidence for merging the two together.

> deployed SPF records (v=spf2?).

   Seems reasonable: I have no strong opinion.

>   - Due 2004-07-31: Fold in PRD and SUBMITTER.

   These seem dubious. Recall that that's during the ID blackout period
for IETF 60. I think it unwise to do these without externally visible
documents. Inevitably (IMHO) this will lead to last-minute changes and
confusion during our IETF60 meeting.

   (BTW, how stable does the schedule seem: are we pretty well set for
Wednesday, August 4, at 9:00 a.m. and 3:00 p.m.?)

--
John Leslie <[email-masked]>

---

From: Marshall Rose <[email-masked]>
Date: Fri, 25 Jun 2004 13:52:52 -0700

> complete our work for RFC2822 headers on schedule.

that is a fair reading.

> during the Monday jabber; plus a few days on the list to see if there's

a good plan.

> confusion during our IETF60 meeting.

right you are. we will revise the dates.

> Wednesday, August 4, at 9:00 a.m. and 3:00 p.m.?)

that is the schedule that i am planning on.

/mtr

---

From: Andrew Newton <[email-masked]>
Date: Fri, 25 Jun 2004 17:09:49 -0400

Adjusting for IETF 60 cut-off dates:

   - Due 2004-07-02: Decide if CSV is complimentary, parts to be 
incorporated, or dropped.
   - Due 2004-07-08: Decide how MARID output will work with already 
deployed SPF records (v=spf2?).
   - Due 2004-07-18: Refine SPF syntax and extensibility semantics.
   - Due 2004-07-18: Fold in PRD and SUBMITTER.

-andy

---

From: Roy Badami <[email-masked]>
Date: Sat, 26 Jun 2004 00:28:55 +0100

Sorry, this has been sort of raised by other posters in this thread,
but I'm still slightly confused.  You say:

    Andrew> 1) There is consensus within the MARID working group for
    Andrew> the use of SPF syntax over other encoding schemes.

Does this rule out of scope further work on CSV/CSA's use of SRV
records (which are certainly not SPF syntax)?

    Andrew>    - Due 2004-07-02: Decide if CSV is complimentary, parts
    Andrew> to be incorporated, or dropped. 

What this means depends very much on the answer to my previous
question.

Is it an option (given rough concensus) to independently advance the
draft-marid-core/submitter document set and the draft-marid-csv-*
document set to PS, or is their a requirement to produce a single
standards track specification?

	  -roy

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Jun 2004 07:35:55 +0800

Andrew,

AN>    - Due 2004-07-02: Decide if CSV is complimentary, parts to be 
AN> incorporated, or dropped.

Since this line from your note did not have any lead-in text, I would
appreciate some clarification on this.

SPF validates individual messages, using author/sender authority for
the latest-hop client MTA.

CSV also validates the client MTA, but for the entire session, and
independent of the particular message traffic.

So I am not seeing how to incorporate one into the other.  The fact
that you listed the alternative of merging suggests that you have
something substantive in mind.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 25 Jun 2004 21:31:44 -0400

> records (which are certainly not SPF syntax)?

The question put before the working group dealt with the extensibility 
of syntax, with the group being concerned that too much extensibility 
could potentially harm interoperability.  SRV syntax is probably not as 
extensible as SPF syntax.  More to the point, the working group did not 
discuss SRV extensibility in the context of SPF and XML.  So the intent 
is not to rule out CSV/CSA.

> standards track specification?

It is expected that MARID produce a cohesive, sensible, and 
interoperable specification that meets our charter objectives.  That 
specification may be contained in a single document or among many.  
CSV's place in that specification is for the working group to decide.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 25 Jun 2004 21:35:03 -0400

> something substantive in mind.

We simply listed the possibilities.  The prospect of taking some of the 
concepts from CSV and placing them in SPF has already been discussed on 
the list, though not in detail.

-andy

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 25 Jun 2004 23:36:18 -0400

----- Original Message ----- 
From: "Andrew Newton" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: "Marshall Rose" <[email-masked]>; "Ted Hardie"
<[email-masked]>; "IETF MARID WG" <[email-masked]>
Sent: Friday, June 25, 2004 9:35 PM
Subject: Re: consensus statement on record syntax and type

> the list, though not in detail.

Currently our 2821 based Transaction Management System (TMS) has the
following specific order of testing:

- FILTER, Admin defined White/Black Accept/Reject Rules
- RBL, List of Reputation Lookup Sites.
- LMAP (SPF, CEP, DMP)
- CBV (Call Back Verifier)

MARID will replace LMAP which means SPF stays, DMP (currently undocumented)
will be deprecated and CEP pulled and replaced with the future MARID (SPF2)

Still fresh at reading CSV (combining it with DNA/CSA), from what I see,
the only new concept introduced is the "Accreditation" logic and also
possibly (need to read more) solving some level of the possible forwarding
issues in the LMAP methods.  So as a new product feature customer offering,
I can see it fit as follows:

- FILTER, Admin defined White/Black Accept/Reject Rules
- CSV, Accreditation and CSA Lookup per spec
- RBL, List of Reputation Lookup Sites.
- MARID (SPF, SPF2, CSV-2)
- CBV (Call Back Verifier)

I should note RBL currently represents 80% of the total rejection, the best
method in the industry hence why it is so popular. So it would be hard to
replace/remove it as a TMS feature.

In any case,  I have to read more, but one of the remaining issues would be
the forwarding issue with SPF/MARID.  So possible concepts discussed in CSV
regarding Address-based Authentication may apply in validating the
"routed/forwarded" message (CSV-2 in MARID).

Also,  on a related note,  one part that will be a challenge for implemented
or support is the idea of a remote SPF domain record/policy defining the
sources used for reputation or accreditation lookups.   If it is added it
will be done as an option (off).   So I would be initially oppose to a SPF2
functional specification enforcing such a directive/mechanism.

[X] SPF support
     [_] Honor Reputation Lookup
     [?] Honor Accreditation Lookup

The main reason is because the sysop will want to apply such look ups across
the board, not based on what a specific MARID/SPF domain policy says.  The
odds are very high, the above options would not be made available since RBL
is already in place.

If anything, Accreditation may be provided and ON by default if its done in
a way that allows the sysop to decide what trusted sites to lookup.

But overall,  I would prefer to continue to have both separate from MARID.
This means I also see CVS having a partial role in a MARID based Transaction
Management System.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com