Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 25 Aug 2005 10:14:39 -0700

Julian,

not speaking for anyone but myself.....

one matter of principle:

are you of the opinion that the IESG should try to police which experiments 
get run on the Internet by refusing to publish RFCs documenting 
possibly-conflicting experments?

Both of these documents were published at the request of their authors. I 
know that ways in which they could cause conflict were pointed out to the 
authors, and that both authors upheld their requests to publish.

If you ask the IESG to assert the power to police this kind of experiment, 
please make sure you will be happy with the result if they agree with 
you.....

                  Harald

--On 25. august 2005 00:45 +0200 Julian Mehnle <[email-masked]> wrote:

> I believe that draft-lyon-senderid-core-01 conflicts in a significant
> aspect with draft-schlitt-spf-classic-02, on which the former depends, and
> which has also been approved by the IESG to be published as an
> Experimental RFC.[2]  The conflicting part of the Sender-ID specification
> disrespects the substantial history the SPF specification has outside the
> IETF. Through its decision, the IESG also ignores SPF's deployed base.[3]
> And even if the IESG intends to run both of the specifications as an
> experiment before deciding any further on how to proceed with them, the
> publication of conflicting specifications is bound to disrupt these
> experiments.

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 25 Aug 2005 14:08:39 -0400

> possibly-conflicting experments?

It depends on the form of the conflict.

I believe that the IESG has the duty to ensure that concurrent
experiments either use experimental codepoints in non-conflicting ways,
or else require them to use distinct codepoints; to fail to do this
creates the risk that any experimental results will be
muddled/contaminated.

In this case, the two experiments interpret the same codepoints in the
DNS in subtly different ways.

A mail-sending domain indicates that it is participating by publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment.  This renders any
claimed results of either experiment suspect.

							- Bill

---

From: Ned Freed <[email-masked]>
Date: Thu, 25 Aug 2005 11:26:07 -0700 (PDT)

> creates the risk that any experimental results will be

Bingo. There is, after all, an "experiment" in "experimental". A conflict that
stands a good chance of making it imposisble to get useful results from the
experiment is something that clearly needs to be resolved prior to publication.

There's even some support for this in RFC 2026. Section 4.2.1 talks about
experimental publication being subject to "verification that there has been
adequate coordination with the standards process".

Now, this is phrased in terms of conflicts with standards, not conflicts
between experiments, likely because the case of conflicting experiments
was never envisioned.

> claimed results of either experiment suspect.

RIght again.

In any case, I support this appeal to the extent that I believe the conflicts
need to be resolved prior to publication. I take no position on the means
by which the conflict is resolved as long as a resolution is reached.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Aug 2005 12:08:46 -0700

> by which the conflict is resolved as long as a resolution is reached.

All of this raises the obvious question of the purpose in having the IESG 
"approve" Experimental status.  If the approval does not pertain to basic 
technical issues, such as known conflicts with other specifications, it is 
difficult to imagine any benefit in the approval process.

On the other hand, the fact of IESG "approval" for these two specifications has 
been richly touted as progress on the standards track.  Given how sensitive the 
IETF community is about misrepresentation of its actions and labels, we should 
make sure that the value-add of those actions is clear and real.

-- 
 
   d/

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 25 Aug 2005 15:06:21 -0400

> by which the conflict is resolved as long as a resolution is reached.

And I wholeheartedly agree with this.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 25 Aug 2005 21:25:29 +0200

On Thu, Aug 25, 2005 at 10:14:39AM -0700,
 Harald Tveit Alvestrand <[email-masked]> wrote 
 a message of 41 lines which said:

> are you of the opinion that the IESG should try to police which
> experiments get run on the Internet by refusing to publish RFCs
> documenting possibly-conflicting experments?

If the IESG were to refuse to publish the Sender-ID document as it is,
it would not "police" everything: anyone can still do what he wants on
the Internet.

The only thing than the IETF can do is to "bless" or not the document,
saying in essence "it is interesting and worth more
experimentation". Not blessing it does not mean actively using lethal
force against those who still want to try it.

So, cool down, nobody asked the IESG to police or to censor or to
forbid, just to NOT bless a bad idea (reusing SPF records in an
unattended way).

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 25 Aug 2005 15:58:48 -0400

