> From: Olaf M. Kolkman [mailto:olaf@xxxxxxxxxxxx] > 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. Agreed, but let us also be on the lookout for folk who insist on deployment of a change to the standard knowing that it will favor specialist providers of DNS infrastructure over platform providers. > 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. As I have discussed on DNSEXT on several occasions it is actually possible to do the same thing by defining semantics for PTR which is currently unused in the forward direction and has the correct semantics in the reverse. The reason for proposing PREPTR is purely political as I have mentioned. There are some people who see a value in new RRs for their own sake. I can live with a new record for the purpose of supporting wildcards because wildcards is not a feature that everyone requires, even in the context of DKIM. In the case of DKIM there are two requirements for DKIM specific semantics. The first is the key record, the second is the policy record. There is absolutely no reason to require the ability to specify default key records and plenty of reasons to avoid them. So there is no requirement for wildcards, none. The next consideration is policy records which are not in last call but do have a requirement for default records and thus for wildcards. My preferred solution would be to use PTR for the policy pointer. It is clean and means that we can deploy everything now and be 100% backwards compatible. An acceptable outcome is to define a new record for PREPTR but use prefix records for base policy. This allows people to define DKIM policy records now but requires them to upgrade if they feel they need wildcards. There is the 'sand in the shoe' that encourages them to upgrade. If you want to encourage DNS servers to be tollerant of new RRs this is one approach to take, another is to use DNSSEC in the same role. There are two unacceptable outcomes. The first requires everyone to upgrade their DNS server before they can deploy DKIM. The second unacceptable is to define a prefix record and a new RR and try to persuade people to make a switchover, this approach was suggested in MARID but if you consider the implications it means a doubling of DNS query traffic for absolutely no benefit whatsoever. PREPTR is not an ideal outcome but it is one that I am willing to live with. It means that we have one new episode of RR deployment but would not require a new RR for every single protocol that requires policy. In my book I consider this approach, a once and forall change to the DNS infrastructure to be the most logical, most principled and most aesthetically pleasing solution. > 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. The draft is incomplete. It does not review all the technical options. These were raised on the DNSEXT list months ago. If you want there to be consensus on a draft then it has to put all the options fairly. If you want to refer to the draft as an authority you have to consider all the options. > 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. How is it going to have review if the editors refuse to consider it? 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. 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. If you want choices to be influential as an architecture document it has to consider all the choices. Otherwise it is dead on arrival and you wasted the time. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf