--On Wednesday, June 19, 2013 17:14 -0400 Warren Kumari <warren@xxxxxxxxxx> wrote: >>> I think this is the correct strategy, BUT, I see as a very >>> active participant in ICANN (chair of SSAC) that work in >>> ICANN could be easier if some "more" technical standards >>> where developed in IETF, > > + lots. > > If these are not developed in the IETF, we run the risk of > ICANN doing technical stuff. Risk of ICANN doing technical stuff? You mean like the technical details of the escrow policy and how zones are supposed to be restored? Or how about Label Generation Rules for IDNs? Or how about the existing policies about registration data availability and what information is required? The point, Warren (and others) is that all of these are "ICANN doing technical stuff" and even "technical standards" in a broad sense of that term. Some of it is stuff that the IETF really should not want to do (I'm tempted to say "avoid like the plague"). Some of it probably should be here. As an outsider to both, there is a certain amount of stuff that has ended up in SSAC and even RSAC that might have been better located in SAAG or some IETF or NOG DNS operations group. I certainly won't argue that we've got the balance right. And I think it is unfortunate that the very early redesign of the original PSO had the side effect of making it hard or impossible to work out optimal boundaries and cross-review mechanisms with ICANN and that we are instead having a discussion more than a dozen years later about keeping ICANN from doing technical work or making standards. Let's not complicate things further by making the assumption that anything that reasonably looks like "technical stuff" belongs in the IETF and not in ICANN. It is likely to just make having the right conversations even harder. > As someone whose time is now[0] split between ICANN and IETF, > I can tell you something -- you[1] *really* don't want ICANN > developing technical standard. Sorry. Too late. The horse left the barn well over a decade ago, arguably after we opened the door, led it out, and gave it a good swat. More broadly, there are lots of organizations I'd rather not have developing technical standards. In a few areas, the IETF might even be on the list. But stopping them would take not the usual Protocol Police force, but the IETF Army and I don't know where to find or how to deploy them. Perhaps you do. But, if not, the best we can do is to try to figure out and describe realistic boundaries and then try to negotiate, starting with having good arguments about what should be done where and why. And we should be really, really, careful about what we wish for because a lot of the space in which ICANN operates mixes really protocol issues with Layer 8 and 9 considerations and really heavy-duty politics. >> A pre-condition for that is that technical and operational >> problem statements are formulated, which could be sent to >> appropriate WGs or used to justify a BOF. If ICANN could >> focus on that instead of solutionism or committeeism, >> progress should be possible. Sure. Especially if ICANN could actually commit. where appropriate, to mandate whatever comes out of that process and then to enforce its mandates. Of course, I would also like a pony... or perhaps a stable-full. > Yup. This message needs to be properly communicated though -- You mean like the requirements for variant aliases communicated to DNSEXT and other groups? Or did you have in mind the registration data requirements that went to CRISP? Or the more recent ones that have been handed off to WEIRDS after going through enough of an ICANN Policy Development Process that we can be reasonably confident that the requirements are real? Sorry, but, if we are going to have this conversation, I think it is very important that we be both real and specific, rather than engaging in fantasies about how things might work in the Best of All Possible Worlds or some other alternate reality. best, john