Any design the requires a new RR type is not deployable anytime soon.
As I said before, if a new RR type is the path we are going down, then we may
as well quit and go home now.
To put it in requirements language, I think it is a requirement that SSP be
deployable with the same DNS infrastructure that supports base (this is
independent of where in the namespace the record goes - as long as it's
somewhere in TXT we can design the details later).
Scott K
On Monday 16 October 2006 08:51, Michael Thomas wrote:
From a requirements standpoint, I'd just assume we not go into this level
of detail. The high level bits of deterministic number of lookups and other
things seem fairly uncontroversial, but the engineering/deployment
considerations
of the RR problem require a lot more detail and/or experimental evidence
to be
examined. I don't think that a requirements document is the right venue
to run
that debate.
Mike
Jim Fenton wrote:
Eliot Lear wrote:
Jim,
Fair points. One possibility, by the way, is that we use the SAME
prefix but simply with new attributes. That way you get the whole thing
in one shot.
I'm not sure what you have in mind here. One of the benefits of using a
new RR type is that it may allow us to get away from the use of a prefix
entirely, which in turn may shorten the search process by detecting
nonexistent domains more easily. I'm not certain how well this
mechanism works, but you can see what I'm talking about in
draft-allman-dkim-ssp-02.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html