Subject: [ietf-dkim] New issue: fate of ssp-reqs draft...

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Oct 2006 21:47:26 +0100

This is something that I think we never decided, but now that
we're nearing closure for the open issues on the document we
should figure out its future.

Should the ssp-reqs draft:

(a) become an RFC of its own, as soon as we can do that, or,
(b) be incorporated into the eventual SSP protocol RFC or,
(c) just be allowed expire once we're done with it, or,
(d) finish it but only send it to the AD at the same time as
     the SSP protocol draft?
Or, perhaps even, (e), something else?

The only reason to not choose (a) is probably that its a bit more
work and I guess means an additional IETF last call which could
mean additional delay, so I'd be marginally in favour of (d) I
think.

Thanks,
Stephen.

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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Oct 2006 17:24:50 -0400

> mean additional delay, so I'd be marginally in favour of (d) I

OTOH, if we get the requirements thorugh an IETF last call, then I'd expect 
that to ease the passage of the eventual SSP RFC through last call so it 
might be a net gain in time/work to the final product.

Scott K

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Oct 2006 15:01:54 -0700

>Or, perhaps even, (e), something else?

There is not good guidance on that in the IETF. (b) seem best because 
it gives the reader just one place to look instead of two.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Oct 2006 14:01:05 -0700

> (d) finish it but only send it to the AD at the same time as

The ssp-reqs are abstract without a clearly defined underlying  
mechanism other than DNS in some fashion.  There are some general  
goals such as "to allow an administrator to publish various  
statements about their email accountability practices [that  
recipients] take that into account when it receives an unsigned piece  
of email."

There have been no considerations regarding more essential goals of  
reducing disruptive message blocking, ensuring safe message  
annotations, dealing with abusive message replay, or administrating  
email-address/signing domain relationships.  This draft instead  
offers only general guidelines where the broader scope of essential  
requirements are yet to be determined.  As it stands now, option 'c'  
seems like the best choice.

-Doug