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

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jun 2013 10:30:26 -0400

--On Tuesday, May 21, 2013 09:42 +0100 Steve Crocker
<[email-masked]> wrote:

> Like the IETF, ICANN is also an open organization.  ICANN
> meetings are free, and a veritable ocean of documents are
> published regularly, many in multiple languages to increase
> availability.
> 
> ICANN is purposefully organized to include participation from
> a range of communities, e.g. business, civil society,
> governments, and the technical community. 
>...
> The roster of topics active within ICANN at any given time is
> fully documented and publicized, and I invite anyone who is
> interested to participate.  We listen to everyone, and we
> publish tentative results, tentative policies, etc. for
> everyone to critique.

--On Tuesday, May 21, 2013 12:25 +0200 Olivier MJ Crepin-Leblond
<[email-masked]> wrote:

> Quite frankly, I used to have the same feeling... until very
> recently. With Steve at the wheel, things have improved a lot.
>...
> Today, it's still not
> perfect, but you cannot fix a bus by shooting it - work on it
> instead, to fix it. I believe it's fixable.

Steve and Olivier,

As I think you both know, I've made personal decisions to avoid
saying what I'm about to say in places as public as the IETF
list and have been largely successful in that for the last
decade.  I've been deliberating about the balance of advantages
and disadvantages of responding to your notes; hence the delay
in doing so.  I've worked happily and successfully with both of
you on various Internet issues and have no doubts about either
your integrity or your commitment to a better Internet, with the
latter more or less the way the IETF would understand.  That
shared background and assumptions combined with your very
optimistic postings seem to call for comment.

Olivier, certainly there has been change at ICANN over the last
several years.  You comment implies to me that you think things
are monotonically improving; I don't believe that although I do
believe that, if one starts from selected examples and times,
huge improvements are easy to document.   I'll address the issue
of public input and what happens to it below.

As a fairly trivial example, while issues are publicized (as
Steve notes), they are publicized on a web site that seems much
harder to find anything on, unless one is spending enough time
working on ICANN issues for it to feel familiar with its
organization, than it was a few years ago.  I recommend trying
the experiment of pretending you don't know the site and then
trying to get quickly to information on the status, open issues,
and decisions already made about any particular substantive
issue in which you might be interested.

Steve, participation in ICANN is certainly not free, any more
than participation in the IETF is free.  ICANN doesn't charge a
meeting registration fee, but its meetings tend to be in more
exotic places that are more costly to get to and/or stay at than
IETF's choices (and some of us still whine about the IETF ones,
especially when IAOC considers "mid $200 range" to be acceptable
for hotels and when the combination of the IETF meeting
schedule, associated meetings, and plane connections can easily
require a six or seven day stay).  

My not entirely subjective impression is that participating in
ICANN, f2f, is considerably more expensive in an average year
than it is for IETF.   More important, while I think the IETF's
remote participation mechanisms could still use a lot of
improvement, they do tend to work and our "decisions on mailing
lists" rules and provisions for very public appeals and
responses provide a lot of protection when they don't work.  By
contrast, ICANN's remote participation mechanisms for meetings
often don't work (probably an unfortunate side-effect of some of
the places ICANN chooses to meet) and a very large fraction of
the key decision-making meetings and discussions don't even
pretend to be publicly or remotely accessible.  

But the more important issue, at least from my perspective, is
that two things keep reappearing and have either gotten worse or
remained the same in recent years.  They are:

(1) While ICANN accepts input from anyone who is interested,
there is very little evidence that any of that input has any
influence on results unless it comes from a well-established
constituency group.   There is little evidence that either the
Board or Staff actually consider any of the public input and
considerable evidence (from examination of proposals before and
after the public review) that they do not.  It is also possible
that they consider all such comments and justifiably conclude
that all of them are completely bogus or uninformed, but I just
can't believe that.  That might be less of an issue were those
established constituency groups really representative of the
Internet community but, especially in the domain name space, the
influential groups seems to be entirely those with a vested
interest in the marketing and sales of domain names.  Even in
the address space, there is little evidence that anyone but the
NRO/RIRs and their associated entities can really be heard at a
level that has an influence on policy.  I'm sure they consider
their processes adequate to reflect all legitimate input and
therefore that the closed circle of influence is a good thing;
perhaps they are right. Consequently, what "bottom up" seems to
mean in the ICANN environment is that only ICANN-recognized and
established presumptive representatives of the "bottom" have any
voice in the system with "that proposal or objection didn't
arrive via the bottom up process" sometimes being used as an
excuse to ignore input.

(2) The established mechanism for dealing with a moderately
contentious issue is to appoint a committee of volunteers to
study it.  The mechanism for even more contentious or complex
issues is to appoint many committees either serially or in
parallel.  Those committees typically produce reports that tend
to run into the hundreds of pages.  I don't know whether that is
because they don't have time to write shorter reports or because
they don't think the subject matter can be covered in more
concise reports, but the pattern is clear,   When those
committees cannot agree or discover the the issues are, in fact,
contentious, they typically recommend the creation of more
committees.  

Those committees are time-consuming enough that their design has
another effect: only those with a very strong commitment to the
work and resources to back that commitment up can participate in
practice.   Those people usually turn out to be those with a
vested interest in particular results, interests that are
dominated by those with an organizational interest in buying and
selling names.  Others who might be willing to invest personal
resources to participate in the best interests of the Internet
are typically driven out of active participation in the process,
if not initially than by the sequence and multitude of
committees and inability to even figure out where the leverage
points lie, much less participate everywhere that is necessary.

The many, many years in which one "whois" or "registry database"
committee followed another, each one addressing somewhat
overlapping aspects of the issues, but with no ability to get
any of them to address IDN or "multilingual" registrations in a
serious way (at least until very recently) is symptomatic of the
problem but I believe only one example among many.  In the
meantime, staff (I believe trying sincerely to fill the vacuum)
charges ahead with their own approaches.  Those approaches end
up either binding ICANN without even a sign of a legitimate
policy development process or, because they don't have community
support, going nowhere after considerable resources have been
wasted.

The result of the many committees is collections of long and
complex reports that often avoid asking, much less answering,
actual critical questions.  Because of the length, number, and
complexity of the reports almost no one actually reads them,
much less gets a complete picture of the systems and issues
involved.  Staff apparently sees their mandate in organizing,
overseeing, and presenting the resulting studies as "how do we
make this work and minimize the risks".  A result is that one of
the questions that rarely or never gets asked, especially if
there is a loud or well-resourced constituency for some action,
is whether the action is a good idea for the Internet at all
rather than how to do it and mitigate the damage.

The Board doesn't seem to be inclined and able to fix any of
this.  I don't know whether that is because too much of its
composition is the wrong people with the wrong knowledge and
skills, it isn't getting adequate information or an adequate and
comprehensive understanding of the issues about which it is
supposedly setting directions and policies, because it has come
to care more about ICANN's success (however measured) than that
of the Internet, of for other reasons.  However, the result
seems to be that the same patterns keep repeating themselves
years after year with little real change.

I'm not at all sure how to fix these problems, at least without
a reorganization of ICANN that is at least as significant as the
2.0 one.  But I'm fairly sure that the sort of complacency that
I interpret from the notes partially quoted above is an
impediment to even serious thinking about the issues.

I hope there is some way to do better in the future.

best regards,
    john

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 18 Jun 2013 11:57:28 -0400

Did this LC end?
or stated differently: "What's the status of this draft LC?"

I'm not such a fan of the draft, mostly because it appears to remove
some principles that some RIR folk hold up in their policy discussions
as important... while not having a backstop in said policies to
replace the originals from 2050.

That can be fixed though... provided those communities see fit to keep
the principles in place. Mostly then my 'not such a fan' is a timing
problem I suppose, which is what prompted this LC query.

-chris

---

From: David Conrad <[email-masked]>
Date: Tue, 18 Jun 2013 09:15:07 -0700

Chris,

> replace the originals from 2050.

Which principles are you referencing?

Thanks,
-drc

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Jun 2013 19:54:10 +0300

Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on the IESG telechat, up for an approval decision and/or suggestion for changes. I personally think it is ready to move forward. That is not to say that we wouldn't take comments, if you have some.

As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. For what it is worth, I have limited experience about ICANN, but it has all been very positive.

Jari

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jun 2013 13:09:45 -0400

--On Tuesday, June 18, 2013 19:54 +0300 Jari Arkko
<[email-masked]> wrote:

> Chris: The last call on RFC 2050 bis has ended. The draft will
> be shortly on the IESG telechat, up for an approval decision
> and/or suggestion for changes. I personally think it is ready
> to move forward. That is not to say that we wouldn't take
> comments, if you have some.

Jari,

For the record, I still believe that 2050bis should be
published.  Regardless of what I think of some of the things it
says, I think it is reasonably reflective of reality and that
reality is always worth documenting.

> As for the rest of the discussion - I'm sure there are things
> to be improved in ICANN. I'd suggest though that some of the
> feedback might be better placed in an ICANN discussion than on
> IETF list. And is not like there'd be nothing to improve on
> our side :-) Lets focus on IETF aspects here. For what it is
> worth, I have limited experience about ICANN, but it has all
> been very positive.

As to my more general comments, they were not really addressed
to 2050bis and I have no desire to start a discussion of them
here.  However, some assertions about how well ICANN is working
were made on this list by people who do not usually participate
actively in IETF's technical work.  In part because some ICANN
decisions and behaviors does affect the fate of IETF protocols
and the state of the Internet generally, I concluded after a lot
of consideration that those assertions should be responded to on
this list.  I would welcome a discussion (definitely somewhere
else) about that difference in perceptions if it were possible
that it would bring about either improved understanding or
changes that would make the various decision-making processes
that affect the Internet more open and/or more based on a
general understanding of Internet technical reality.  That would
include an offlist discussion of why your perceptions and mine
may differ should you find such a discussion useful.

best,
   john

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Jun 2013 20:36:26 +0300

John,

> reality is always worth documenting.

Thanks.

> and the state of the Internet generally,

Ok. Understood.

> I would welcome a discussion (definitely somewhere
> else) about that difference in perceptions … That would

Fair enough. Hopefully some of that could be fed into ICANN as well.

(I should probably have indicated that my experience is very limited. I didn't want to indicate that there are no challenges - I know there are.)

Jari

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 18 Jun 2013 14:14:50 -0400

> Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on the IESG telechat, up for an approval decision and/or suggestion for changes. I personally think it is ready to move for…

ok, cool... my  only comment was on the timing issue... which I doubt
will get fixed before pub time, and isn't a show-stopper though ...
will make the conversation at the RIR level a bit more challenging for
some folks I imagine.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 18 Jun 2013 14:21:08 -0400

> Which principles are you referencing?

at least needs-based allocations...

So, I should be clear that I don't 'like' that 'the ietf has dictated'
to the community some actions they must take with respect to
allocation policy that the RIR communities are supposed to agree upon
amongst their individual selves (perhaps coordinated, perhaps not). So
I understand why these things (and actually agree with) the removal of
these things.

I think though there could be perceived a situation where 'oops, no
more rules!!' because the RIRs (arin's community at least) hasn't
pushed for these items explicitly in their policy manual. (arin has
some of this via linkages to 2050 in their PDP.. but not in the
community-built nrpm)

It's worth noting, to me at least, that the 'no rules!' bit could be
viewed as a good thing, and could be a method to pull back as a
community and gather some data on how the system reacts. Additonally,
it could be the case that the community really does not want this sort
of restriction in place in the name of 'making the move to ipv6 happen
more quickly and more completely' (a-la burning your ships upon
landing in the 'new world').

as a summary:
  1) happy to see the principles / restrictions imposed from 'above'
on the RIR's removed
  2) happy to see the doc move forward
  3) interested to see how the communities at the RIR level deal with this
  4) sad a bit that the ARIN community (at least) didn't move to put
in place protections/restrictions/garter-belts/suspenders/etc before
this doc is published.

-chris

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Jun 2013 04:07:14 +0900

> As for the rest of the discussion - I'm sure there are things to be
> improved in ICANN. I'd suggest though that some of the feedback might
> be better placed in an ICANN discussion than on IETF list.

when that feedback is that the icann does not really listen to feedback,
i think there is a problem with this approach.  the examples of earwax
are rife.

randy

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 19 Jun 2013 08:25:10 +0200

On 18 jun 2013, at 18:54, Jari Arkko <[email-masked]> wrote:

> As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here.

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, and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to "invent" or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do?

I will btw be the first few days (until including Tuesday or so) at IETF in Berlin and am happy to discuss this issue with anyone interested.

   Patrik Fältström
   Chair SSAC, ICANN

---

From: SM <[email-masked]>
Date: Wed, 19 Jun 2013 01:59:28 -0700

Hi Patrik,
At 23:25 18-06-2013, Patrik Fältström 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, and moved forward along standards track, 
>that ICANN can reference. Same with some 
>epp-related issues, and also DNS-related, which 
>I must admit I think has stalled in the IETF. 
>When that happens, ICANN start to "invent" or at 
>least discuss IETF related issues -- which I 
>think is non optimal. But on the other hand, if 
>IETF do not move forward, then what should ICANN do?

I'll highlight part of a comment from Steve Crocker:

    (I sometimes have to explain to my colleagues at ICANN who have not had the
    benefit of the IETF experience that "let's 
send it over to the IETF" doesn't
    work.  The IETF isn't a standing army ready 
to do ours or anyone else's work.
    Rather, I say, it's a place where the 
relevant people can get together to get
    their work done.

It is easy to see why there isn't significant 
progress about DNS-related issues in the 
IETF.  If nobody volunteers to do the work the 
work does not get done.  Whether the problems are 
acute enough to require surgery is not for me to decide.

The ITU does work as the IETF does not show 
interest in doing that work when it had the 
opportunity to do so.  I would not worry too much 
about ICANN inventing as, to quote John Klensin:

   I don't know whether that is because they don't have time to write shorter
   reports or because they don't think the subject matter can be covered in
   more concise reports, but the pattern is clear,   When those committees
   cannot agree or discover the issues are, in fact, contentious, they
   typically recommend the creation of more committees.

Sometimes people either do not see the problems 
or pretend not to see them (I am not inferring 
that you do that).  In the latter case I would be 
asked to explain why I think the problem is a 
problem when I mention it.  I am somewhat 
suspicious when people who have much more experience than me do that. :-)

I don't know whether you have been following the 
URNbis discussions.  That WG had leisurely 
discussions about the drafts since over three 
years.  It has not been able to publish a single 
RFC.  DNSEXT has been in shutdown mode since over 
a year.  The call for adoption of a draft in 
DNSOP failed as there wasn't significant interest 
within the working group to do that work.

I'll ask a question to the other persons 
subscribed to this mailing list.  Are there other 
active participants in ICANN interested in doing work in the IETF?

Regards,
-sm

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 19 Jun 2013 11:27:49 +0200

On 19 jun 2013, at 10:59, SM <[email-masked]> wrote:

>   benefit of the IETF experience that "let's send it over to the IETF" doesn't
>   work.  The IETF isn't a standing army ready to do ours or anyone else's work.
>   Rather, I say, it's a place where the relevant people can get together to get
>   their work done.
> 
> It is easy to see why there isn't significant progress about DNS-related issues in the IETF.  If nobody volunteers to do the work the work does not get done.  Whether the problems are acute enough to require surgery is not for me to decide.

Correct, and this is a/the weakness of both IETF and ICANN. And to some degree there might be parties that see the lack of progress as a good thing...

> The ITU does work as the IETF does not show interest in doing that work when it had the opportunity to do so.  I would not worry too much about ICANN inventing as, to quote John Klensin:
> 

This is one pattern, correct. And lack of RFCs is one of the reasons "more committees" is an attractive tool.

I am not saying this is the only issue, I see it is one of them.

Take (lack of) progress of draft-liman-tld-names for example.

The need for this draft is in the ICANN context, not the IETF context, so of course it is hard to see the need in the IETF. Lack of an RFC there is by definition creating discussions in ICANN that goes on and on.

And do not let me get started on EPP or Whois issues... ;-)

> Sometimes people either do not see the problems or pretend not to see them (I am not inferring that you do that).  In the latter case I would be asked to explain why I think the problem is a problem when I mention it.  I am somewhat suspicious when people who have much more experience than me do that. :-)

The need is in ICANN, not in the IETF.

That I see is the largest problem. Individuals then spending time in ICANN do not, although they see the need, participate in the IETF, or do not know how to participate, or fails to express the need/problem statement in IETF.

> I don't know whether you have been following the URNbis discussions.

Oh yes! As one of the editors of the first URN documents, I have sort of a "hobby" to follow that :-P

> That WG had leisurely discussions about the drafts since over three years. It has not been able to publish a single RFC.  DNSEXT has been in shutdown mode since over a year.  The call for adoption of a draft in DNSOP failed as there wasn't significant interest within the working group to do that work.

That is one of the problems for IETF. "Can not say yes" to something, while it seems (if I exaggerate) ITU and ICANN "Can not say no" to things.

> I'll ask a question to the other persons subscribed to this mailing list.  Are there other active participants in ICANN interested in doing work in the IETF?

  Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Jun 2013 07:01:39 -0700

> And do not let me get started on EPP or Whois issues... ;-)

Actually, let's let you get started. :-)

Part of the problem you are seeing with the lack of RFCs desired by ICANN is that it is now harder to get an individual submission standards track RFC than it was ten years ago. ADs want more more done in WGs so they get more review before the document comes to IETF last call.

But there is no EPP WG. And WEIRDS is supposed to only be forward-looking, not dealing with practices with the current protocol.

The problem is that the IETF is saying two different things to ICANN: let us do the work, and we don't really care about the work you need done because it is about old protocols.

The Applications Area Directors have done a good job of spinning up short-lived WGs for narrow topics, and letting single-topic documents come to AppsAWG, but ICANN's needs are greater than that.

In the past, it was easy for a small group to put together a small protocol spec and get it on standards track if it was a follow-on to an existing protocol, but that is much more difficult now. ICANN needs it to be easier. The IETF should support them in that.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Jun 2013 12:01:18 -0400

> But there is no EPP WG. And WEIRDS is supposed to only be forward-looking, not dealing with practices with the current protocol.

Brief history and then maybe a point.  (Written as one of the co-chairs of the PROVREG WG.)

In December 2000 a BoF was held to start the work on EPP at the San Diego meeting.  A few months passed by before the PROVREG WG was formalized. I was told by a then-IESG member that the decision to form the group was contentious because EPP was to be a limited scope (B2B if you will) protocol and not something for general use.

The WG progressed by 2003 to have a nearly complete specification when it ran into IESG pushback.  I was told that the group was nearly shutdown despite the WG having come to consensus.  In March 2003 the group met for the last time, nailing down an acceptable (to the IESG) set of documents.

The group formally closed in 2004 once the drafts passed the RFC Editor queue.  At the time, the queue was quite lengthy (in duration) and in fairness there was a dependency on a trailing document.

In 2009 (5 years hence) at a ccTLD registry meeting the chorus of "EPP stinks" got quite loud.  What made this irritating was the EPP had progressed to Full Standard (Proposed, Draft and then Full) in full accordance with IETF procedures and policies.  So I took on a little exercise to figure out why, on the one hand, operators dissed EPP but the protocol engineers elevated it.

First, once the PROVREG WG was shutdown the mail list was kept open.  At the same time (2004-2009) the industry EPP that supports blossomed.  The new majority (operators coming on line then) were not aware of the mail list as the list had no cover, no publicity, no "home" if you will.  This pretty much was the root cause, as it spawned a side effect.

The material deficiency surrounding the chorus of "EPP stinks" was due to the new majority not having access to the originators of the documents and the lack of publicity for the "5th" document.  There was conventional wisdom built of how to extend the protocol that was not in-line with the intent of the design and this was causing, well, chaffing.  Was there a document describing what should have been done?  Yes, the "5th" document.  The first four EPP documents were the ones elevated through the standards process while the 5th was just informational.  As the first 4 were elevated, the 5th was forgotten, again, because the link to it was lost.  (RFP's would cite the 4 latest ones, the Full Standard, and not the original 5th.)

Once the new majority was "rejoined" with the mail list communications were re-opened between the new majority and the originators.  The technical issues were quickly solved (at one of the "formal" Bar BoFs in spring 2003/Anaheim).  With the publicity surrounding some open-source EPP software the plethora of extensions became less of a concern to the operators.  (Software trumps spec!)

To underscore the point, despite sporadic traffic in the 2004-2009 timeframe, today the list is moderately active.  There are new phases of operations that EPP supports, so there is constant growth in engineering.

At the next round of the ccTLD meeting that started my task, all of this was explained.  The alternative was, continue on with this re-patched relationship or try to invent EPP 2.0 - meaning a whole new development, deployment, and adoption effort.  The consensus was, forget EPP 2.0, the situation was now "good to go."  There's been no more choruses of "EPP stinks."

Looking back in hindsight, what would help is to have some means for the IETF to provide a maintenance vehicle for it's products.  Or realize that the "waterfall model" that seems to be in place is no longer appropriate.  (As if you've never heard that before!)  The world changes (the new majority) but the IETF acts as if "once it's an RFC it is done."

