Minutes for IANAPLAN at IETF-91
minutes-91-ianaplan-1

IANAPLAN WG at IETF 91
Co-Chairs:
Leslie Daigle
Marc Blanchet

Agenda:

Agenda bash
1. Review of outstanding issues in draft-ietf-ianaplan-icg-response
Discussion of issues raised on the mailing list

2. Conclusion and next steps.

——Intro Slides——
(Leslie Daigle as co-chair)
Timeline
* tight timeline, externally imposed

Goals of this meeting
* discuss and consensus on final outstanding issues

** Questions and discussion held to the end; slides contain the change
log and proposed text for all suggested changes**

(Eliot Lear) presents the slide deck on changes to
draft-ietf-ianaplan-icg-response.

Q&A <draft-ietf-ianaplan-icg-reponse-02>

(Eliot Lear) Does the IAOC feel there is enough here for guidance?
(Bob Hinden) What do you want the IAOC to do if they can’t negotiate the
intent of this?  Are you pushing a hard problem to a future IAOC?  You
are asking a lot for something to happen in the future, and maybe the
IAOC will need more guidance on the desired result.

(PHB) Less worried about the name or the ownership than about switching
costs.  The issue is if we end up in a situation where ICANN is at the
center of a cyber WWIII by necessity because the name is a control point
for the Internet, would like the IETF to be completely decoupled from
that argument.  The question is why do we need to be so attached to the
name?  We switched from ARPAnet to Internet.  Don’t feel bound to the
IANA name.  We should own the brand of the registry, and that registry
brand is run by IANA.

(Leslie Daigle) When you have an opinion, state not just the solution,
but state what problem you have to solve. Thank you, PHB, for doing that.

(Scott Bradner) also on the IAOC.  Probably cannot stay out of this food
fight.  IANA is listed in a lot of RFCs and those won’t change, so we
have to deal with that at some point.  As a member of the IAOC, the
right answer may not be that the IAOC negotiates.  Historically, this is
a task that belongs to the IAB and IETF chairs.  The IAOC stands as a
backstop and second-guesser to that, but it’s not a good idea to have
that scale a committee to be doing detailed negotiations.

(Jari Arkko) The WG provides the guidance on direction, and then we’re
not the ones to do the amateur lawyering.  Some of these things are
agreements beyond this organization so we cannot decide on them
independently.  The mechanics of who actually does some of this
negotiation we can discuss, and part will fall on the IAB and the
chairs, and part of the IAOC.  Now that we have text, Jari is reasonably
happy that he knows what needs to be done.  To respond to Bob’s question
about putting the IAOC in line of a hard problem, we need to have a plan
and that plan means several things in the world need to happen. But it
is a separate step, and the transition isn’t just that we publish an
RFC.  If those changes are impossible to do, that’s a very public and
visible thing.  We need to specify what the IETF needs in this space and
go do that.

(Russ Housley) Instead of saying what needs to be negotiated, say what
the desired outcome is.  There is no confusion about where to find the
authoritative protocol parameters.  As long as we have that outcome
everything is ok.

(Jon Peterson) I agree, and that’s a big improvement to the existing
text.  In the event of a transition, what owners are we talking about at
various points of the transition?  (Eliot) We mean the operator that we
are transitioning from and the operator we are transitioning to.

(Larry Masinter) There is a grammatical error that introduces
confusion.  Definite or indefinite article? (Eliot) The extra definite
article needs to go.

(Alissa Cooper) Don’t feel there is a problem to be solved here.  Not
concerned about confusion, and we will have many options on how to find
parameters even in the event of a transition.  Have two suggestions that
have been sent to the list.  As long parties agree to minimize
confusion, don’t need to get so detailed.  It’s hard to specify the
detail in advance; just specify the goal.  We are also asking too
specifically things of the IAOC.  Maybe say we want the IAOC/IAB to work
together to minimize confusion, and leave it at that.

(Dave Crocker) [jabber] Switching costs could be high but they are
cheaper if we attend to the issues now rather than wait until the event.

(Andrew Sullivan)  Following up on Bob - you can’t have in this text
anything that says “go negotiate this” that also have a detailed, sorted
list of what you can give up in negotiation.  Don’t believe there really
is a problem here to solve, so would like people to be more clear on
that.  If it’s not already covered by existing arrangements, you need to
say what it’s worth to you (if you don’t already have it).  People need
to be able to say “this is worth more than something else” else we’re
not really negotiating, we’re demanding.

(Andrei Robachevsky) Regard to level of requirements, heard the word
“negotiations” but think it implies negotiation with ICANN, but we need
to look at the united proposal.  If we can’t coordinate proposals, we
have a problem.  The goal of this group is to make sure outcome is
clearly specified, and then negotiation happens when we see other
proposals.  In the united proposal, we need to resolve those issues.
The probability of resolving those issues will be lower if we embed a
specific solution in this draft.

(Tobias) seconding Russ; if you give us an indication of desired outcome
that would be more helpful than what we should demand.  A wish list
would also be nice.

(Leslie Daigle) Of the things heard so far: minimizing switching costs, and
minimizing confusion, with a separate conversation about how and what
going into this document.

(PHB) It is important to put the reasons in.  Most people involved in
this dispute have no idea the technical implications and it needs to be
explained to them.  The people driving the meta process are not really
technical. What they want to do is establish the internet as free of
government control, and that is also the goal of the US government.
This isn’t a negotiation in the classical sense; you are negotiating a
will before the person has died.  Putting this on the table to say this
is what we need to be independent of US government and ICANN control is
what’s important to say.

(John Curren)  Picking up on what Andrew said, there is an implied
negotiation aspect to this.  Whatever the IETF sends to the ICG is just
one of several proposals the ICG will need to bring together.  The IETF
will need to agree to support the process.  The implied “what you give
up” is that the IETF would prefer the status quo.  The IETF can say it
believe something is necessary, with the implication being if that’s not
possible, maintain the status quo.  The document should be clear about
what it MUST (RFC 2119) have, and what you SHOULD have, but it is
implied that what you put in the proposal are necessary for moving
forward, and you don’t need to specify the trade offs

(Jon Peterson) Have mixed feeling about lobbying for specific outcomes
prescriptively.   Some people we believe we should be lobbying for a
broader say, but having the IAOC specified in here is probably more
detail than the ICG needs to know.  We’re giving the IAOC too much
direction in this.  (Eliot) You hit on something nagging at me as well:
are we doing th right thing in the doc mentioning the IAOC at all, or
should we state what our requirements are in terms of the service, and
separately charge the IAOC to have discussions to get that outcome.  Is
that what you said?  (Jon) I am torn.  Given the fact that we could drag
this down into a lengthy process in getting into that detail when we
understand this community cannot be privy to all the negotiations, the
less we say about it the better, and the more we communicate that it
would be nice to have the status quo seems good.

(Alissa Cooper) Really like the thinking that John Curren has about the
separate of  must-have and nice to have.  This doc only needs the
must-haves and if the draft is limited to the must-haves, then the IAOC
doesn’t need to be mentioned at all.  None to the things that mention
the IAOC are must-haves.  In responding to Andre, there are people
paying attention to proposal development, and it is not the
responsibility of the IETF community to make sure this proposal is
consistent with those other proposals.  It’s not like we need to have
everything resolved in the next two months.

(Ted Hardie) We are trying to solve a superset on the question of
switching costs.  We are putting forward whatever we need in the
process.  It is a risk management exercise.  Do we want to start that
aspect of the risk management now, or later, or hope it never comes up?
If we put in what we believe what we as a community must have, we are
looking at having complex negotiation of things that might not actually
need to happen.  We may be increasing our risks of a putative award for
a later condition not happening.  Do the simplest thing that will work,
and so the proposed text does not belong in the document.

