Hi Russ,
The DKIM WG has completed its work [1] on the threats
draft [2], which is intended to be progressed to become
an informational RFC.
I've attached what I think is required for PROTO
reasons for this draft.
As I'm shepherd, I guess questions/queries/whatever
should be directed to me.
Cheers,
Stephen.
[1] http://mipassoc.org/pipermail/ietf-dkim/2006q1/002947.html
[2] http://www.ietf.org/internet-drafts/draft-ietf-dkim-threats-02.txt
1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?
Yes. Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> is shepherd.
1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?
Yes, the review was fine and we have no concerns other than
the obvious one that you can never really complete a
threat analysis.
During the WG last call we maintained an issues list, which
is in the dkim queue on https://rt.psg.com/ All issues were
closed at the Dallas IETF.
1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?
No concerns.
1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.
No concerns.
1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?
Very solid consensus from the WG as a whole, with a very few
exceptions.
1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.
1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.
Yes.
The ID nits tool notes the use of the DNS domain
anytown.ny.us instead of the more common example.org
but this is justified since the example needed has to
have some meaningful hierarchy and this is clearer than
foo.example.org in this case.
1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.
This is fine since there are only informative references. There
are references to other WG documents that are not yet complete
so this document will stay in the rfc editor's queue or else
can have be progressed referencing these I-Ds.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html