Maybe the IETF Won't Publish SPF and Sender-ID as Experimental RFCs Af ter All
John Levine writes over on CircleID: [snip] Yesterday, the IESG, the group that approves RFCs for publication received an appeal from Julian Mehnle to not to publish the Sender-ID spec as an experimental RFC due to technical defects. IESG members' responses were sympathetic to his concerns, so I'd say that a Sender-ID RFC has hit a roadblock. The problem is simple: Although Sender-ID defines a new record type, called SPF 2.0, it also says that in the absence of a 2.0 record, it uses the older SPF1 record. Since SPF and Sender-ID can use the same records, if you publish an SPF record, you can't tell whether people are using it for SPF or Sender-ID. [snip] http://www.circleid.com/article/1178_0_1_0_C/ - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
In article <20050825.183907.23402.149667@webmail10.lax.untd.com> you write:
John Levine writes over on CircleID:
Actually I wrote it in my own blog at http://weblog.taugh.com which CircleID mirrors with permission. If you want to comment, put them in my blog so people will see it. R's, John
On Fri, 26 Aug 2005, Fergie (Paul Ferguson) wrote:
John Levine writes over on CircleID:
[snip]
Some corrections to what is said in John's article: 1. The appeal is against publication of SID draft (3 SID drafts, although only one is actually mentioned in appeal they go together) as experimental RFC(s) in current form. This does not imply that SPF draft would not be published by itself as article's title suggests (although it maybe delayed if there is another attempt to reconcile the differences). In article text John does not say that SPF draft would not be published because of this appeal, so I'm unsure why such a title... 2. The appeal is made to IETF Chair Brian Carpenter. According to IETF system he can choose to have appeal decided on by IESG or can choose to decide on it himself (in which case his decision can still be appealed to IESG). So far he has not said if IESG as a whole will consider the appeal. In either case, saying that IESG received this appeal is probably not quite correct (they were CCed however). 3. During MARID itself it was decided that new record version would be used (SPF2.0 prefix), which is opposite to what John says in the article about there being decision as part of MARID to reuse existing set of SPF records. 4. Nobody knows how many records had been published exclusively for SID, but its probably lot less then for SPF. But I don't think maintaining records is such a big deal (rather having to decide what goes into initial record is a lot more of a problem) and it probably would not be the reason why SPF2 SID records would not published if separation happens. 5. As far as last two paragraphs in the article, first of all appeal is being made after people already asked if MS is willing to make a change and they said no. And as far as solution to this that lets "Microsoft save face", it probably can involve using positive results of SPF1 records for SID but not negative results unless its SPF2 record (which it not say that everyone at SPF "camp" would support it, but it is probably better then now). But I'd not be surprised if instead MS chooses to disregard IESG and IETF and proceed with SID even if its not approved for RFC, nor would I be surprised if IESG is afraid to say no to MS even when it knows this is bad engineering... -- William Leibzon Elan Networks william@elan.net
upon skimming the following...
1. The appeal is against publication of SID draft (3 SID drafts, ... ... 2. The appeal is made to IETF Chair Brian Carpenter. ... ... 3. During MARID itself it was decided that new record version would ... ... 4. Nobody knows how many records had been published exclusively for SID... ... 5. As far as last two paragraphs in the article, first of all appeal is being made after people already asked if MS is willing to ...
...i've determined that the spammers have no cause to worry that the IETF is going to affect their businesses at all. in fact they're probably laughing their asses off watching all this idiocy. apparently, one way to stop spam would be to require spammers to live by the official ietf motto, "rough consensus and running code", or by the unofficial ietf motto, "let ``the best'' be the enemy of ``good enough''." -- Paul Vixie
participants (4)
-
Fergie (Paul Ferguson) -
John Levine -
Paul Vixie -
william(at)elan.net