(Bob Hinden) Agree that this has nothing to do with the IAOC.  We are
talking about whether we the IETF needs to own IANA.org.  Should the
position of our community be that the IETF Trust owns it (if not operate
it).  We have more ability to negotiate that outcome than some time in
the future.  That’s the question the IETF should be debating.  It is not
a vague notion of the IAOC should negotiate something good.

(Jari Arkko) More complex than that, since IANA.org is used by multiple
parties.  Want to make the observation so far that everyone at the mic
line has said go to higher level requirements.  The separation of MUST
and SHOULD is a good thing.  This is not the only thing we’re doing, the
transition is not the only thing we’re doing.  We make changes every
year.  We had some discussion today around those topics.  You don’t have
to do everything in this document, so support doing only the absolutely
required things.

(Geoff Houston) Though the aim of the doc was to demonstrate to the
community that the NTIA doesn’t have a necessary role to the
relationship with IANA functions, that they could walk away from this
and the mechanisms in place would still allow things to function.  The
top level is saying “this is how we structure the relationship and
things change, and here’s how the community can see what we’re doing”.
It doesn’t need to say in precise detail what we’re doing and how we’ll
react.  Keep it general and as high as you can, and demonstrate that the
controls and functions are in place and we are

(ekr) support the points made.  Don’t send people to negotiate with a
precise program of what they can negotiate.  Baffled that people think
that’s big a deal.  The notion that people will get confused about where
to go for protocol parameter registry is bizarre.

(John Levine) Thi sis contract negotiation and think there is a key role
for NTIA.  They were there in ICANN wanted to do something stupid.  In
some future incarnation of ICANN they could decide to demand money.  It
is important that we at least have an understanding of what the
agreement is and how we negotiate if one side of the other needs a
significant change.

(Leslie Daigle - speaking personally)  Making sure that the clarity of
the IPR of the registries is important, and that’s another thing that
mentions the IAOC.  The high level requirement in the doc that’s a MUST
- the IETF requires there is a stable reference on where to find the
protocol parameters and how to operate the service.  The implementation
of achieving that, the paths are different between what you do now
versus what you do when there is a problem and/or a desire for change.
Another way to implement that there is stable references and clarity
about IPR is to consider alternatives.  This doesn’t have to be done as
one flag day thing.  Key points: fine with going with high level
requirements in doc as long as we’re clear there are multiple possible
implementations, and that a strategy for future change/negotiation

Jabber room
JCK - agree with Andrew that it is desirable to avoid solving problems
we don’t have but agree with avoiding switching costs.  Take it off this
groups table and ask the IESG to consider a separate domain

Martin Duerst - why not put nice to have in the draft; if another
community has the same it would be a shame to drop it

Dave Crocker - switching costs are not a risk, they are an expense

Stephen Farrel - we do not need to own IANA.org

(Russ Mundy) Has a seat on the ICG, but speaking as an individual.
Heard several people mention the merger/single integrated proposal.
That is absolutely the wrong thing to do.  There will not be a merged
proposal.  There will be three or four proposals from the respective
operational communities, and one letter or mini-cover piece of words
from the ICG that states “here are the proposals, here are the
overlaps”.  The ICG doesn’t intend to merge proposals.  The IETF’s
proposals should/will remain the IETF’s proposal.  Urge folks to take a
look at documents that the FSAC (?) have produced.  They talk about what
the contract today says, and today’s contract specifically states there
will be no cost to these functions.  It also says the IPR of the
registry cannot be claimed by ICANN.  There are good and useful things
stated in the existing contract that people may want to consider
pointing to or extract from.

(Jon Peterson) Some burden of reconciliation will eventually fall to the
ICG (probably).  Insofar as these things are up for grabs, deeply
concerned that with all these things up for grabs we can lose our sense
of mission.  Hope you get input from people with broader governance of
input.  (Russ Mundy) each community should talk about what they need and
want, and the ICG is looking for what collides.  Those collisions will
be sent back to the respective communities for resolution; the ICG
doesn’t do that.  (Jon Peterson) the stable registry requirement - I
fear the ossification of our process that unduly binds us to procedures
that may not be what we want to be in five years.  I want IANA to evolve
with us.

(Richard Barnes) Stability is way low on the list of priorities here of
what is needed to make the Internet operational.  Can everyone today see
the specs and protocols?  We have a way to update RFCs today for errors
in pointers.  If you take the NTIA thing out of th machine, everything
still runs.  The domain name has nothing to do with that.

(Randy Bush)  We got here by riding on the front of the surfboard not
lying down and paddling.  When ICANN was formed, tried to get a
librarian and a 15 year old with a modem on board.  We are not
responsible for ourselves, we are responsible for the Internet.  We are
dealing with one of the least transparent and least accountable
organizations in our entire domain (ICANN).  The horse will leave the
barn, and it is our last chance to get transparency and accountability
built in to what goes forward.  They have cash and more lawyers than we
have protocols.  And we’re arguing over a domain name.

(Andrew Sullivan) My view is that we’re trying to solve for a one-time
transition.  There rare some problems that are potentially dangerous in
the future, and there are risks in that, but there are also risks in
opening this far future up for discussion.  There are things in this
agreement that need to be moved around so they are incorporated into our
agreement.  We do not need to worry about the case where the operator
goes berserk and we need to have an emergency separation with no
graceful transition.  That is insane.  We need to engineer a practical
solution for the problems we actually have.

(Colin Jenkins) don’t see that the domain name itself is a must have; it
is not critical.  There are options about what will be available going
forward.  When we say our numbers HAVE to be at this domain that we
don’t have control of us unnecessary.

(Alissa Cooper) Leslie mentioned about the public domain; in that case,
the term IAOC appears there because we don’t want the IETF to ask the
other parties for this.  Don’t care who asks the other parties to make
the declarations.  It would be nice if any party who could reasonably be
claimed to have content of the registry makes clear that they don’t
would be good.  Keep in mind that the consumer of this is the NTIA and
ask what the NTIA should do with the nice to haves.  Their choices are
somewhat limited.  And to respond to Russ Mundy, the expectation is that
there are substantive changes that need to be made to prevent the system
will be sent back to the operators, but there should be only one final
document sent to the NTIA.

(ekr) To be clear, we’re talking about a list of numbers on a website.
IANA curates that list, and the curation is important but the
maintaining the website is not.

(Andrei Robachevsky) When the NTIA announcement came, we though tee had a simple
task because we are happy with how things work.  So we need document the
status quo, and the document mostly does that.  But there are still some
changes.  The MOU operates in a changing legal environment, so we need
to do a legal diff on the MOU regarding changing conditions.    We
should instruct the IAOC to do this legal advice, and supplement of rthe
missing NTIA contract.

(Dave Crocker) [jabber] IANA is critical operations infrastructure, but
what’s been said is the stability is a bad thing.

——

AD review came in this morning from Jari — see mailing list
No blocking comments.
(Eliot Lear) I agree with most comments except the last one. To be discussed.

——
(Russ Housley) in an earlier discussion, there was a decision to ask the
IAOC to consider jurisdiction and arbitration text.  It was noted that
if either party (ICANN or IETF community) is really upset with the
other, there is a clause to end the relationship. But there is another
clause for disputes less drastic, and those say the IAB decides.  Do we
need to discuss jurisdiction in any more detail?  It sounds like the IAB
decides.

(Jari Arkko) We found out late about this text, and my general desire is
to point to our existing tools rather than instruct the IAOC to add
additional SLA clauses in our contracts.  Don’t invent something new.

(Brian Carpenter) we have already had that discussion.  The IETF has
done well by avoiding the word jurisdiction, and we should avoid it here
too.  We have managed to avoid getting our debates out of courts (patent
litigation aside).

(Marc Blanchet) To be inserted into the draft.

——
Wrap up
(Marc Blanchet, as co-chair)
Do you agree with the changes listed in the section titled “I think we agree
on”? [strong agreement, a single person against] (Peter Koch) Not really happy
with the final bullet item, the coordination of special use domain names. (Marc
Blanchet) Except of the last point in the list, do you agree with the rest?
(Peter Koch) Yes, but some other mentioning of ICANN and the role of the
various ICANN bodies that were proposed here. Will sent a comment to the list.

Mention of .ARPA
Didn’t have any comment so far.
(Alissa Cooper) this is different than what she thought you were
proposing earlier.  Thought you were talking about what registries were
in scope for this document.  In this section, your’e saying no sections
are needed.  So why do we need to specifically call out .ARPA?  (Eliot)
if the IANA function operation changes, does this function change with
it or not?  (Alissa) so we’re expecting different things to happen in
different protocol parameter registries?  (Eliot) do you think that
.ARPA is a protocol registry?  (Alissa) we will have to be more clear.

(Olaf Kolkman) I started this conversation by intro ducting ARPA in this
text.  .ARPA is mentioned specifically in addition to protocol
parameters in the contract, so we should explicitly mention it in our
response also.  Not sure if it needs to be exactly here, but that’s the
context.

(Alissa Cooper) Agree that it needs to be separate in the list, but it does not
need to be handled in the protocol registry component.

(Eliot Lear) Can we talk about this on the list or in person to figure out
where this should go?

(Andrew Sullivan) The dispute here is that this is another one of the
things that the current IANA registry operator is doing for us, and we
need to list it.  But it doesn’t need to be called out separately with
it’s own special language.  (Eliot) if it is part of the protocol
parameters registry, we can define at such in the first part.

(PHB) No, it is more complicated than that.  .ARPA is really complicated
because you have the reverse DNS in there, and so it’s an order between
two spaces.  This is more subtle than you might imagine, and we’re not
the people that asked for this change.  ICANN did, and ICANN will get
the most benefit from this.  So why are we saying we will only do
reasonable negotiate?  Be unreasonable and just take them.

(Andrew Sullivan) .ARPA does not include the reverse; reverse is
delegated separately underneath it. We are only talking about the
TLD .ARPA, not the sub-delegation. It is just another protocol
parameter and should go in the first list.

(John Levine)  To the extent there is a conflict in .ARPA, the
administrative of that is a technical task that the IAB does as
requested by the RIRs.

(Brian Dickson) Wondering with the NTIA role going away, are we
concerned about the ability to hold ICANN to task?  Are there ways we
can exert more control over ICANN?  Such as delegating to ICANN all the
name space except specific components, and so exert control over the
root name space.

(Jari Arkko) That is outside the scope of this WG.

Outcome of .ARPA is : new version of text, where the .ARPA will be
included as a kind of protocol parameter.

———
(Leslie Daigle as co-chair):  We have good direction on most elements, and so
we are coming out of WG last call (with some one big huge question mark re: the
question of IANA.org marks).  There is pushback on mentioning IANA.org at all
in this document, and the reasons for that come back from the standpoint that
this isn’t solving the question on the table at all. What we need to do now is
find a solution to the problem of the existing transition and not try to solve
for some future emergency.  Should rephrase the section of text that keeps the
operator obligations in existing contract, point three drops out altogether,
and point two should be reframed just say that there is work done to ensure
best effort clarity and continuity in face of existing work.

(Ted Hardie) Is there more than that we really need to say than one and two?

(Leslie Daigle) No.  The intro paragraph will need to be revise.

(Jon Peterson) Let’s take this to the list.

(Leslie Daigle) It will be helpful if more people express this on the list.

(Ted Hardie) Take a hum on removing the IAOC bit?

(Leslie Daigle, as co-chair): If you agree with dropping the phrase that is
about the IAOC…  Please humm. [loud hum] Unanimous

(Marc Blanchet, as co-chair): Expecting a new version of the draft to reflect
today’s discussion.