Re: [IETF] Re: IETF, ICANN and Whois (Was Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC)

[John C Klensin <[e-mail]>]

--On Wednesday, June 19, 2013 17:14 -0400 Warren Kumari
<[e-mail]> 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