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
