Subject: [Ianaplan] Where we're at/going forward

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Tue, 25 Aug 2015 12:52:17 -0400

Hi,

Reviewing the discussion of the last 24 hours, I think the major points 
of discussion have revolved around:

	1. Role of the interim outcome
	2. Scope of the statement of the WG

Speaking as one co-chair of this group (i.e., Marc may have a different 
perspective), I believe:

1.  The interim meeting produced a good starting text, but there have 
been substantive issues raised on the list since the meeting, which were 
not addressed during the meeting.  We can’t roll back to the text from 
the interim without addressing those issues.

2. Those issues largely have to deal with clarity about scope of this 
WG’s comments.  As I noted on Friday,  we have a charter item to 
review the whole proposal but only in the light of the protocol 
parameter function.  This does not take anything away from our 
individual right and responsibility to review the whole proposal, and it 
also does not touch the fact that the IETF as a whole may have a broader 
responsibility to review the whole proposal, in the light of the future 
of the IANA entity in its entirety.   If people want to address that 
(the IETF’s larger response), they are welcome to address their 
comments in the appropriate forum, which is not this WG.  (I’m 
guessing it would be [email-masked], or anywhere the IAB designates).

Those of you who were on the call on Friday will recall that I urged 
that the WG’s statement be encapsulated (but clearly identified) in 
whatever total response the IAB sends on behalf of the IETF.  Consensus 
on the call was that the WG should send its own, scoped message 
directly.   That’s the path I articulated in my note after the call, 
but I’ll observe that the approach is also up for consensus 
confirmation on the list.

Leslie.

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2015 21:42:12 -0000

>of the IANA entity in its entirety.

Quite right.  Personally, I think the transition plans for parameters
and for numbers are fine, and that the plan for names is not.  If you
asked me whether I'd support the combined three part plan, the answer
would be no.  It sounds like I'm not the only one who feels that way.

At this point I don't understand what reviewing the whole proposal in
light of the protocol parameter function really means.  If it means do
we think son-of-IANA will handle parameters well and we have an escape
route if they don't, we all seem to agree on that.  If it means that
the whole proposal will work to maintain the stability of the DNS, I
see no consensus there.

The IETF interacts indirectly with IANA via the names world in lots of
ways.  The obvious recent example is the discussion about .onion and
other non-DNS name use, but there are technical stability issues for
changes to top level records (.google asked for a wildcard last year),
for DNSSEC (will we ever invent a workable way to provision it) and
all of the various ways to bundle names that are semantically related,
a problem that the marketing community appears to believe is trivial,
but that we have found intractable.  So far we've managed to dodge the
bullets, but that seems to me largely due to the moral suasion that we
have over ICANN, due in no small part to personal relationships with
leaders who, although vigorous, are not immortal.

So if we're going to make a statement about the combined proposal, we
need to make it clear that we endorse the parameter parts and make no
statement either way about the rest of it.  If the press spins that as
saying the IETF doesn't endorse the names PTI, they wouldn't be wrong.

Beyond that, I don't see that we have any particular expertise related
to what the names community should do beyond being particularly aware
of what's likely to go wrong if they screw it up.  So even though some
of us might like to comment on the names part, or on the whole thing,
we probably shouldn't.

R's,
John

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 26 Aug 2015 16:04:38 +0900

Hello Leslie, others,

> the interim without addressing those issues.

I agree. I haven't ready the full proposal, and I don't have time to 
read it. I'm not sure where exactly I'd fall in evaluating it (on the 
spectrum between John Klensin and Eliot Lear).

My guess is that this is similar for (mostly silent) the majority of the 
members of this group. But that's not for me to judge.

I'd personally prefer that it be made clear that we (this group, the 
IETF as a whole) don't express anything about the proposal as a whole, 
except where it affects our activities. Any of the many texts that make 
this clear would be fine for me.

> WG’s comments.  As I noted on Friday,  we have a charter item to review
> the whole proposal but only in the light of the protocol parameter
> function.  This does not take anything away from our individual right
> and responsibility to review the whole proposal, and it also does not
> touch the fact that the IETF as a whole may have a broader
> (the IETF’s larger response), they are welcome to address their comments
> in the appropriate forum, which is not this WG.  (I’m guessing it would
> be [email-masked], or anywhere the IAB designates).

