Hello Philip,
You wrote:
1) DKIM does not have a requirement for specifying default key
records. The need to solve the wildcarding problem does not
therefore arise and there is no TECHNICAL reason to prefer RR over
a prefixed record and significant DEPLOYMENT reasons to choose
prefixed records over TXT.
Personally, I favor of the more elegant solution of creating a new
RR. I do understand the reality of being 'held hostage' by
implementations that are not transparent to new RRs. Given that the
trade-off has been made and the lack of wildcard support does not
seem to be a problem I hesitantly consent with the use of TXT RRs in
this case.
In general I think that we should make the 'being held hostage' part
into account when doing the tradeoff. Supose 'Bob' has vested
interest in deploying protocol FOO and there is an installed base of
application X that does not work well with FOO. We (protocol
engineers) should drive to the cleaner approaches (a new RR type in
this context) when Bob is in control of implementation X. If bob
relies on Alice to upgrade application X then we may try to engineer
around that (with label prefixes in this context). That is a
difficult case-by-case, and often a esthetic, tradeoff between a
clean future and fast and cheap way to market.
2) CHOICES should not proceed until and unless it specifically
addresses the pointer mechanism for handling prefixed wildcards. I
am willing to propose text and even to take over the editorship of
the draft if the current editor is unwilling.
I note that nobody responding to these threads ever acknowledges or
contradicts either of these points above. Instead we simply get a
reiteration of the claim 'do it our way it might not be as bad as
you imagine and if it does turn out to be a problem you can blame
the Redmond club'. That does not persuade me.
I would like to make sure I understand. "The pointer mechanism"
refers to your Nov 21st message:
The approach that CHOICES does not address is to solve the wildcard
prefixing problem by introducing a new record that acts as a
pointer, the Prefix Pointer record: PREPTR.
To encode the wildcard record _prefix.*.example.com we create the
following records:
*.example.com PREPTR _preptr.example.com
_prefix._preptr.example.com TXT "This is the default record"
So in order to solve the wildcard problem, that exists because we
choose to use label prefixing, which we do because we cannot deploy a
new RR type, we introduce a PREPTR RR? That sounds like a broken
circular dependency so I think I miss something.
Speaking as the IAB stuckee for draft-iab-dns-choices:
dns-choices is almost a done deal. It will need to be reved to refer
to RFC2929bis (that doc should ease the process of getting RR type
assignments). That reference is the sole remaining issue.
I also do not agree that the document should not proceed without
addressing the pointer mechanism. The document is not of the type
that specifies new solutions, it documents tradeoffs. If your pointer
mechanism would be more than 'mail-ware' (i.e. had sufficient review
and consensus) then it could have been part of the equation. I think
that its to late for that.
(I've CC-ed the editor, too)
--Olaf
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf