From: Olaf M. Kolkman [mailto:olaf(_at_)NLnetLabs(_dot_)nl]
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf