Julian Mehnle wrote:
I'm usually too trigger-happy with regard to taking
responsibility for things. ;-)
If you're happy with it it's fine, and Meng is apparently
happy with being on the road. Editing the SPF Web pages
from a cell-phone is kind of "sub-optimal" though. <beg>
I'm unsure if it has a chance of making it into
spf-classic-01.
Definitely not "into" as in "add a chapter 6.3 to the SPF
standard". I've now started calling the (unknown) 01-pre
"SPF standard". From our POV (SPF-community represented
by its Council) it's a standard.
From the IESG's POV it's an experiment as proposed by the
authors (actually that was Ted's idea IIRC). They (IESG)
had the right to change the RfC category to a "proposed
standard", but didn't use it.
I'm still desperately trying to find out why there is no
"Last Call", Wayne asked this on the rfc822 mailing list.
And why there can be two conflicting experiments at the
same time.
So far I found out, that it's possible and even normal to
submit experimental RfCs directly to the RfC-editor. Who
would of course ask the IESG for their comments. IETF WGs
would use the procedure for proposed standards with their
experiments. [BCP 9 chapter 4.2.3]
But SPF is no IETF WG, therefore SPF took the right exits
after "AD Evaluation", not the left exit "Last Call".
Let's assume that it's somewhere in limbo below the state
"IESG evaluation". They didn't say "do not publish", they
also didn't say "Approved", and they didn't say "Defer". It
is in the generic "AD-Followup" substate of whereever it is.
It entered this state via "Point raised - writeup needed" (?)
I'm not sure why, maybe the "Discuss" ballots did this. OTOH
it had the required 2/3 "No objection", 6 of 9 are 2/3.
But 5 of 9 for Sender-ID are not 2/3, and Sender-ID is also
in the "AD-Followup" state. This state diagram assumes that I
find, read, and understand all relevant RfCs, and of course I
haven't done this.
It's unclear (from the state GIF) how SPF can leave this state.
<https://datatracker.ietf.org/public/states_table.cgi>
And I still don't know what "sent to dea-dir" means, and who
this is. Is it related to the state "External Party" ? From
there it would go back to "AD Followup", directly or indirectly
via "Revised ID Needed".
Maybe a new 01-draft could help the unknown "dea dir" entity to
decide this, if it addresses the "Point raised" issues, still
assuming that these points are the three "Discuss" ballots.
After some time like say four weeks, if nothing happens at the
"dea-dir" front, the 01-draft could be submitted directly to
the RfC editor. He'd then ask the IESG, the IESG would see
that they already discussed this, or would they vote again ?
They can do lots of things, but after the first ballot a "do
not publish" is unlikely. They could add an IESG note. They
could reconsider the category and say "proposed standard".
They can't move it to an IETF WG, because they closed this WG.
Whatever they do, they should check their legal insurace about
potentially lost mails by conflicting "experiments", if they
intend to approve the publication of both SPF and Sender-ID
core as is. Jim and Meng should also do this, it's a tricky
case if you intentionally **** the owners of 740,000 domains,
some of them _are_ lawyers.
Bye, Frank