Minutes for IANAPLAN at IETF-90
minutes-90-ianaplan-2

IANAPLAN BoF at IETF 90
Toronto, ON, CA
2014-07-24 09:00 local time (13:00 UTC)

Agenda:
- Preliminaries and agenda bash (co-chairs)
- Introduction (co-chairs)
- NTIA transition in the larger Internet community, and the
Coordination Group (Alissa Cooper)
- What does the transition mean from an IETF and IAB perspective? (Andrew Sullivan)
- Discussion
- Review of proposed charter (co-chairs)
- Discussion of charter
- Close/any final questions (AD)

------
Notes:

- Co-chairs: Marc Blanchet, Andrew Sullivan

- Preliminaries and agenda bash
Scribes: Heather Flanagan (notes), Ted Hardie (jabber)

- Introduction (Marc Blanchet)
This is a working group forming BOF. An important goal is to see if there is
consensus in the community to form a working group. The typical set of BOF
questions will be asked at the end of the meeting.

History from IETF89 igovupdate (see slides)

- NTIA transition in the larger Internet community, and the
Coordination Group  (Alissa Cooper)
(slides 1, 2) Brief and recent history
(slide 3) NTIA's transition plan criteria
(slide 4) ICANN facilitation
(slide 5) IANA Stewardship Transition Coordination Group (ICG)
(slides 6, 7) Draft ICG charter
(slides 8, 9) Draftier request to communities
(slide 10) Even draftier timeline
(slide 11) Next steps
(slide 12) References

Q&A:
Olaf Kolkman (wearing no hat) -- we will have to ask process questions
as we go, and we will have to invent some process in order to answer
questions you come up with as representatives in the ICG.  One
question now is about the finalized charter.  That means that the
charter that you presetned the outline of is rough but very advanced
draft.  Is there an expectation on the ICG side that you will need
something of a consensus about that charter and if there are un-eases
in the community can you bring those back.  If you were to ask that
question, I would say the charter is in pretty good shape, clearly
pointing out that the IETF is one of the customers of this thing and
identifies us almost explicitly.  I would support the charter, but is
there is an ask from you to the community about endorsing it?
Alissa: We felt pretty good about the charter, but we want input from
the community.  The charter is open for discussion for two weeks
(until next Friday?)  For matters of internal organization of groups,
it is more important to set a marker down and keep moving than to run
a big consensus process for every single thing that the ICG does.  The
communities need to focus more on their own processes.

Lee Howard: did not understand about testing.
Alissa: in the IETF it is hard to wrap your head around.  We do not
interact with NTIA now, so testing how we will interact without NTIA
is difficult.  But in other situations, if a new accountability
structure is created, then you want to run your system that way for a
few months to see how it goes.  The other thing that has implicitly
fallen in the testing bucket is scenarios analysis.

Brian Carpenter: I have complained about the length and complexity of
the charter on email, but did NOT complain about the wording.  The
other comment is about the polite argument being held with Avri via
email.  There is something we can test - if there are liaison
relationships for coordination within the major blocks, that we
haven't been explicit about in the past, those new liaison
relationships would be testable.

Jari Arrko: More info on testing and an example.  The arrangements for
IANA are not a static thing.  Every year we add new things to the
contract.  This year it was a requirement for an audit that would show
the database or record location function is following the policies set
by the IETF.  Once this is run the global community can see that
things are working.  Since it is in this years SLA, it will not be
available now, but look for it next spring.


- What does the transition mean from an IETF and IAB perspective? (Andrew Sullivan)
(slides 1, 2) Stuff requested
Russ Housley: missing an important accountability mechanism which ties
to our normal appeals process.  Important to talk about the
fine-grained mechanisms as well.
Andrew: Absolutely correct.  We have running process to handle things.
(slide 3) A suggestion
Russ Housley: Please explain the bullet, because we do not have a
contract with NTIA, we have one with ICANN
Andrew: the point I'm making is that we have a contractual
relationship and that isn't changing; their contractual relationships
are what's changing.
(slide 4)  Have we done everything?

- Discussion
Brian Carpenter: I am an advocate of "if it ain't broke, don't fix it"
but something you said before is complacent, and that is that
"everything is working."  We need some self-examination before we can
really make that determination.  I am of the opinion that we don't
have major things to fix, but we should look at any cases of
coordination failure that might exist today.

John Klensin: As an observation, channeling conversations on the list.
There is a critical issues that differs if the accountability
procedures are self examination, or if there is an opportunity for
review by an outside community.  We are operating in self-examination
mode and have done so successfully, but at various times we expect
other organizations to operated in external evaluation modes because
we don't think their self-examination modes don't work.  If we expect
other organizations to be accountable to external review, we may be
asked to defend what we do more strongly than before.

Andrew Sullivan: the observation on the previous slide, that the contractual
relationship that's changing is between IANA and NTIA.  The ones
between us and IANA are not changing.  Our relationship is an external
body that's overseeing that policy.  We are not responsible for the
other part.  Do you think you're talking about the NTIA oversight of
IANA or of other communities and their oversight of stuff.

John Klensin: you are engaging in hair splitting.

Russ Housley: responding to that point, we don't have a contract with
NTIA, that's going away.  We need to make sure a spart of this
analyssi that our contract with IANA is sufficient to get everything
we need in the new world.

Peter Koch: much of this is an education exercise.  Documenting
practice is a good start.  There are a couple of things developing in
the recent past, that we ourselves are reacting the boundaries of the
MoU between the IETF and IANA/ICANN.  The timezone database is an
example.  The IETF is one customer of the IANA/ICANN; assuming the
IETF has the monopoly on protocol parameters might seem strange to the
rest of the world.  The IANA taken as a metaphor as the policy
development for our registries.  An example is the possibility of
someone not getting a code point assigned they want pointing at IANA
as IANA's fault.  "Do nothing" is one option, but would like an escape
route or a plan B that may not be for the ICG, but needs to be
discussed internally.  That might include adding figures to the
contract about the costs of the whole thing at the moment so we could
put up a tender for a new operator.

Elliot Lear:  Agree with Russ on the overall point, that we should be
looking to see that we've covered everything.  But I want to make sure
we cover metrics.  Russ has suggested that needs to be handled through
the IAOC, and so I like what you have in the charter.  Second point,
one of those little nits, when we wrote the timezone database we made
the deal with the ICANN not the NTIA.

Brian Trammel channeling Eric Burger: Please don't take this as an
opportunity to change things.

Jari Arrko: Strongly support the idea presented here not to do too
much of a change; stability is important.  But am respectful of the
comment that that's being a bit complacent.  This is a good direction,
this is the direction we are thinking of.  At the end of the day we
need the document that explains all the different cases and all the
details, and will identify if there are other pieces needed.  Also
want to mention this "plan B"--those are in our minds, and we are
considering them.  We do have the IAB and iana program thinking about
this whole system, and are considering plans for different scenarios.

Lars-Johan Liman: This is a good starting point.  One thing that could be
added, even if we don't have direct contractual relationship with
NTIA, if we remove it and replace it, we must look at the pressure
balance in the system because it changes.  The replacement may have an
impact on us.

Bernard Aboba: It makes sense not to change anything with the
operator.  In terms of existing contracts, many clauses in the
contract between NTIA and ICANN are things we asked for, including:
intellectual property protections, transition itself is specified
itself, the IETF is contractually through user documentation becomes
rule setter for IANA, ICANN cannot set policy.  There are a bunch of
protections in that contract that we don't want to lose.

Jari Arrko: That is exactly right, and what I meant that we must write
that document to captures those details.

Leslie Daigle: Liman already made the points I want to make.  "If it
ain't broke, don't fix it" but, when Russ framed it as "does the
current MoU work even if the NTIA contract with ICANN goes away"
that's missing the point that the NTIA contract is not just going to
go away, some other frameworks will take its place.  Our existing
contractual documentation will not be accurate.  It is a good starting
point, but it is the fourth bullet on A Suggestion slide that I object
to.  Last three words should be, observe what's going on in the rest
of the conversation and when the dust settles, is the IETF the
generator of protocols and parameters, and are we the only one?

Alissa Cooper: Agree with the general thrust here.  Relaying a
conversation with the ICG last week, our process and relationships
that we have are well understood by people in this room.  The
transition plan needs to be understood by a broader audience.  You
can't just throw together a list of references and expect people to
understand.  This plan will go well beyond the IETF to people not
familiar with our systems.

Russ Mundy: happy to be a member of the ICG, but not speaking with
that hat on.  One of the things that has caused help and confusion is
the NTIA contract itself.  It is big and long and painful, but it does
contain many useful pieces of information.  Bernard made good points
earlier, that some of those things were placed in that contract at the
request of the IETF.  Whether or not all of them, some of them, more,
less, different still belong there needs to be examined.  The bigger
thing is that the IETF has the easiest problem to solve, with the
numbers people being second, but the names people having the hardest
of the problems.  Tht IETF needs to document things as quickly as they
can because this can become the example that the rest of the community
can take and follow.  The IETF has the most well-defined set of things
to be looked at and will help the others.

Jari Arrko: agreeing very much with Russ Mundy.  Continuing the thread
of Leslie and others, re: the need to interact with the rest of the
system and document those interactions.  The rest of the system does
change, and we don't fully understand what those ways are, and we need
to understand that better.  There is overlap and interaction points
between the broad categories of things that we need to document and
understand.  The NTIA is going away, but I don't think it is being
replaced by another "super entity" that would have special oversight
over things like port numbers.

Larry Masinter: I made a point on the list that some of the IANA
registries are not working so well, such as around URI schemes and
MIME parameters, esp. at the application level where people don't
bother registering things, and where other SDO can add things to the
registries without consulting the IETF.  The response was
satisfactory, in that those are part of the existing relationship.
Not sure if those are going to be handled later, or handled now in
figuring out the new contract(s).  The system we have resolve that, it
would help to make it more explicit that if you want to say IANA
should offer a way to insert comments in the registry, how would we
institute that in the existing and new framework?

John Levine: Agree with the suggestions that there are things in the
IANA contract that we should look at, but one of the most important
things to remember is the fact it doesn't cost us anything.  Should
the contract go away and the cost go up, that could be a problem.
Jari Arrko: responding to the cost issue, not too worried about the
cost part.  The reasons why it is set up like it is will continue
after a transition, regardless of whether NTIA is there or not.  The
motives remain, and even if things do change, cost shouldn't drive the
good solutions to our problems.  The good of the internet should drive
the requirements.


- Review of proposed charter
(slide 1) Content of charter
draft charter has been circulated


- Discussion of charter
John Klensin: you have captured my objection to the charter.  A
charter that long and complicated is almost equivalent to no charter
at all.  I don't know how to fix it, but it's a problem.
Andrew: there is a lot of background in there that I felt needed to be
captured somewhere, but without it, anyone who came to this without
that material would be lost.

Brian Trammel channeling Eric Burger: I was convinced by Andrew's
thought that we needed a venue for consensus.  I don't see this
charter as longer as more complicated than others, and that newbies
would be confused without the background.

Eliot Lear: Agree with Eric Burger; I don't think that if you go down
to the milestones, these are fairly general.  The only question is
whether the dates, esp. the May dates, are possible.  Dates in
charters tend to be so fluffy.  The charter is well written and a good
starting point.  The one question is RFC 3777 - don't know what
updates to that means in this context

Leslie Daigle: want to make the IETF aware that the different groups
don't understand IETF function.  Having a WG makes this an obvious
landing point for people not already in the IETF.  For them, there
needs to be very clear context setting.  Whether that belongs in the
charter and listing them out, that makes them something of a target.

Larry Masinter: we are not setting them aside for future
consideration, we are assuming they will be handled in the framework
that will be established.  Will propose a better sentence on the list.
Bernard Aboba: one way to think of the existing contract is that the
ICANN can update those documents at their discretion.  The IETF can
have a WG to update stuff, but that has nothing to do with the
arrangement.  A best transition plan allows you to update these
outside the transition plan.

Alissa Cooper: The WG might want to review, comment, and evaluate
proposals that impinge on the IETF, not just protocol parameters.
Jari Arrko: Bashing the traditional working group forming BoF
questions.  Do we believe we need to have a forum for this topic?

Bernard Aboba: One other comment, under RFC 6220, there is an org that
owns the contracts with IANA, and that's the IAOC.  Need to consider
how this WG would work with the IAOC.

Andrew Sullivan: there is text in the charter that says the contract must be
negotiated with the IAOC; is that sufficient?

Jari Arrko: This WG is to discuss the IETF processes and RFCs about
how we view the IANA organization from our perspective, and the actual
execution of those process belongs to other organizations such as IAB,
IANA, IAOC.

Brian Trammel as Eric Burger: Is there a real problem here?  Yes, but
not a typical IETF problem.  It is not a technology problem.

Andrew Sullivan: in order to satisfy this, the first question that the way you
expand problem is "documentation to be done and agreed to,
investigation of the various contractual language and whether there
are gaps, and understanding of what the agreement of the community
is." those are the potential problems a WG could solve in this case.

CONSENSUS (yes: loud hum; no: silence) in the room on there being a problem here
MAJORITY hum, but some level of no on understanding the problem

Geoff Houston: no, I don't understand the problem.  The NTIA role in
terms of what we, the IETF, and our protocol parameter registration
function has, the NITA role's is nothing.  If the topic is the
transition of the NTIA role to something else, our function shouldn't
change.  On the other hand, there does seem to be a view of "while
we're at this, ..." re-engineer because we can.  If that's the problem
you want to solve, that's fne, but it has nothing to do with the NTIA.
If you are looking to provide the NTIA that they can step back and it
would be fine, the worst thing you could do is to say "we're going to
change everything".  This is simple: they weren't editing our protocol
parameter function, they were saying ICANN can do the job.  If we were
confident before, we should say we're confident now.


Olaf Kolkman: I hummed twice.  That is debating with Jeff; I am in
Jeff's camp re: that we don't have a problem.  We have a good
relationship, we have good documentation on what we expect from the
vendor.  But I am also in the camp that we are not on an island.  We
work with other communities in a complex environment.  We have an
opportunity to explain/make clear that what we're doing is rock-solid.
If the problem statement is that, I'm on board.  If the problem
statement is to change everything, I agree with Jeff.

Pete Resnick:  Generally agree with Jeff that we are rock-solid, and
we should express that.  Even if I go completely down that pass, an
IETF WG documenting that is a fine thing; that expresses IETF
consensus.  One point that's a bit worrying, and that is the NTIA is
one stick we're pulling out of the pile that can shift the pile quite
a bit.  This WG should consider if there are side effects that would
impact that stability.  We should look carefully at those possible
side effects.  It is worth forming the WG, we should look at those
effects, we should do as little as possible to change the state of
affairs.

Russ Mundy: In agreement re: type and quantity of change.  I've read
through all the contractual material.  The way it is written, it's not
clear how many things in there that relate to this functionality, are
things that were really desired by the IETF and put in because the
NTIA were trying to be helpful, or if they were things thought up by
bureaucrats in Washington.  This is something the WG need to give
careful thought to.  Would put the things that go on relative to that
functionality into two groupings.  One, the mechanical, operational,
here are things that happen.  Two, how do we measure the quality with
which this is done.  These are things that show up in the NTIA
contract.  How much of this quality kinds of things are needed esp, if
we're happy with things today.

Jari Arrko: In response to Russ Mundy, those quality controls are in
our SLA, so we're better off than people who just read the contract
language might thing.  Next point, agree with Jeff Houston.  There
isn't much to do, but we're letting ourselves be confused by the
"problem" word.  In retrospect, a better way to phrase that is "Does
the IETF need to express it's opinion on how IANA will be going
forward?"  Of course yes.  That guidance might be "don't change anything"

Alissa Cooper: I think if there is a question about whether we need to
respond to the NTIA request for the piece of this that is the purview
of the IETF, that question should be asked.  If people thinks we don't
need to respond, that's important to know.  If people thing we should
respond but not via a WG, that should be known too.  There might be
people who thinks we don't need to respond to this; thought that is
what Jeff was suggesting.

Bernard Aboba: How many people in this room know what the iproc is?
That is the group that includes members of the ICANN, IAB, IAOC, that
oversees the IANA function.  It might be a good idea to document the
workings and procedures of that organization.

Andrew Sullivan: to address what Jari and Alissa have asked for.  

- Do we need to respond to the NTIA, yes or no? (majority yes; CONCENSUS) 
- Do we need we need a WG to do that, yes or no? (large hum, very few no) 
- do we know what else we need if no? (for those
who said no, have no alternatives)

Jari Arrko: I do think we need a WG.  We do have the IAB and
ianaprogram who are formally responsible for this.  They have done
most of the leg work.  This is an important topic, and you should get
the IETF opinion on this.  The WG should confirm the opinion and work
with the ianaprogram.

Geoff Houston: the IAB has a responsibility for a number of things,
including the RFC Editor and the protocol parameter registry.  We
handled the RFC Editor transition well without a WG.  The function
fell within the natural parameters of the IABs role.  They could work
within the administrative framework of the IETF.  We are not changing
what we expect of the IANA role.  We still think it is a contracted
function.  This isn't a difficult problem, and to give the NTIA
confidence that they were not a foundational piece, we don't need
something special. It is an IAB function that should be documented and
sent to the NTIA.  Don't create new stuff just for this.

Leslie Daigle: It is a comforting thought to have the IAB take care of
it, but the difference between this and the RFC Editor situation, our
view of the universe is not the totality of the universe.  It is not
as straightforward as the RFC Ed situation.  The community will expect
to have had an opportunity to provide input.

Brian Trammel: Agree with what Leslie said.  There is a need for, at
minimum, a venue in which we can evaluate IETF consensus in a smaller
room.  I would like to have an alternative to taking this to ietf@ietf.org

Ran Atkinson: Mostly agree with Jeff Houston's analysis.  The minor
difference is, it could be useful to have a WG to demonstrate to the
rest of the community that we collected input.  But I don't want the
output of this to be more than "the way it works is fine; the IAB
represents the IETF in this manner, and we want to continue to have
the kind of independence from third parties going forward.  Do not
micromanage the IAB, but provide a forum for input, and reinforce the
notion that the IAB is allowed to act on behalf on the IETF on this topic.

Andrew Sullivan: Repeating something on the list, normally this would
be the IAB, but the NTIA has explicitly mentioned the IETF as a
specific group, separate from the IAB, to get input.  If the NTIA
wants the input of the IETF, we only have one way to do that.

Jari Arrko: The IAB and the program is in charge and they should do
most of the work.  It would be useful for the IAB to have a place in
the IETF to collect consensus.  We have done it in different ways
(e.g., ietf@ietf.org) but that's a detail.  We don't want a WG that
comes up with crazy ideas and tries to redesign the whole system, but
that's not the intent.  This is a place to confirm the IAB's opinion.
Why do we need this?  it's not just because the NTIA mentioned our
name.  It's the fact that when we go to other groups, saying "the IETF
community believes this" that has a huge amount of weight.

Erik Nordmark: Agree with a number of things that have been said, and
trying to find a path forward.  We are looking at the ianaprogram as a
design team that feeds input into a WG.  The key thing is to write
down what isn't already written down in an RFC, some things that are
only in the contract language now.  As the different communities come
together, there might be input that we have to respond to, and there
needs to be a place to have those discussions.  Being able to have a
place to gauge IETF consensus to capture things not written in RFCs,
and a place where we can react.

Bernard Aboba: to elaborate on something Jari said.  It would be
useful to have IETF consensus on points in the NTIA contract.  If we
have input that the intellectual property points are mandatory, and
the consensus is clear, that's very useful input. This WG will
probably not be useful in that some of the broader work has come with
very very short time frames (like 2 weeks) and those things should go
to the IAB where they can be handled more expeditiously.

Ted Hardie: +1 what was said about the timeline problem.  It may be
useful to take Erik Nordmark's formulation and apply a bit of
recursion.  The ianaplan group is both a design team for the WG, and
the WG is a sounding board for the design team responses to the NTIA.

- Close/any final questions
Andrew Sullivan: does the sponsoring AD (Jari) have any further questions?
Jari Arkko: didn't hear a lot of opposition.
Andrew Sullivan: some adjustment to the charter needed, but not radically
wrong.  So we have heard what we need to hear, yes?
Jari Arkko: yes, we have talked about the overall situation, the need to
support stability but make sure to document anything missing from
existing documentation.  The IAB and its program in charge of the
issue, but they will use any WG list as a sounding board and a place
to confirm consensus.