ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM charter update proposal

2009-10-18 18:15:41
(shaking head)

No need to do that, nor say that.

Is there a reason why my suggestions are off the table?

Namely, codify the existing specification and specifically adding
simple text that imply:

   Forwarders SHOULD|MUST NOT break ADSP domain messages.

or

   Forwarders  SHOULD|MUST take into account ADSP Domains
   before stripping and resigning or signing ADSP domain messages.

Why is this not a legitimate consideration for rechartering - Codify
the existing RFC specifications? Can you explain why it would not be
thus not even include it in your suggestions?

Oversight.  It's certainly a valid way to proceed, and it should be
included in the discussion.

You'll need to clarify where you think this text should go.  Note that
RFC 5617 does not "update" RFC 4871, using "update" in the RFC sense.
That means that no one implementing DKIM base is told to go read ADSP
and get more implementation information there.  They can do ADSP or
not, as they please.

That also means that if we add your text to ADSP, it won't help
implementations that do DKIM base only.

If we add your text to DKIM base, it must go through another cycle at
Proposed Standard, and can't be moved to Draft Standard yet.

Now, that's a perfectly good thing for the working group to decide to
do, so it's absolutely in scope for discussion.  I'm pointing this out
so it's clear what the process will be.

I even suggested a far fetch possibility to "deprecate" RFC 5617, if
thats all even IETF procedurally possible, to help remove this
on-going dispute.  I can understand this would be extreme, but there
was a agreement but another person with this.

This is basically John Levine's suggestion, in his branch-off thread
("How about that..."):

Re the ADSP data collection, I'd like to add a third option to move it
to Historic if ADSP turns out to be as useful as I think, but I
realize this is unlikely to be a popular suggestion.

"Historic" is the proper way to take a protocol out of current use.
There's also a stronger mechanism, if we should decide that it was
SUCH a bad idea that we really wanted to tell people, "NOOOOO!  DON'T
USE IT!": we could make an "ADSP Considered Harmful" RFC that
officially updates 5617.

I personally think it's way too early to consider any of this now,
which is why the ADSP step in the proposed charter starts with data
collection and analysis.

But I will change my working version of the proposal to make it clear
that we have flexibility in what to do after the analysis is done:

 * Collect data on the deployment and interoperability of the
   Author Domain Signing Practices protocol (RFC 5617), and
   determine if/when it's ready to advance on the standards track.
   Take action as appropriate -- update it at Proposed Standard,
   advance it to Draft Standard, move it to Historic, or some other
   action that the working group decides.

How's that?

Barry

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html