I may be totally wrong, but my understanding was that [email-masked] wasn't 
subscribable, or publicly archived. I haven't found any hint/link to 
subscription instructions or an archive at https://www.iab.org, but I 
may not have looked carefully enough.

If the above is correct, I guess that [email-masked] would be way more 
appropriate for discussing the IETF's larger response.

> directly.   That’s the path I articulated in my note after the call, but
> I’ll observe that the approach is also up for consensus confirmation on
> the list.

Either is fine with me.

Regards,   Martin.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Aug 2015 10:03:26 +0200

Hi John,

On 8/25/15 11:42 PM, John Levine wrote:
> but that we have found intractable.

Indeed, and you haven't even touched on Unicode.

>   So far we've managed to dodge the

Yes.
> saying the IETF doesn't endorse the names PTI, they wouldn't be wrong.

The problem is that you continue to treat this proposal as three.  It's
not.  It's one integrated proposal.  Further, a binary decision will
eventually be made.  Ours is as follows: do we support it or not, and
why or why not?  Does the ICG have more information if we simply support
only our portion of the proposal?  I would say not.  They gain a little
information if we tell them that they haven't cocked it up.  But a very
little more.  We have the opportunity to say more.  If we pass on that
opportunity, the decision will be ceded to others; and we may not like
their view or their goals at all.

Thus we perform a risk analysis.  Are the risks of not supporting the
proposal outweighed by the risks of supporting it?  Note "it" and not
"them".

Eliot

---

From: "John R Levine" <[email-masked]>
Date: 26 Aug 2015 09:02:25 -0400

> their view or their goals at all.

Now I'm really confused.  If we as think the parameters and numbers are OK 
but the names are headed for trouble, what do we say in what capacities?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Aug 2015 15:14:06 +0200

Hi John,

On 8/26/15 3:02 PM, John R Levine wrote:
>> The problem is that you continue to treat this proposal as three. 
>> It's not.  It's one integrated proposal.  Further, a binary decision
>> will eventually be made.  Ours is as follows: do we support it or
>> not, and why or why not?  Does the ICG have more information if we
>> simply support only our portion of the proposal?  I would say not. 
>> They gain a little information if we tell them that they haven't
>> cocked it up.  But a very little more.  We have the opportunity to
>> say more.  If we pass on that opportunity, the decision will be ceded
>> to others; and we may not like their view or their goals at all.
>
> Now I'm really confused.  If we as think the parameters and numbers
> are OK but the names are headed for trouble, what do we say in what
> capacities?

From the IETF point of view, if that trouble from the names community is
heading our way, we should express our concerns and any proposed
changes.  Even if some trouble *is* headed our way (and nobody has
really seriously argued that it is), we should perform a a risk
analysis, like with many other business decisions to determine what path
is best to take.  The level of meta-conversation in this thread has
obscured nearly all of that because nobody has actually shown a
substantial risk to us.  Perhaps that's one of the reasons most people
are okay with Leslie's text, although I myself would prefer the
alternative I sent.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Aug 2015 12:44:55 -0400

--On Wednesday, August 26, 2015 10:03 +0200 Eliot Lear
<[email-masked]> wrote:

>> The IETF interacts indirectly with IANA via the names world
>> in lots of ways.  The obvious recent example is the
>> discussion about .onion and other non-DNS name use, but there
>> are technical stability issues for changes to top level
>> records (.google asked for a wildcard last year), for DNSSEC
>> (will we ever invent a workable way to provision it) and all
>> of the various ways to bundle names that are semantically
>> related, a problem that the marketing community appears to
>> believe is trivial, but that we have found intractable.
> 

The above actually identifies another issue that I think we have
been (correctly) trying to avoid: In what, from my point of
view, would be a more reasonable approach, those are not
interactions with IANA at all but are interactions with the
domain names policy part of ICANN.  The parallels to more
traditional protocol parameters should be clear: if someone
believes a particular value should, or should not, be allocated,
they may have an issue with the IESG, some expert responsible to
the IESG, or even the IETF's definition of the relevant
registry, but they don't have an issue with IANA.  IANA should
be fulfilling an almost entirely administrative function: the
things that have turned it into a leverage point are
understandable historically but almost certainly undesirable
from the standpoint of _all_ of the customer/ "operational"
communities and we should probably be working, at least
post-transition, to reduce their scope.

It is possible that something like a root-level wildcard would
be an exception, in that the policy process might direct IANA to
do such a thing and IANA might, perhaps with IETF advice, plead
technical feasibility or technical implications as a reason to
not do so.   But those examples are very few and most of the
cases described above are really interactions between the
technology and IETF interests and expertise and ICANN policy
decisions.

>...
> The problem is that you continue to treat this proposal as
> three.  It's not.  It's one integrated proposal.  Further, a
> binary decision will eventually be made.  Ours is as follows:
> do we support it or not, and why or why not?  Does the ICG
> have more information if we simply support only our portion of
> the proposal?  I would say not.  They gain a little
> information if we tell them that they haven't cocked it up.
> But a very little more.  We have the opportunity to say more.
> If we pass on that opportunity, the decision will be ceded to
> others; and we may not like their view or their goals at all.
> 
> Thus we perform a risk analysis.  Are the risks of not
> supporting the proposal outweighed by the risks of supporting
> it?  Note "it" and not "them".

Sorry to be splitting hairs, but I'm trying to suggest a
narrower goal and analysis.  I don't want to see us be forced to
pull out of the IANA arrangements either pre-transition or
post-transition.  I recognize that, official/formal statements
aside, enough of the ICG is following this list that it would be
irresponsible of them to not be aware of the concerns.   I
don't, for example, want to see the IETF opposing the PTI idea
because the WG hasn't studied it and, more important, the
organizational behavior and culture issues it involves and
assumptions it makes are not areas of strength and expertise for
the IETF.    It is, it seems to me, reasonable that we express
misgivings, but, for that reason, not reasonable for us to
either oppose or endorse.  I can tell you that, in my very
personal opinion, having PTI, and, e.g., various of the
boundary-condition budget issues in the mix significantly
increase the odds that we will eventually have to pull out, but,
for the reasons above and because it would surely be construed
as a threat, I'm opposed to the WG saying that.

If the discussion is broadened beyond "what do we need to make
the protocol parameters work well, at least as long as everyone
continues to recognize their importance and to act in good
faith, another question comes into the equation, one that we
(and the ICG) have generally assumed away.  That question is
whether, if this type of very complex proposal, with little
identification of what problems some of the mechanisms are
intended to solve and no external and truly independent
oversight or review capability, is the best the community can
do, whether the Internet would really be better off with the
potential for US Government oversight withdrawn.  Politically
and symbolically, I think the answer is "get the US Government
out at almost any cost".   Operationally, procedurally, and in
the actual best interests of a technically functional Internet,
I'm not quite so sure -- not because I view the US Government's
role as entirely benign but because there is a possibility that
the other alternatives may be worse.

--On Wednesday, August 26, 2015 15:14 +0200 Eliot Lear
<[email-masked]> wrote:

> From the IETF point of view, if that trouble from the names
> community is heading our way, we should express our concerns
> and any proposed changes.  Even if some trouble *is* headed
> our way (and nobody has really seriously argued that it is),
> we should perform a a risk analysis, like with many other
> business decisions to determine what path is best to take.
> The level of meta-conversation in this thread has obscured
> nearly all of that because nobody has actually shown a
> substantial risk to us. 

OK, if that is the elephant in the room, let me be the bad guy
and identify the problem.  First, very little of what follows is
the IETF's problem and I hope we can keep it that way.  While
the role and "community" that make up the IETF and RIR/address
communities are fairly clear, it is less clear that that even is
a "names community".   Insofar as there is, it is widely
believed that the representation and decisions of that community
have been captured by those seeking profit in names rather than,
e.g., considering accurate identification (including
anti-phishing concerns) or Internet navigation issues paramount.
Should the balance within that community shift, perhaps because
there actually is a bubble in the "names market" and it bursts,
it is entirely unpredictable how that "community" would behave,
especially if they are expected to bear the costs of operations
in which some fractions of that community has not seen
themselves as involved or concerned.  