> forbid, just to NOT bless a bad idea (reusing SPF records in an

I agree with this sentiment.  It's not like the RFC series is the only
place that protocol specifications for such experiments can be
published, and with Google and the Wayback Archive, the search and
persistence problems are solved as well.  So we should only publish if
we think we can add some kind of value beyond that which any yahoo who
owns a web server can do with publishing some random specification on
the web.  

Making sure that experiments don't collide with one another seems like
a very basic starting point.  This is especially important in this
particular case given how contentious the debate over proposals in
this problem space have been in the past.

						- Ted

---

From: Douglas Otis <[email-masked]>
Date: Thu, 25 Aug 2005 13:21:09 -0700

> by which the conflict is resolved as long as a resolution is reached.

As with any conflict, there are two parties involved.  In this case,  
the SPF group has essentially ignored potential conflicts by  
neglecting to include support for a subsequent version of the DNS  
record.  This newer record explicitly expresses the intended scope.   
At the MAAWG meeting in Dusseldorf, Julian suggested SPF developers  
would only consider use of the newer DNS record version provided  
Sender-ID abdicated use of the initial version of the record.  Sender- 
ID supports both versions.  An appeal was made for the SPF group to  
consider supporting the newer version of the record as a solution for  
avoiding this conflict.  This suggested use of the record is part of  
interim advice on the MAAWG website.  It would appear this appeal  
reflects a decisions to remain intransigent.

http://www.maawg.org/about/whitepapers/spf_sendID/

A condition that Sender-ID abdicate the use of the scope-less version  
of the record is puzzling, as once the newer record is also adopted  
by SPF, the claimed conflict is resolved.  Meng Wong, an author of  
both drafts, explained the conflict in his white paper by indicating  
the SPF draft was for historical purposes and suggested Sender-ID  
embraced both semantics.  Sender-ID's use of the initial version of  
the DNS record will create problems should the publisher of the  
record intend the semantics to exclude Sender-ID.  The methods  
suggested by the Sender-ID draft to circumvent their semantics could  
negatively impact the publisher.

This conflict is not accidental or without a simple solution, but  
rather based upon a desire to withdraw Sender-ID semantics in a manor  
that negatively impacts the Sender-ID effort.  I am _not_ a proponent  
of Sender-ID.  While the merging of semantics was initially  
considered acceptable by the MARID WG, the desire to now exclude the  
Sender-ID semantics is primarily due to subsequent licensing  
notifications.  At that time so long ago, the technical solution to  
allow the record publisher to formally indicate their desired  
semantics was to change the version of the record that provided the  
requisite scoping parameters.

Rather than adopting this solution, the SPF group insists anyone that  
published the initial version of this record only intended to support  
SPF and not Sender-ID.  This would be a difficult conclusion  
following any number of gatherings where email administrators have  
subsequently and repeatedly been provided information that indicated  
this initial record version supports both, and that the subsequent  
record versions can be used to isolate the scope of the record.

While this conflict should be resolved, without evidence that Sender- 
ID has fallen out of favor, which the stance by the SPF group  
prohibits, the obvious solution would likely be for the SPF group to  
finally adopt the newer record version.

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 Aug 2005 08:47:17 -0400

> claimed results of either experiment suspect.

If this is the source of the conflict, then BOTH experiments should  
not use the v=spf1 records.

-andy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 26 Aug 2005 15:15:13 +0200

On Fri, Aug 26, 2005 at 08:47:17AM -0400,
 Andrew Newton <[email-masked]> wrote 

> not use the v=spf1 records.

It is an absolutely incredible request since SPF uses these records
since its beginning (a long time before Sender-ID existed) and since
there is (unlike SenderID) actual deployment, which can not be called
back.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 Aug 2005 09:53:38 -0400

> there is (unlike SenderID) actual deployment, which can not be called

Is this appeal about avoiding further conflict or is it about  
challenging past differences?

-andy

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 08:59:29 -0500

> not use the v=spf1 records.

The stated goal of draft-schlitt-spf-classic is to document SPF,
basically as it was before the IETF got involved.  Yes, the IETF is
calling it an experiment, which I don't agree with.  It is documenting
an existing, well established, protocol.

Are you saying that the IETF shouldn't publish an RFC that documents
SPF?

Yes, the IETF, via that MARID WG, tried to create a new protocol
called SenderID that was based on both SPF and CallerID.  I can see
that newly created protocol being called an experiement, but I don't
see why the IETF should go out of its way to bless a new protocol that
is incompatible with an existing one.

Is this the normal process of the IETF to create conflicting
standards, just because one standard was developed outside the IETF?

-wayne

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 Aug 2005 10:45:17 -0400

> Are you saying that the IETF shouldn't publish an RFC that documents

I stated that the SPF and Sender ID experiments should not use the  
v=spf1 records to avoid conflict.  I did not state that the IETF  
should not publish an Experimental RFC about SPF.

But since you brought this up: if you (the author of the document) do  
not consider this to be an experiment, then perhaps the IETF should  
not publish SPF as an Experimental RFC.

-andy

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 09:53:13 -0500

> not publish SPF as an Experimental RFC.

I asked for the IESG to not consider the SPF I-D to be experiemental.
It was turned down.  According to Ted, *none* of the IESG members
expressed interest in changing the status from Experiemental.

So far, no one has appealed that decision, and there are only a few
days left to do so.  Like the appeal on the re-use of SPFv1 records, I
don't think it would be a productive use of my time to write an appeal
on the experimental status, and thus I won't do it.

-wayne

---

From: Graham Murray <[email-masked]>
Date: Fri, 26 Aug 2005 15:56:21 +0100

> not publish SPF as an Experimental RFC.

That would be a good idea. As there is already more than one implementation of
the SPF protocol, should it not be possible to 'skip' the experimental phase
and go straight to the start of the standards track?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 Aug 2005 10:00:52 -0700

> on the experimental status, and thus I won't do it.

If the goal of the SPF Classic draft was intended to capture a point  
in time pre-dating semantic extensions related to RFC-2822 defined  
content, then perhaps the draft should be on an historic track.  ; )

