On Jun 19, 2013, at 8:43 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
...
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.
+1 (specifically - it is unfortunate that a more operational
ICANN / IETF liaison did not emerge via the PSO structure)
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.
I believe that policy issues that are under active discussion in
ICANN can also be discussed in the IETF, but there is recognition
that ICANN is likely the more appropriate place to lead the process
of consensus development and approval.
I believe that protocol development that is under active discussion
at the IETF can also discussed at ICANN, but there is recognition
that the IETF is likely the appropriate place to lead the process
of consensus development and approval.
Note that there are lots of things that are neither policy nor
protocols (e.g. operational best practices and guidelines) and
while one can claim that either forum is valid, it really depends
on the particular situation and where those folks who are closest
to the problem actually choose to go with it (and depending on the
protocol, that might not be either of the above...)
/John
Disclaimer: My views alone - YMMV.