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