[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
4. The phrase "minimal change" just doesn't belong in a
charter for a charter like this - its use just offers a very
handy stick for anyone who wants to beat up on the charter. I
believe that the real requirement isn't so much minimal
change, but that all changes need to take into account that
there is already deployed technology for this purpose and we
should not make the (required) migration any more difficult
than needs to be the case. Its implicit in any WG charter (or
ought be) that gratuitous changes aren't what we do - trying
to hammer it home in this way is just counter productive.
I agree, what people want is to avoid unnecessary backward
incompatibility. The type of thing that happens when someone decides
that all URLs should begin with the string URL: to be valid. According
to one 'official' spec we should write URL:http://www.ietf.org/
I have seen four specs that look like DKIM, there is no real difference
between them tecnically. One has significant deployment, the others do
not. That the best way to choose all things being equal.
I'd also suggest some improvements, along the following lines:
5. Add a new deliverable - a dkim overview informational rfc
which is not on the critical path (i.e. can be delivered
last) and which can contain all of the "sales pitch" and "my
favourite useful extension" bits of text we accumulate as we
go. In a couple of contexts I've found this to be a useful
way to insulate the core specs from well-intentioned but
currently distracting contributions. Its also a good way to
archive those truly useful contribitions which are basically
too early but can be re-considered once the core deliverables
have been done.
Good place to put patent busting comments as well. If we don't write
down the DNS revocation hack some troll will patent it.
6. I would allow for the later addition of a few deliverables
which can handle changes to ciphersuites, improved/fixed
canonicalisation, and/or alternative ways to distribute publc
keys. The logic here is that these are areas where specs.
have been shown to need additional malleability over the last
few years, due to developments in crypto (e.g. hash fncs>,
the discovery of broken c14n (e.g. xml sig) or just because
some specs don't arrive on time (e.g. scvp). I wouldn't start
by planning to have any of these types of spec written but
would like the charter to specifically give the chairs the
flexibility to allow new drafts in these specific areas if
they do end up being needed.
IETF is currently a three round deal. In the near future it may be
reduced to two rounds. I think we can add the additional ciphers in at
the DRAFT standard stage without introducing delay.
We are unlikely to want to do anything other than RSA with SHA1 in the
short term. In the medium term we expect to have a new hash algorithm.
We will need to consider ECC.
_______________________________________________
ietf-dkim mailing list
http://dkim.org