RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02 MARID<ietf-mxcomp@imc.org>

	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: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
Frank Ellermann
Sent: Friday, August 26, 2005 9:10 PM
To: ietf@ietf.org
Cc: ietf-mxcomp@imc.org
Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in
conflictwith referenced draft-schlitt-spf-classic-02
MARID<ietf-mxcomp@imc.org>

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

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf