First off, I apologize for an almost word-for-word repeating of myself in a
previous post -- it's fairly obvious that my mail reading habit is fifo
based :)
My feeling is that deferring this argument until the design phase won't
likely hurt, while getting it wrong in requirements phase certainly
will. If we
can just be patient until then, I think there will be plenty of opportunity
to work this issue through. I personally agree that this is an important
issue, but I'm also very interested in real experience which will support
the various conjectures about how the discovery mechanism should work.
Mike
Scott Kitterman wrote:
I'd be satisfied if the requirements draft were to say:
The protocol MUST NOT require use of a new DNS RR type. The protocol MAY
allow for optional use of a new RR type.
I understand others may not like that and so I guess we leave it open for now.
Scott K
On Tuesday 17 October 2006 16:11, Michael Thomas wrote:
From the requirements standpoint, I'd just assume that we avoid this
topic. There are some pretty deep engineering and political tradeoffs and
absent actual proposals, it's really hard to imagine that a requirements
draft would
finesse this topic correctly.
Mike
Scott Kitterman wrote:
On Monday 16 October 2006 10:21, Stephen Farrell wrote:
So I'd suggest that we leave this issue [2] open for now, and come
back to the topic when we've got a concrete protocol on which we
can base the discussion.
Does that sound ok for now?
If that's the best I can get, OK.
I was serious when I said that if we are going to have to cut and deploy a
new RR type for SSP we may as well stop now. By the time that happens
the internet ecosphere will have routed around the protocol.
From my perspective a new RR type is a showstopper problem. I'm not sure
what
a more concrete proposal for a new RR type might do to change that.
However you want to handle it is fine though,
Scott K
_______________________________________________
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html