SPF Classic has not achieved the goal of capturing a pristine version  
of pre-MARID semantics.  With some semantic changes introduced by the  
SPF Classic draft itself, these potential semantic conflicts, as well  
as those introduced by Sender-ID, have not been addressed.  Prudent  
accommodations were made within the Sender-ID draft however.  The SPF  
Classic draft has not found higher ground in this regard.  Expecting  
any standards group to retroactively arbitrate semantics restrictions  
for a previously enigmatic DNS record would be disruptive.   An  
unfrozen SPF Classic draft adding provisions for a scoped version of  
the DNS record would allow some percentage of publishers the means to  
indicate their intended semantics when so needed.  The conflict issue  
being described seems specifically based upon a design flaw within  
SPF Classic.

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 Aug 2005 14:13:15 -0400

> and go straight to the start of the standards track?

It should not be possible.  Please consult RFC 2026 and RFC 2418.

-andy

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Aug 2005 14:10:55 -0400

>>>>> "wayne" == wayne  <[email-masked]> writes:

    wayne> In <[email-masked]> Andrew
    wayne> Newton <[email-masked]> writes:
    >> But since you brought this up: if you (the author of the
    >> document) do not consider this to be an experiment, then
    >> perhaps the IETF should not publish SPF as an Experimental RFC.

    wayne> I asked for the IESG to not consider the SPF I-D to be
    wayne> experiemental.  It was turned down.  According to Ted,
    wayne> *none* of the IESG members expressed interest in changing
    wayne> the status from Experiemental.

As a point of fact, I only saw requests from you to publish as a
proposed standard or some other standards track document rather than
experimental.

Of course I would not have seen private communication between you and
Ted.

however if you do not consider SPF an experiment, standards track is
not the only status to consider.

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 13:38:10 -0500

> not the only status to consider.

Yes, good point.  I really hadn't considered other status.  I guess
Informational might also be appropriate.

I still think Standard Track is most appropriate, but again, I don't
think it would be a productive use of time to try and change the
current Experimental designation.

-wayne

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 14:56:05 -0500

> content, then perhaps the draft should be on an historic track.  ; )

RFC2026 says:

4.2.4  Historic

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level. [...]

This wouldn't apply because there are no newer specifications for SPF,
nor is it obsolete.

> SPF Classic draft itself, [...]

There isn't a "pristine" version of SPF, there are several different
draft specifications and a whole bunch of implementation.  There are,
unfortunately, conflicts between these.  The SPF-classic I-D attempts
to document the most coherent intersection of these.

There have been *very* few semantic changes that were introduced in
the current spf-classic I-D.  Almost everything was either part of one
of the earlier, pre-MARID specs, or part of one of the earlier,
pre-MARID implementations.

Of hand, I can think of only the following three "new" items in the
spf-classic I-D:

1) The introduction of a new DNS RR type.  Personally, I would be
   happy to get rid of this, but there are a lot of folks, especially
   in the IETF who think this is very important.

2) The SPF result code "unknown" was renamed "PermError" and the
   result code "Error" was renamed "TempError".  This is truely a
   holdover from MARID.  I think the names are much better, but yeah,
   it is a change.

3) The result of a redirect modifier that has, as its target, a domain
   name that has no SPF records has been changed from returning a
   result code of "None" to "PermError".  Actually, I'm not certain
   what the result code in the earlier draft should be because it was
   a corner case that was not addressed.

There were quite a few places where we either removed things like
Receiver Policy, or changed things from "MUST" to either "SHOULD" or
"MAY".  We did this when we found that existing implemenations did not
obey the "MUST" and in practice, a "SHOULD" or "MAY" would be more
productive as the standard.

In some cases we also had to tighten the requirements in order to make
things more portable.  For example, there were a couple of SPF
implementations (pre-MARID) that enforced processing limits needed to
prevent SPF from being used as an (effective) DoS vector.  Since these
implementations were deployed, domain owners need to make sure their
records conform to these limits in order to make sure their records
would be processed correctly everywhere.

Finally, we found some cases where features were simply not used in
practice.  For example, the ABNF for the Received-SPF: header in the
older specs could allow for the creation of headers that did not
conform to what RFC2822 wants.  In practice, the Received-SPF: headers
generated by actual implementations conformed to RFC2822, and so the
ABNF could be tightened up.

It took a great deal of work to find as many SPF implementations as we
could, figure out how the actually worked, find as many SPF records as
we could, figure out which features are used, and to resolve as many
conflicts as we could in the best, most coherent, way we could.

While I'm sure that the SPF-classic I-D can be improved, I think it
has done a good job of meeting the goal of documenting SPF, as it
existed pre-MARID.

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 Aug 2005 17:38:52 -0700

> This wouldn't apply because there are no newer specifications for SPF,

My apologies for this poor attempt at humor.  With the authors  
insisting the draft only documents prior art that is now in conflict,  
it becomes difficult to consider this draft as experimental.

With an experimental draft, one would expect modifications addressing  
issues as they arise.  This record conflict has been a problem for a  
long time.  If this draft is really only for historical purposes,  
perhaps SPF Classic should dropped.  Sender-ID would then need to  
introduce a different draft defining the syntax related to the DNS  
records.

> to document the most coherent intersection of these.

The reduction in processing limitations seemed substantial with  
understandable reasons.  There was a change that including HELO in  
parallel with the MAIL FROM rather than when the MAIL FROM was NULL.   
A number of other changes have since been struck.  Problems created  
when modifying record processing or what identifies are applied could  
be ameliorated through use of record versioning.  This would ensure  
the server understood how to utilize the record being offered.

While I agree with the view that PRA semantics may create problems  
when applied against the initial record version, the Sender-ID draft  
permits the use of a scoped version of the record which makes it  
clear what semantics are expected.  Accommodating this identical  
provision within SPF would have resolved the potential Sender-ID  
conflict and also would have been a means to acknowledge adherence to  
newer processing limits and HELO checking, for example.

Sender-ID does not define the syntax of the record, but instead  
depends upon the SPF draft for these definitions.  It would appear  
the Sender-ID draft is willing to follow the syntax defined by the  
SPF draft.  The major difference is that Sender-ID accommodates both  
versions of the record, whereas, despite the reasons, SPF has  
deliberately elected not to support the scoped version.

This difference relates to a prefix of "v=spf1 ..." versus "spf2.0/ 
<scope>,<scope> ..."

> has done a good job of meeting the goal of documenting SPF, as it

I understand this is the justification used for the draft then  
ignoring the scoping problem. : (

Solutions:

a) Sender-ID avoids applying any RFC-2822 content semantics to the  
initial DNS record version.

b) SPF incorporates support for a scoped version of the DNS record.

c) a & b

d) Drop SPF Classic and create a separate syntax document.

The number of domains publishing the initial version of the DNS  
records negatively affected is likely less than those that benefit.   
By itself, SPF is not without its own significant issues.  Even  
Hotmail publishes just the initial record version, but depends upon  
the PRA.  It would seem that while the SPF effort claims  
guardianship, they have been guilty of versioning abuses as well.   
Although option b is not perfect, it is good enough.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Aug 2005 03:53:43 +0200

Andrew Newton wrote:

> I stated that the SPF and Sender ID experiments should not
> use the v=spf1 records to avoid conflict.

Yes, you are a prominent part of this "embrace and extend"
strategy also known as "steal or destroy".

> if you (the author of the document) do not consider this to
> be an experiment, then perhaps the IETF should not publish
> SPF as an Experimental RFC.

Perhaps the IETF should choose its leadership more carefully.

It didn't work, this trick to get rid of the critical "NOT
RECOMMENDED" in draft-schlitt by a note to the RfC editor.

It didn't work, this trick to close MARID when it was clear
that abusing v=spf1 for PRA is a non-starter.

Hopefully it also won't work by the infamous "SHOULD abuse
v=spf1" in senderid-core-01.

The persons listed on...
http://www.ietf.org/u/ietfchair/dea-directorate.html
as well as all "no objections" on http://tinyurl.com/ayaun
will have a hard time to redeem themselves in my eyes, and
so far only one managed this.

When Keith said here that all this was only an error, not
intentional, I fear that isn't the case for some of these
persons.
                         No paseran

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Aug 2005 05:02:57 +0200

> Informational might also be appropriate.

Not from my POV, I wanted this beast under IETF control.

That's why I pushed for an RfC, and later after reading
the "fine print" 2026 for standards track.

"Informational" is something the authors could update 
whenever it pleases them.  There was no SPF Council
last year, "we" (TINW) trusted that the IETF and MARID
would get it right.

