One of the things I tried to get at during the BoF was that using the
DNS to distribute data implies that the entity asserting that the data
is correct is the DNS zone maintainer. In DNSSEC, for example, you
can read the cryptographic work as assuring that "data which passes
this validation is the same data that was placed in the zone by
the zone maintainer".
As we move forward, we have to recognize that the connection between
the zone maintainer and the other entities involved will be critical; we also
have to recognize that the connections are fundamentally different in
the forward and reverse zones (in-addr.arpa or ip6.arpa). Essentially,
the forward zones (domain.tld) follow lines of administrative responsibility,
where the reverse zones follow lines of network topology. As we have
this discussion, we have to consider how communications about the
assertions that should be made will follow those lines.
Speaking personally, I am concerned about the ways in which structuring
this communication will interact with the policies for allocation. This is
perhaps most obvious in the reverse zone, where a delegation of responsibility
of a specific network prefix by an RIR to an ISP does not currently carry
the responsibility that the ISP maintain information at this level of detail
about the uses of the address space. If it had to maintain that data,
new tools might well be needed to pass the data from the customer
to the ISP, and that might have an effect of deployment. Not that
this is the only way it could work; indeed, it is common for an ISP
to delegate the space it has received to the organizations for which it
carries traffic, so they can maintain their own zones (see the data ARIN's SWIP
project, http://www.arin.net/library/guidelines/swip.html, for an example).
There seems to me a risk, though, that the practical need for a certain
level of assurance about the assertions being made might have an impact
on the assignment/reassignment policies. If a reassignment involves
an end-user customer, there may also be privacy regulations about
revealing data about that customer which would hinder easy association
of customer data with the assertion.
To go back to the main point, though, I think we need to consider how
the connection fits between "the person who knows that $FOO may
assert an identity" and "the person who maintains the DNS entries associated
with the MTA". If they are the same person or in the same organization
this is relatively easy; if they need to be in different organizations for some
proposals (in a common case, anyway), then discussion of that relationship
seems to me in order.
Speaking personally,
regards,
Ted Hardi