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/
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf