--On 24 February 2010 07:30:27 +0100 Eliot Lear <[email protected]> wrote:
> Typically, an interoperability survey is required to go to draft. > Considering that you may wish to reverse the order a bit. If that's the case (being new, I don't know whether it is or not), then should the wording be modified to make the interoperability survey a higher priority than item 1? That is: the dependencies should be done first, or at least made explicit in the charter. > Eliot > > On 2/23/10 10:36 PM, Murray S. Kucherawy wrote: >> OK, dates: >> >>> -----Original Message----- >>> From: [email protected] [mailto:ietf-dkim- >>> [email protected]] On Behalf Of Barry Leiba >>> Sent: Friday, February 19, 2010 11:32 AM >>> To: IETF DKIM WG >>> Subject: [ietf-dkim] Proposed new charter >>> >>> [...] >>> +++ New Work +++ >>> The working group is now ready to switch its focus to refining and >>> advancing the DKIM protocols. The current deliverables for the >>> DKIM working group are these: >>> >>> 1. Advance the base DKIM protocol (RFC 4871) to Draft Standard. >>> This is the first priority for the working group. >> Unfortunately I don't have any background doing this kind of work, so >> I'm forced to guess. But what about the July IETF as a "done-by" date? >> Is that a crazy idea? >> >>> 2. Collect data on the deployment, interoperability, and >>> effectiveness of the base DKIM protocol, with consideration >>> toward updating the working group's informational documents. >> July IETF. >> >>> 3. Collect data on the deployment, interoperability, and >>> effectiveness of the Author Domain Signing Practices protocol >>> (RFC 5617), and determine if/when it's ready to advance on the >>> standards track. Update it at Proposed Standard, advance it to >>> Draft Standard, deprecate it, or determine another disposition, >>> as appropriate. >> November IETF. >> >>> 4. Taking into account the data collected in (2) and (3), update >>> the overview and deployment/operations documents. These are >>> considered living documents, and should be updated periodically, >>> as we have more real-world experience. >> February 2011 IETF. >> >>> 5. Consider issues related to mailing lists, beyond what is >>> already documented. This includes considerations for mailing >>> list software that supports or intends to support DKIM, as well >>> as considerations for DKIM/ADSP deployment in the presence of >>> mailing lists that do not have such support. Include >>> recommendations in the informational documents, or produce a >>> new informational document about mailing-list considerations. >> I think this can be done in parallel, so November IETF. >> >> >> _______________________________________________ >> NOTE WELL: This list operates according to >> http://mipassoc.org/dkim/ietf-list-rules.html >> > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
