Hello Phil,I moved this discussion to namedroppers and BCC-ed the IETF list, please continue this part of the thread on namedroppers.
For namedroppers, the context is:A discussion on draft-iab-dnsext-choices (the document) and the pointer mechanism as described in [1].
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.
On 23Nov 2006, at 5:18 PM, Hallam-Baker, Phillip wrote:
How is it going to have review if the editors refuse to consider it?
It is not only the editors of dns-choices that need to review the pointer mechanism, I think a wider review of the pointer mechanism is needed in order to assess the idea is actually a good alternative choice. The only thin I claim is that, as far as that happened, it did not come to a conclusion yet.
Sounds to me like you are saying that you are not going to consider my proposal until after I persuade DKIM to adopt it. Fine.
No, that is not what I am trying to say. I think that if you want to 'design' a more general extension mechanism you should actually try to pull this spec out of DKIM.
[1] doesn't look that DKIM specific and it doesn't specify the configuration directive you proposed on namedroppers in July [2] nor the discussion that followed. I think that it is time for a rev or maybe even a new draft in order to get closer to a conclusion.
So, let us try to do justice to the whole "a suggestion for super- wildcards" discussion (thread starting at [4]).
Rereading that thread:I think that most folk seem to agree that the "**" (terminal) super- wildcard could be implemented using a preprocessor [3], personally I think that such mechanism does not need a protocol action. I also think that there are still folk that would like to see a solution for the not-so-terminal wildcard (_foo.*.example.com) although we have not seen any concrete solutions and there is doubt that deployment of such (protocol) extension would ever happen.
On new RRs: We can continue to have long debates on how difficult it is to introduce a new RR and weather or not the problems that we see with a major systems vendor are real or not. I do not think that will lead anywhere. Having said that: This working group is wrapping up RFC2929bis which should ease the IANA process and at some point in the future, so my crystal ball predicts, all systems will support unknown RRs and their portable zone file representation.
Let us assume that whatever we design to deal with the problem at hand is so good that it will cause system updates on which support for RFC3597 piggybacks.
Back to the problem at hand as described in section 3 of your document [1] and some parts of the email discussion. Paraphrased: An application (the DKIM policy client) wants to know all policy statements for application X (currently mail) that relates to domain Y. Since domain Y is an element in the DNS namespace the only sensible choice is to use the DNS to reach that information. Also, we need to design a generic mechanism so that we do not have to register new identifiers whenever X changes i.e. we do not want to go back to IANA. (do I paraphrase that correctly ?).
I have seen you argue against applying DDDS for this problem but I am not sure why DDDS and the 'terminal' super-wildcard generation mechanism does not provide the appropriate means to redirect to a 'policy server' that is (potentially) outside the DNS? My gut feeling is that we have the building blocks available now. You indicated you dismissed the idea, could you elaborate a bit, or refer to the appropriate message in the thread in case I have overlooked the argument?
I'm also not sure if and how you can avoid namespace clashes for applications when you do not register the identifiers for "X". In that sense I think that the effort by Dave [5] is sensible.
Just don't dare tell me that choices in any way prevents DKIM from considering my proposal. And don't dare suggest that choices does anything more than consider the four options it describes.
I have not told you anything, at this moment I am trying to listen. Enjoy the turducken left-overs :-) --Olaf[1] http://www.ietf.org/internet-drafts/draft-hallambaker- dkimpolicy-00.txt [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00976.html [3] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg01042.html [4] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00989.html
[5] http://www.ietf.org/internet-drafts/draft-crocker-dns-attrleaf-02 ----------------------------------------------------------- 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