If the possibility of a de-funded, or financially seriously
constrained, protocol parameter function is a substantial risk,
then that is the source of such a risk.    If we believe that
our ability to walk away provides adequate protection against
that risk and that it would be painless enough to mitigate some
associated risks, then there is no issue and we should just move
on.  But, as I tried to explain in my note to Olivier, I don't
believe that having only a choice between putting up with an
unacceptable situation and having to pull the plug in the event
of a crisis is a desirable position to be in and, for that
standpoint, that choice of options is another substantial risk.

best,
    john

---

From: Eliot Lear <[email-masked]>
Date: Thu, 27 Aug 2015 16:59:15 +0200

Hi John,

Skipping down...

> the other alternatives may be worse.

I would say that where we split hairs, if you can call it that, is that
I view the alternatives as far worse.  As I've said, this is a risk
analysis.  But on to the meat of the matter...

> standpoint, that choice of options is another substantial risk.

Well, first, thanks for being specific.  I think we run better as an
organization on this sort of fuel.  Since you did me the courtesy of
commenting along these lines I feel obliged to respond in kind.

I agree that the budget is an issue, but I do not view it as an
overriding one for several reasons.  First, if the bubble bursts, the
structure of ICANN won't matter that much because the revenue shortfall
will hit the organization as a whole.  There is no alternate revenue
stream today and none is proposed post-transition.  Second, the overall
IANA budget is relatively small compared to the ICANN budget.  Third,
ICANN has sufficient reserves that in the event of a shortfall, there
will be time to find alternate funding sources and, if needs be,
organizations that perform the function.  In addition, ICANN has
undertaken an obligation to this community.  I suspect they will be
loathe to relinquish their responsibilities, as they are the basis of
the organization's raison d'etre.  Does this make it certain that the
budget will forever be funded?  No.  There are no certainties.

Still, I think it is worth it for the IAB to raise this sort of concern
with regard to the CCWG proposal, where the budget is discussed, and I
hope they will.

In regard to your note to Olivier, I know you know that the nuclear
option is called that for a reason, and that you know many intervening
steps exist.  Those steps should make one confident that the button will
not need to be pushed for a very long time, if ever.  Again, confidence,
not certainty.

In the end, therefore, I personally weight the risks of not proceeding
higher than proceeding.

Related, the charter of this list has necessitated thinking about nasty
"What if" scenarios that make it sound like The End Draws Nigh.  That's
just not the case, nor is there any real reason to think that the
situation will change.  And so it's probably good to remember that from
time to time.  We are all, after all, trying to do what is right for the
Internet.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Aug 2015 13:08:07 -0400

> I would say that where we split hairs, if you can call it
> that, is that I view the alternatives as far worse.  As I've
> said, this is a risk analysis.  But on to the meat of the
> matter...

Letting the elephant in the room out and turning it loose, the
bottom line may be that different of us appraise the ICANN
situation differently, weigh the factors of the risk analysis
differently, make different projections about how the ICANN
community might behave under stress, etc.  Reasonable people can
differ on those points and I'm not convinced that more traffic,
especially as long as we continue to be circumspect about the
details of our various case analyses and scenarios, will help
convince anyone.

Perhaps as part of that, but perhaps as an independent issue, I
apparently assess the alternatives differently than you do.  As
as result, I don't think a "far worse" conclusion is justified
although I see risks either way.  I don't know how relevant it
is today, but I note that, in the ICANN formation period, there
were several governments whose public position was that US
Government involvement (usually spelled "control") was
unacceptable but whose private one was closer to "all of the
other obvious alternatives are likely to be worse").

Because of those differences and the expectation that we are not
likely to persuade each other -- especially when neither of us
seems anxious to go into details about our analyses and the
information and sources on which they are based -- my preference
is that any formal WG comment focus on what the WG actually
knows and has discussed rather than our various risk analyses
and their interpretations, speculation on scenarios, etc.

  best,
   john