Another omnibus response to a few. (Had to step away for a few days.) On Apr 23, 2013, at 17:02, Wes Hardaker wrote:
> - Realize that CDS is likely to go forward because a lot of people like it > and: > > - [ ] choose to ignore it because it doesn't fit your desires > > - [ ] offer concrete suggestions to change it so it does fit your > needs (without removing the features that everyone else keeps saying > they want (in-band acceptance)) I think that the above statement is indicative of what I see wrong in the IETF process. Sorry that this is off-topic, but I feel the need to pick this out as something to look out for in the consideration of the proposal. "A lot of people like it" - but that is not consensus. And, I can't say that I even agree with "a lot" and "like it". What is "a lot" when you consider that very, very few people have ever recorded a public opinion on this? I haven't counted (to be fair) but I bet it is less than 25. We had more than that in the DNSOP meeting in Orlando. To go quickly to the point, there are a lot of people in the DNS industry that don't participate in the IETF, so "a lot" is kind of a weak bar. As for "like it", this is a first draft and I'd say I like it because it has potential. Olafur has a framework for going forward which is good. As for an concrete alternative - if I'm not mistaken, this is a working group. I have ideas, but because I time slice through life's issues, I don't want to fix my mind up with a solution that I'd fall in love with. I have in the past offered up criteria for opening this up. But I don't have a solution. I'm trying to avoid having an opinion, because I don't think the problem is completely understood. Sorry for this rant, took more time than I thought. > - [ ] Objecting and then pushing the appeal as far you can make it go > and stomp your feet really loudly on the ietf@ mailing list Frankly, I really don't have even just the time to think about that much less launch a complaint. If the IETF promotes a document, I let it go. I honestly don't care that much about the process. There are a lot of bad documents out there already, what's one more? Well, in this case, if the proposal isn't general, you've added one more obstacle to a general solution. I do care about engineering something useful, document quality is not what I'm going to bark about - just not enough time. On Apr 23, 2013, at 20:07, Andrew Sullivan wrote: > ... (1) that this is an > important additional move on the supposed insignificance of the SEP > bit, and that is worrisome and (2) if this mechanism were altered > slightly, then it could be more generic and therefore more useful. Exactly. > Instead I'm just pointing out that a dismissal along > the lines of "just don't use it" seems to ignore at least part of the > point of reviewing things in the IETF. Exactly. (I guess this is more of +1 to Andrew's message.) On Apr 24, 2013, at 7:36, Antoin Verschuren wrote: > I actually think it's the ICANN-style translation of the RRR model > that is wrong and why we don't go forward. That's not a a helpful response to the problem. Whether you are right or not, you can't wave a wand and see requirements go away. No matter what one feels about a set of business rules, you have to deal with anything that others want to participate in. I have a hard time seeing how a model that accounts for 100's of millions of domain registrations can be so flawed it can't work - especially when there are, what 250 million total domain registrations? I"m just saying - you can't discount something that is so prevalent even if it is flawed. On Apr 26, 2013, at 1:55, P Vixie wrote: > Mark's right. Not so much as a reply to that but a reply to the alternate engineering solutions and a reason to keep an open mind. If this were easily solved, it would have been in RFC 4034 and RFC 4035. Recall that in 2002-2003 (when the work behind the RFCs happened) we did not have the experiences we have now. And EPP had just started rolling out, etc.... Pretty much we need to have something in the CDS record at the apex of the zone. And to make this work really well, we have to figure out how I'd get a DS record for an unpublished DNSKEY into a zone like .NL (Antoin's - well, not his personally) that wants keys to work on, not DS records. To hark back to Wes, I don't have answer for that, I don't want to propose a solution - like, hey Antoin, you're wrong, use DS instead - that would prevent Antoin from operating under his model. I can see having CDS be used to indicate what DNSKEY Antoin would have to pull - if the key is in the DNS. And yes, there is a DS record in the root zone (as of last time I checked) that pointed to an un-published DNSKEY. And it is not one I put there just to mess with Antoin's model. ;) I'm looking forward to the next document on this, and we can continue working on it. Problems are solvable, even more so when the problem statement is clear and agreed upon. And - the problem statement might morph as we progress. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