This is an example of an ICANN initiated piece of work that barely got into the IETF, the IETF completed it in a way that has benefit beyond ICANN (meaning many ccTLDs have adopted it on their own accord), but the IETF didn't make it easy and didn't help the deployment.  I hope the latter phase isn't repeated with the WEIRDS WG and RDAP.

PS. With WEIRDS there's a much more substantial industry and majority than "back in the day".  Just something to keep in mind.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 19 Jun 2013 09:22:13 -0700

On 6/19/13 9:01 AM, Edward Lewis wrote:
>
> Looking back in hindsight, what would help is to have some means for 
> the IETF to provide a maintenance vehicle for it's products.  Or 
> realize that the "waterfall model" that seems to be in place is no 
> longer appropriate.  (As if you've never heard that before!)  The 
> world changes (the new majority) but the IETF acts as if "once it's an 
> RFC it is done."
>
Are we perhaps not using area meetings with the effectiveness that we 
should be? Now that I'm cutting my teeth on the AD sponsoring thing I'm 
begining to understand why AD's are reluctant to use the tool liberally 
and the next best place assuming the existance of a critical mass of 
existing participants would be for example appsawg.
> This is an example of an ICANN initiated piece of work that barely got 
> into the IETF, the IETF completed it in a way that has benefit beyond 
> ICANN (meaning many ccTLDs have adopted it on their own accord), but 
> the IETF didn't make it easy and didn't help the deployment.  I hope 
> the latter phase isn't repeated with the WEIRDS WG and RDAP.
>
> PS. With WEIRDS there's a much more substantial industry and majority 
> than "back in the day".  Just something to keep in mind.
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 19 Jun 2013 13:04:51 -0400

> Looking back in hindsight, what would help is to have some means for the 
> IETF to provide a maintenance vehicle for it's products.

I think there is some truth to this.

The reality has at times been that some WGs get a bit out of control
after they've been around a while, and getting them to deliver final
product is a challenge. Rather then finish a MIB or do the boring OAM
stuff that a real protocol needs, folk are much more interested in
develeping all sorts of extensions and other features. As such, ADs
often want to shut down the WG and make everyone go away.

The challenge of creating maintenance WGs is that unless handled well,
they become magnets for all the leftover and unfinshed (and often
uneeded) work and random individual drafts from the original WG. And
all the same players with all the same agendas are tempted to show up
at the new WG.

Maintenance WGs are definitely needed. And they need to be timed
correctly. Wait too long, and you miss the window of opportunity
during which folk are starting to implement/deploy, and you can still
fix the spec.

Successful maintenance WGs also need strong chairs and carefuly
crafted charters that keep them from becoming nuisance magnets. The
challenge in doing that I think keeps ADs from chartering such WGs in
some cases when a WG really is needed.

Even today, there are maintenance WGs that have issues. They can be
identified by the ratio of mail/drafts/discussion to the actual
importance of the problem purported to being solved.

Thomas

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 19 Jun 2013 19:09:14 +0200

> This is an example of an ICANN initiated piece of work that barely got into the IETF, the IETF completed it in a way that has benefit beyond ICANN (meaning many ccTLDs have adopted it on their own…

To complete the story for newcomers...I did bring up EPP just because when EPP was discussed in IETF, I was the responsible Area Director. So I am (a) definitely aware of the problem, and (b) still annoyed over the result.

If I could travel back in time and try again...

Anyway....

So, the example was very explicitly chosen so that my story was not to blame any individuals, but the situation which I am both part of an frustrated of.

      Patrik

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 19 Jun 2013 17:44:21 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Wednesday, June 19, 2013 12:01 PM
To: ietf
Cc: Edward Lewis
Subject: Lessons from PROVREG WG was Re: IETF, ICANN and Whois...

[snip]

> This is an example of an ICANN initiated piece of work that barely got into the IETF, the IETF completed it in a way that has benefit beyond ICANN (meaning many ccTLDs have adopted it on their own accord), but the IETF didn't make it easy and didn't help the deployment.

Actually, I first wrote the protocol in Internet-Draft form and then socialized it among members of the ICANN community. It wasn't really initiated by ICANN.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Jun 2013 13:52:14 -0400

I stand corrected.

My recollection about the initial pushback should be clarified...by the time the reason got to me, EPP was something ICANN had asked of the IETF.  Consider that to be subject to the "telephone game (http://en.wikipedia.org/wiki/Telephone_game)" syndrome. ;)

On Jun 19, 2013, at 13:44, Hollenbeck, Scott wrote:

> Actually, I first wrote the protocol in Internet-Draft form and then socialized it among members of the ICANN community. It wasn’t really initiated by ICANN.

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2013 19:43:38 -0000

>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, and moved forward along standards track, that ICANN can reference.

As a concrete example, the EPP systems used in production by TLD
registries use extensions that are documented only in I-Ds, often
expired I-Ds, or in dusty I-D like web documents.  If you look at the
applications for new TLDs on the ICANN web site at
https://gtldresult.icann.org/application-result/applicationstatus you
will find that nearly all of them plan to use EPP extensions not
described in an RFC.  Most of these extensions should be utterly
uncontroversial, e.g., one to synchronize renewal dates among multiple
domains, or another to tell a client that its credit balance has
dropped below a threshold.

Assuming we care about stability and interoperability, wouldn't it
make sense for the IETF to spin up a WG, collect these drafts, clean
up the language, make sure they agree with the widely implemented
reality, and publish them?

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Jun 2013 08:29:12 +1200

On 19/06/2013 18:25, Patrik Fältström 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, 

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.

    Brian

> and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to "invent" or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do?
> 
> .

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jun 2013 20:42:44 +0000

> reality, and publish them?

The only way that something like this can happen is for some current or future IETF participants to do it.   "The IETF" doesn't spin up working groups.   IETF participants do.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 19 Jun 2013 17:03:55 -0400

> reality, and publish them?

I realize you were asking a larger question, but..

If we do, I volunteer to help collect, review, clean up, check and push them along.

W

--
"Working the ICANN process is like being nibbled to death by ducks,
it takes forever, it doesn't make sense, and in the end we're still dead in the water." 
    -- Tom Galvin, VeriSign's vice president for government relations.

---

From: Joe Abley <[email-masked]>
Date: Wed, 19 Jun 2013 17:14:13 -0400

> If we do, I volunteer to help collect, review, clean up, check and push them along.

This is also something we could dedicate ICANN staff time to.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Wed, 19 Jun 2013 17:14:31 -0400

>> 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.

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.

> progress should be possible.

Yup. This message needs to be properly communicated though -- Suzanne Woolf has been attempting (and being fairly effective) to do so.

W
[0]: I, along with some other IETF folk, serve on the SSAC under Patrik. 
[1]: You in the general sense, not you as in Brian or Patrik -- although I'm guessing you don't either. Are you confused yet with which you you are?

--
She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name".

    -- (Terry Pratchett, Maskerade)

---

From: "John R. Levine" <[email-masked]>
Date: 19 Jun 2013 17:14:42 -0400

> The only way that something like this can happen is for some current or 
> future IETF participants to do it.  "The IETF" doesn't spin up working 
> groups.  IETF participants do.

I'd do it if there were other interest.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Jun 2013 19:43:03 -0400

--On Wednesday, June 19, 2013 19:43 +0000 John Levine
<[email-masked]> wrote:

>...
> As a concrete example, the EPP systems used in production by
> TLD registries use extensions that are documented only in
> I-Ds, often expired I-Ds, or in dusty I-D like web documents.
> If you look at the applications for new TLDs on the ICANN web
>..
> Assuming we care about stability and interoperability,
> wouldn't it make sense for the IETF to spin up a WG, collect
> these drafts, clean up the language, make sure they agree with
> the widely implemented reality, and publish them?

I hate to put a damper on this sudden enthusiasm, but we
presumably also care about issues of change control and
adoption.    It seems to me that we could reasonably do two
things:

(1) Try to do what you suggest but with the understanding that
those who haven't come to us and said "standardize this" may
still not come... and may not consider that they have any
interest or obligation to conform, long-term, to whatever we
come up with.  I think that gets us Informational documents that
are basically a cleaned-up version of the I-Ds.

(2) At least partially follow the lead of  Joe Abley's comment.
Go to ICANN, suggest that having these commitments in the new
gTLD process depend on I-Ds that are not supposed to be
referenced normatively and might change at any time is not in
the best interest of anyone, especially the best interest of
Internet stabiiity, usability, and interoperability.  See if we
can persuade them to initiate a policy development process that
would require adherence to whatever consensus standards are
developed in this area.  Then, per Joe's comment, let their
staff poll the various actors to find out what they are doing,
be sure that the various implementations are at least intended
to be consistent and get that documented.  Then we work with
them to get the I-Ds updated and to work a process that includes
reviews from those who are actually using and depending on the
specs.  

Seems to me that would both minimize IETF workload and get us a
higher quality and better-vetted set of specs for which there
was actually a committed audience.

   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Jun 2013 20:43:01 -0400

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

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,

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

---

From: John Curran <[email-masked]>
Date: Fri, 21 Jun 2013 11:46:34 -0400

> later about keeping ICANN from doing technical work or making

+1  (specifically -  it is unfortunate that a more operational
ICANN / IETF liaison did not emerge via the PSO structure)

> 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.

---

From: David Farmer <[email-masked]>
Date: Fri, 21 Jun 2013 11:50:22 -0500

> Disclaimer: My views alone - YMMV.

A version of these three paragraphs would make an excellent executive 
summary for the 2050bis Draft itself.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jun 2013 14:56:59 -0400

--On Friday, June 21, 2013 11:46 -0400 John Curran
<[email-masked]> wrote:

>> 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.
>...

John,

While I agree with the above (and am still trying to avoid
carrying this conversation very far on the IETF list), I think
another part of the puzzle is that there are also situations in
which technical considerations imply real constraints on policy
alternatives.  Some obvious examples include physical constants
like the speed of light, others, only slightly less obvious,
include things like the design of the DNS as a simply hierarchy
that cannot support symmetric aliases (i.e., anything that would
support an actual "came from" function or a list of all of the
names that point to a given note).  The policy folks ignore
those constraints, or treat them as subject to policy-making
decisions at the risk of being ridiculous and/or causing
considerable harm to the Internet.  While they are less obvious
in this community, I suggest it works the other way too -- there
are policy and economic decisions and realities that are as much
constraints on the technical solution space as those technical
constrains are on the policy ones, with just about the same
risks of ridiculousness or damage if they are ignored.

That is, again, why it is so unfortunate that the original model
of the IAB/PSO as one of ICANN's three "everyone has to work
together" pillars was abandoned... and more unfortunate that it
was replaced on the ICANN side by approximately nothing other
than some committees and other bodies that could easily be
ignored and on the IETF side by depending on individuals with
feet in both camps to speak up.

   john

---

From: John Curran <[email-masked]>
Date: Fri, 21 Jun 2013 18:05:22 -0400

> risks of ridiculousness or damage if they are ignored.

Agreed.  I believe that there is a better understanding of this
situation now than in the earlier days (including among governments
who are beginning to seriously engage with ICANN's GAC.)

> feet in both camps to speak up.

It's difficult to lay blame anyone from walking away from the PSO approach;
in ICANN's early years it always seemed to be a vestigial structure serving
little purpose. The lack of apparent value was amplified when ICANN changed 
its proposed structure (from being oversight and coordination between true
independent supporting organizations) into a heavily DNS-focused direction 
by opting to absorb the DNSO internally in the initial Singapore meeting.
If ICANN were operating solely in a coordination and oversight role, with 
policy, process, and protocol development done in supporting organizations, 
then it would have been a lot easier to make the liaison and coordination 
function successful, both between pillars (DNSO, ASO, PSO) and to/from 
governmental types.  For some reason, doing that in the margin of a 97%
DNS-focused omnibus policy/oversight/coordination/operation organization 
doesn't provide the necessary level of attention.

FYI,
/John

Disclaimers: My views alone.  Apologies for length; I lacked the time to
write a shorter reply.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 21 Jun 2013 23:04:34 +0000

> 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,…

Something ICANN can do is ask the IETF for specifications. I can't promise instant delivery, but it will be slower if we don't know what they need.