Okay, that failed spectacularly forcing "us" to create
the SPF Council.  I still prefer standards track, not
some obscure one and a half standards SDO "SPF".  The
role model for "us" might be XMPP (not Phil's idea W3C,
that's megalomaniac).

> I still think Standard Track is most appropriate

ACK.  Now if the IESG thinks that something with less
than one million participants covering roughly about 80%
of AOL's inbound mails is an "experiment", then that's
their choice, and we'll remind them of their own choice
for each and every wannabe-PS with a smaller deployment.

> I don't think it would be a productive use of time to
> try and change the current Experimental designation.

ACK.  Better get a proper PS later, with interoperability
reports, relevant "lessons learned", etc. - too late for
DKIM, but still useful for other / later efforts trying
to do wild and wonderful things with DNS.  Bye, Frank

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 22:23:27 -0500

In <[email-masked]> Douglas Otis <[email-masked]> writes:

> understandable reasons.

The reduced process limits has existed dating back to Feb 23, 2004 in
the libspf-alt implementation.  It was picked up later (still
pre-MARID) by at least one other SPF implementation.

>                          There was a change that including HELO in  

Independent HELO checking was argued for since the summer of 2003.
The Spamassassin development version was doing HELO checking in the
Dec 2003 or Jan 2004, I'm not sure which.  The change in the spec
dates back to May 16 2004.  While MARID was going on at that point, it
was still before the MARID WG had adopted any drafts.

In reality, this is an incredibly minor change because almost all
MTAs send email with a null MAIL FROM every once and a while, so the
HELO domain would be checked at least some of the time.  Having it be
checked all the time makes very little practical difference.

> A number of other changes have since been struck.

Yes, there were a HUGE number of incompatible changes made during the
MARID process and, in hind sight, starting with the MARID drafts and
trying to make it compatible was probably a mistake.  However, we did
try to eliminate as many changes as we could find.

>                                                    Problems created  
> be ameliorated through use of record versioning.  

Maybe, but the implementations that did the processing limits were
deployed in early 2004, so unless you have a time machine, we are
pretty much stuck with them now.

> While I agree with the view that PRA semantics may create problems  

s/may/will/

> clear what semantics are expected.

Our goal in writing the spf-classic draft was to document what is and
was, not to create something new.  The job of creating something new
was given by Ted Hardie to the MARID authors.

>                                     Accommodating this identical  

The SenderID drafts have never contained the HELO identity.  This
makes it not fully backwards compatible with SPF-classic.  The
SenderID drafts are not under our control, so we can't fix it.

-wayne

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Aug 2005 06:10:16 +0200

Stephane Bortzmeyer wrote:

> It is an absolutely incredible request since SPF uses these
> records since its beginning (a long time before Sender-ID
> existed) and since there is (unlike SenderID) actual
> deployment, which can not be called back.

SPF is also older than Caller-ID, a patented XML-over-DNS idea.

                       JFTR, Frank

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 27 Aug 2005 01:08:44 -0400

> Not from my POV, I wanted this beast under IETF control.

  Why?  The concerns you expressed in your previous message about the
IETF leadership and methods were serious.

  How do you believe you can move forward, given your concerns?

  Alan DeKok.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Aug 2005 13:17:45 +0200

> Why?

Because Meng and the SPF community as it was before MARID
produced at least three ideas how to change the spec. per
hour, and that made me very nervous.

With a reason, Meng manouvered himself in a very awkward
position, after all he's the co-author of both drafts in
the subject.  He claims that it's sitting on a fence, but
actually it's barbed wire.

> The concerns you expressed in your previous message about
> the IETF leadership and methods were serious.

Some of them, not all of them.  It's a test, interesting
for anybody volunteering time for the IETF if it turns
out to be "directorated" by the commercial interests of
some big players.

> How do you believe you can move forward, given your

Julian proposed a simple remedy, it could be even shorter,
delete four letters in chapter 3.4 of senderid-core.  Bye.

---

From: "Thomas Gal" <[email-masked]>
Date: Sat, 27 Aug 2005 11:21:01 -0700

Well clearly IANA won't accept 2 differing registrations that
overlap on this matter. Certainly it is the IETF/IESG/IAB's job to rectify
that incongruity? If the two proposals cannot come to a resolution regarding
the differing interpretations of the DNS records then clearly they must be
required to use different/non-overlapping syntax. For the IESG to say
"Change your records to v=senderid or something that doesn't conflict with
this other previously printed document and large number of installations or
we can't really distribute this document" makes perfect sense. Certainly,
though everyone may not agree on the solution, we agrees that publishing
both unchanged seems silly(using common sense not procedure for a moment)?
Certainly not publishing either seems to make more sense than publishing
both. If these documents are distributed elsewhere and conflicting that's
one thing (beccause they'll be read no matter which forum they are
distributed through), but if we distribute them without anything close to
rough consensus on the acceptability of this conflict between documents
(which I don't think we have) then what has anyone accomplished? Have we
followed the spirit of our rules (rough consensus and working code) if it's
clear that it's NOT POSSIBLE to have working code because the proposals are
mutually exclusive?
	I'm not going to try to harp on IPR, or the end of the IETF, or
industry blah blah regarding this decision, but this decision seems
important, so iresspective of all the other things involved, I think it's
important that a good decision is made on this matter. No consensus and non
possiblity for working code.
	I would be interested in polling to know how people feel on these 2
matters:

(1) This draft should not be published by the IETF due, at LEAST due to the
fundamental conflict with SPF, which makes running code impossible. Even a
split on this issue will indicate lack of consensus for publishing this
document.

(2) The document should either:
	a. be published elsewhere if consistency (i.e. no changes) is
paramount
	b. the conflict should be resolved (most useful, least likely based
on history)
	c. the syntax should be changed by the RFC editor (or author) which
will essentially also resolve the conflict, make the documents consistent,
and not sacrafice IETF principles.

-Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Frank Ellermann
Sent: Friday, August 26, 2005 9:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in
conflictwith referenced draft-schlitt-spf-classic-02
MARID<[email-masked]>

Stephane Bortzmeyer wrote:

> since its beginning (a long time before Sender-ID
> existed) and since there is (unlike SenderID) actual deployment, which 
> can not be called back.

                       JFTR, Frank

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Aug 2005 06:13:41 +0200

Thomas Gal wrote:

> overlap on this matter. Certainly it is the IETF/IESG/IAB's
> job to rectify that incongruity?

There's IMHO no IANA problem, using the same DNS RR type 99 is
possible / desirable.

> For the IESG to say "Change your records to v=senderid or
> something that doesn't conflict with this other previously
> printed document and large number of installations or we
> can't really distribute this document" makes perfect sense.

Yes, that's in fact all that has to be done, and what the
appeal proposes, spf2.0 may interpret v=spf1 as spf2.0/mfrom,
but not as spf2.0/mfrom,pra   The proposed remedy is "KISS".

> I'm not going to try to harp on IPR, or the end of the IETF,

IANAL and not very much interested in the former - excl. the
day when I tried to read and understand the IPR boilerplate
in the first CID draft, because it was obvious right from the
day when CID was published that something very odd happens.

IIRC the plan for MARID was to use several ASRG LMAP proposals
as input (SPF, CSV, MTAMARK among others).  After CID was added
and the ASRG cochair resigned (ASRG almost dead since this day)
the situation deteriorated.

So back to your statement above:  The senderid-appeal is the
continuation of the "shuffle those deck chairs" thread here.

                             Bye, Frank