Subject: [Ianaplan] teasing the issues apart -- IANA.org, authoritative IETF repository

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Thu, 09 Oct 2014 17:50:21 -0400

Hi,

I feel there is still a discussion to be had here, though I am sensitive 
to the fact that we're spelunking in a pretty big rathole at this time.

Trying to tease issues apart to see if it helps the discussion -- from 
the couple of days' messages, it seems that:

1/ Some people think the IETF (Trust) is the obvious home of iana.org . 
  Others don't believe that and/or think it would be a stretch to get 
the rest of the world to agree.

2/ The issue that Eliot opened on the document was to address how best 
to go about "requiring the current operator make clear upon termination 
that their copy is no longer the version that is maintained on our 
behalf, where at on[e] point (today and hopefully long from now) it was. 
  " (Eliot's words).

I think "2/" has been characterized as rational contractual behaviour, 
and it seems like a worthwhile problem to address.  But, for now, I 
would like to suggest we take discussion of "1/" off the table.  The 
challenge is that the most obvious way to achieve 2 is to bind iana.org 
and the registries, tightly, as they are today.

My question is: is it the only way?

During the interim meeting, when I, too, didn't think we were talking 
about iana.org, I suggested that a future SLA could require the labeling 
of the IETF protocol parameter pages with a statement that they are IETF 
protocol parameters, and that would have to be withdrawn at the end of a 
contractual agreement.

Stephen Farrell has opined that we can label everything going forward 
with the BLAHBLAH considerations section (though that does beg the 
question of what happens to old RFCs with registries that are still 
assigning values).

Other thoughts?

Leslie.

-- 

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Oct 2014 19:22:27 -0700

I am not sure it really matters if we have the "BLAHBLAH" considerations
section or the IANA considerations section.  The main issue is what happens
when a potential consumer of registry information goes to iana.org.  Today
at http://iana.org/ there are pointers to each of the major functions -
Domain Names, Number Resources and Protocol Assignments.

If one or two of the communities decides to select a new operator (but not
*all* communities make this decision) then the simplest solution is for the
links to those functions to be changed to point to the new contractor's
site for that function.

Only in the case where *all* the communities decide to move to another
vendor would there be a need to reassign ownership of the iana.org domain
to another operator.  *Which* operator should probably not be an IETF
decision alone, since the other communities geare also affected.

I would also note that the NTIA required ICANN to file a transition plan
(presumably covering at least some of the issues we are now discussing on
this list) in April 2013.  Rather than speculating about what property
might be relevant to the transition and how it would be handled, might it
not make more sense to obtain the transition plan?

It is worthwhile to understand that the transition plan that was filed
represents a promise that ICANN has already made to NTIA about how it would
handle a transition.  Rather than asserting that such a transition is
irrelevant, or that equivalent arrangements could not possibly be of use to
use, I would suggest that "due diligence" demands that someone (maybe the
IETF trust) at least examine the existing transition plan and determine
whether its arrangements are relevant or not.

On Thu, Oct 9, 2014 at 2:50 PM, Leslie Daigle (TCE) <[email-masked]
> wrote:

> Trying to tease issues apart to see if it helps the discussion -- from the
> couple of days' messages, it seems that:
>
> Others don't believe that and/or think it would be a stretch to get the
> rest of the world to agree.
>
> 2/ The issue that Eliot opened on the document was to address how best to
> go about "requiring the current operator make clear upon termination that
> their copy is no longer the version that is maintained on our behalf, where
> at on[e] point (today and hopefully long from now) it was.  " (Eliot's
> words).
>
>
> I think "2/" has been characterized as rational contractual behaviour, and
> it seems like a worthwhile problem to address.  But, for now, I would like
> to suggest we take discussion of "1/" off the table.  The challenge is that
> the most obvious way to achieve 2 is to bind iana.org and the registries,
> tightly, as they are today.
>
> Stephen Farrell has opined that we can label everything going forward with
> the BLAHBLAH considerations section (though that does beg the question of
> what happens to old RFCs with registries that are still assigning values).
>
> Other thoughts?
>
> Leslie.
>
>
> --
>
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 09 Oct 2014 23:55:45 -0700

Hello,
At 14:50 09-10-2014, Leslie Daigle (TCE) wrote:
>During the interim meeting, when I, too, didn't think we were 
>talking about iana.org, I suggested that a future SLA could require 
>the labeling of the IETF protocol parameter pages with a statement 
>that they are IETF protocol parameters, and that would have to be 
>withdrawn at the end of a contractual agreement.
>
>Stephen Farrell has opined that we can label everything going 
>forward with the BLAHBLAH considerations section (though that does 
>beg the question of what happens to old RFCs with registries that 
>are still assigning values).
>
>Other thoughts?

Whether it is though IPR or iana.org the result is that there is a 
restriction on the (parameters) repository.  If an entity other than 
the IETF were to take over the registries it would have to change 
some of the registration procedures to:

   (a) Something that does not point to an IETF RFC.

   (b) Something that does not require IETF action.

One alternative is to label https://www.iana.org/protocols and 
http://www.ietf.org/assignments/ as the IETF Protocol 
Registries.  Anyone hosting the repository and attempting to do (a) 
or (b) would not be able to use "IETF" in their label for the 
repository.  The alternative is:

   (i)  not overtly restrictive; and

   (ii) does not require any change to http://www.ietf.org/trademarks-list [1]

I suggest renaming "IANA Considerations" to "IETF Protocol Parameters 
Considerations".  It is not possible to change the old RFCs [2].

Regards,
S. Moonesamy

1. The matter has been discussed previously on ietf@.
2. The reason for that is left as an exercise to the reader.

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 10 Oct 2014 09:14:50 +0200

I agree with what Bernard said.

IMHO, as long as ICANN continues to host iana.org (as part of providing
at least one of the IANA functions, or as a hosting service alone) it
must point to the authoritative registry location in case a new operator
for a function is selected.

Andrei

Bernard Aboba wrote on 10/10/14 04:22:
> section or the IANA considerations section.  The main issue is what
> happens when a potential consumer of registry information goes to
> iana.org <http://iana.org>.  Today at http://iana.org/ there are
> pointers to each of the major functions - Domain Names, Number Resources
> and Protocol Assignments. 
> 
> If one or two of the communities decides to select a new operator (but
> not *all* communities make this decision) then the simplest solution is
> for the links to those functions to be changed to point to the new
> contractor's site for that function.  
> 
> vendor would there be a need to reassign ownership of the iana.org
> <http://iana.org> domain to another operator.  *Which* operator should
> probably not be an IETF decision alone, since the other communities
> geare also affected. 
> 
> (presumably covering at least some of the issues we are now discussing
> on this list) in April 2013.  Rather than speculating about what
> property might be relevant to the transition and how it would be
> handled, might it not make more sense to obtain the transition plan?
> 
> represents a promise that ICANN has already made to NTIA about how it
> would handle a transition.  Rather than asserting that such a transition
> is irrelevant, or that equivalent arrangements could not possibly be of
> use to use, I would suggest that "due diligence" demands that someone
> (maybe the IETF trust) at least examine the existing transition plan and
> determine whether its arrangements are relevant or not.   
> 
> On Thu, Oct 9, 2014 at 2:50 PM, Leslie Daigle (TCE)
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     I feel there is still a discussion to be had here, though I am
>     sensitive to the fact that we're spelunking in a pretty big rathole
>     at this time.
> 
>     Trying to tease issues apart to see if it helps the discussion --
>     from the couple of days' messages, it seems that:
> 
>     1/ Some people think the IETF (Trust) is the obvious home of
>     iana.org <http://iana.org> .  Others don't believe that and/or think
>     it would be a stretch to get the rest of the world to agree.
> 
>     2/ The issue that Eliot opened on the document was to address how
>     best to go about "requiring the current operator make clear upon
>     termination that their copy is no longer the version that is
>     maintained on our behalf, where at on[e] point (today and hopefully
>     long from now) it was.  " (Eliot's words).
> 
> 
>     I think "2/" has been characterized as rational contractual
>     behaviour, and it seems like a worthwhile problem to address.  But,
>     for now, I would like to suggest we take discussion of "1/" off the
>     table.  The challenge is that the most obvious way to achieve 2 is
>     to bind iana.org <http://iana.org> and the registries, tightly, as
>     they are today.
> 
>     talking about iana.org <http://iana.org>, I suggested that a future
>     SLA could require the labeling of the IETF protocol parameter pages
>     with a statement that they are IETF protocol parameters, and that
>     would have to be withdrawn at the end of a contractual agreement.
> 
>     ------------------------------__------------------------------__-------
>     Leslie Daigle
>     [email-masked] <mailto:[email-masked]>
>     ------------------------------__------------------------------__-------
> 
>     _________________________________________________
>     Ianaplan mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/ianaplan
>     <https://www.ietf.org/mailman/listinfo/ianaplan>
> 
> 
> 
>

---

From: Jefsey <[email-masked]>
Date: Fri, 10 Oct 2014 09:58:36 +0200

>for a function is selected.

Andrei,
the point is not what others "must" do, but what if they don't do.
jfc

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 10 Oct 2014 08:17:54 +0000

On Oct 9, 2014, at 11:50 PM, Leslie Daigle (TCE) <[email-masked]<mailto:[email-masked]>> wrote:

During the interim meeting, when I, too, didn't think we were talking about iana.org<http://iana.org/>, I suggested that a future SLA could require the labeling of the IETF protocol parameter pages with a statement that they are IETF protocol parameters, and that would have to be withdrawn at the end of a contractual agreement.

Stephen Farrell has opined that we can label everything going forward with the BLAHBLAH considerations section (though that does beg the question of what happens to old RFCs with registries that are still assigning values).

Other thoughts?

my €0.02

All of the above….

By that I mean: maintain IANA.ORG<http://IANA.ORG> as an entrance portal but have the actual authoritative source of the IETF data live elsewhere, and change the branding, in time the new place will become recognized and remembered as the authoritative source. We don’t have to think of this in terms of a discrete path but as a glide-path.

As long as the IETF is clear about where that glide path is heading to then I think that is fine. The execution does not need to take place in a year.

—Olaf

— — — — — — — — — —
Olaf Kolkman
(on personal title)

---

From: JFC Morfin <[email-masked]>
Date: Fri, 10 Oct 2014 14:14:35 +0200

At 23:50 09/10/2014, Leslie Daigle (TCE) wrote:
>at this time. Trying to tease issues apart to see if it helps the 
>discussion -- from the couple of days' messages, it seems that:

Thank you, this defines the IETF present questions rather well that 
are to be seen, at this WG/IANAPLAN through Andrew Sullivan's filter: 
"Our charter tells us to do the minimum possible. We should heed its 
instructions." However, we have to be careful at not doing less than 
the minimum required.

1. internet ownership

>1/ Some people think the IETF (Trust) is the obvious home of iana.org .

Yes. This makes the ISOC/IETF Trust the owner of the Internet 
technology. From a Libre point of view, RFCs should be subject to a 
Chinese wall and the internet use to be specified again from a user 
point of view in order to free the internet system from the IETF Trust.

>  Others don't believe that and/or think it would be a stretch to 
> get the rest of the world to agree.

Correct. It is unlikely that BRICS, Europe, and Libre will accept the 
IETF Trust terms at this stage. This may result in some TPP/TAFTA 
legal actions that will have no impact on the people's intelligent 
use of the internet. However, might affect IETF and ICANN's image and 
credibility and the US industry's interests.

>But, for now, I would like to suggest we take discussion of "1/" off 
>the table.

This would not make any sense, if (as most probably the rest of the 
world believes) "1/" is the key to "2/".

==> suggested action: to port the IETF deliverables (RFCs and IANA 
Tables) under a Creative Common license. From ISOC proprietary to 
Free. From a GSN pact to people's Libre.

2. tightly bind the future to the past.

>behavior, and it seems like a worthwhile problem to address.  The 
>challenge is that the most obvious way to achieve 2 is to bind 
>iana.org and the registries, tightly, as they are today.

This supposes that the real world is not the world described by the 
RFC 6852 paradigm, i.e. there is still only one global community 
network managed by ICANN and documented by ISOC.

3. Preventing the fork

>Other thoughts?

Unless the IESG, IAB, and ISOC say otherwise you are documenting an 
IETF fork between the past and reality, and between IEN 48 first and 
second objectives, when it could have been cooperation between robust 
end to end lower layers and intelligent fringe to fringe higher layers.

==> suggested action: to add to the RFC 3935 missions of the IETF: 
"to engage in the IEN 48 second objective along its core values, the 
RFC 6852 paradigm and the consequence of the US/NTIA removal, i.e. to 
share the global catenet among/with other technologies". This would 
translate into advocating a WG/RFC3935bis.

4. Conclusion

There are only three clarifications needed:

1/ is the NTIA transitioning its DNS or complete IANA oversight?
2/ is RFC 3935 or RFC 6852 the reference for the IETF or a consistent 
update of RFC 3869, 3935, and 6852 to be done?
3/ is the IETF wishing to constrain innovation to the past, or 
provide a stable basis to open future innovation?

This seems to clearly delineate the purpose of my appeal. Thank you.

jfc

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 10 Oct 2014 14:24:59 +0200

Dear Olaf,

You make a good point below.  The IETF protocol parameters are, at present, also published on the IETF site, at:

 https://www.ietf.org/iana.html 

That page says:

"The first choice below connects to the list of IANA Protocol Assignments maintained by the IETF Secretariat. The second choice connects directly to IANA's web page. 
"Be advised that there is a brief time period when the two directories will be out of sync. When in doubt, the IANA Web Page is the authoritative source page." 

As far as I can tell, the IETF protocol assignments page and the IANA protocol assignments page are identical (which is obviously desirable).

Since the source of the data is IETF, not ICANN, I don't understand why the ICANN version is considered authoritative.

In fact, I don't understand what the value-added is of ICANN publishing this information. Wouldn't it be sufficient for the IETF to publish it?

That is, why do we need anything other than:

 https://www.ietf.org/assignments/ 

I'm sure that people on this list will explain why this should also be published by ICANN and why that adds value.

If publication by ICANN did not add value, then the transition exercice could be greatly simplified: it would suffice to state that the transition plan consists of agreeing that the authoritative source of the protocol parameters is the IETF, and that the information is published on the IETF's web site.

Best,

Richard

  -----Original Message-----
  From: Ianaplan [mailto:[email-masked]]On Behalf Of Olaf Kolkman
  Sent: vendredi, 10. octobre 2014 10:18
  To: Leslie Daigle (TCE)
  Cc: [email-masked]
  Subject: Re: [Ianaplan] teasing the issues apart -- IANA.org, authoritative IETF repository

    On Oct 9, 2014, at 11:50 PM, Leslie Daigle (TCE) <[email-masked]> wrote:

    During the interim meeting, when I, too, didn't think we were talking about iana.org, I suggested that a future SLA could require the labeling of the IETF protocol parameter pages with a statement that they are IETF protocol parameters, and that would have to be withdrawn at the end of a contractual agreement.

    Other thoughts?

  my €0.02

  All of the above….

  By that I mean: maintain IANA.ORG as an entrance portal but have the actual authoritative source of the IETF data live elsewhere, and change the branding, in time the new place will become recognized and remembered as the authoritative source. We don’t have to think of this in terms of a discrete path but as a glide-path.

  —Olaf

  — — — — — — — — — — 
  Olaf Kolkman
  (on personal title)

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Oct 2014 13:30:14 +0100

Hiya,

> Stephen Farrell has opined that we can label everything going forward

"can" is a bit of a different statement, I meant "can, if we really
have to, not that we want to,"

> question of what happens to old RFCs with registries that are still

For existing registries I guess we'd do that write-only RFC that
amongst other things says "remember you used to go to iana.org for
this stuff, well now you need to go to <here> instead." I expect
it'd be painful if iana.org didn't put in place a 3xx or similar
(but equally expect they would) but even if they didn't do that
I think time would fix things - a few months of whatever would be
that epoch's stackexchange postings with the new URL would do it
for us, assuming that developers at that point in time care about
IETF RFCs.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 10 Oct 2014 14:43:49 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Leslie
> Daigle (TCE)
> Sent: jeudi, 9. octobre 2014 23:50
> To: [email-masked]
> Subject: [Ianaplan] teasing the issues apart -- IANA.org,authoritative
> IETF repository
>
>
> Hi,
>

Indeed, the foreseen absence of supervision by the US goverment opens a can
of worms, or, if you prefer, takes us into uncharted waters.  But there
seems to be some disagreement regarding how big the can of worms is, or how
big the unchartered waters are.

> the rest of the world to agree.

Actually it seems obvious to me that the IETF is the obvious home IANA.ORG.
Since the IETF is not a legal entity, it seemed to me that it should be
assigned to ISOC, which is the legal entity under which the IETF operates.
But Brian said no, from ISOC's point of view, it should be the IETF Trust.

IANA.ORG was apparently originally registered by ISI, which was provising
the IANA function for many years, see:

  https://web.archive.org/web/19971210061738/http://www.iana.org/

But the IANA function long preceded registration of that domain name.
Indeed, it was an emanation of the IETF from the very early days.  The first
formal reference to "IANA" seems to be in RFC 1060, of 1990.  It says:

" ... and in any case current information can be obtained from the Internet
Assigned Numbers Authority (IANA).  If you are developing a protocol or
application that will require the use of a link, socket, port, protocol,
etc., please contact the IANA to receive a number assignment.

   Joyce K. Reynolds
   Internet Assigned Numbers Authority
   USC - Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, California  90292-6695"

But the need to assign numbers had been identified much earlier, see for
example RFC 322 which dates back to 1972. The list mentioned in that RFC was
published as RFC 433, and it referred to Jon Postel as the "czar of socket
numbers".

So it seems to me that the IANA function was created way back then, and,
again, was and is an emanation of the IETF.

Historically, the IETF was not a legal entity and so it could not perform
the IANA function itself.  That's why it was performed by UCLA/ISI.

But today there is a legal entity that provides the IETF secretariat, so
that entity could perform the IANA function.

Whether or not it does is of course up to the IETF.  But, even if the IETF
decides to outsource the IANA function to somebody else (e.g. ICANN), it
seems to me that the IETF should control the brand name, and the domain
name, as well as the data and intellectual property associated with the IANA
function.

> and the registries, tightly, as they are today.

I'm not sure that I understand what you mean here.  It seems to me that the
most obvious way to achieve 2 is to agree appropriate language in the
transition plan, in the contract between ICANN and IETF for the operation of
the IANA function, and in ICANN's Bylaws.

Unless everybody agrees that it is sufficient for the IETF itself to publish
the data, in which case everything gets simpler because no contractual
arragements with outside organizations are needed.

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 10 Oct 2014 13:57:17 +0000

> I think "2/" has been characterized as rational contractual behaviour, and it
> seems like a worthwhile problem to address.  But, for now, I would like to
> suggest we take discussion of "1/" off the table.  The challenge is that the
> most obvious way to achieve 2 is to bind iana.org and the registries, tightly,
> as they are today.

I don't see any reason to take 1/ off the table, the fears about that are based on historical factors and are not founded in a rational assessment of the current situation.

There may be ways to finesse the issue, no need to stop discussion of that, but do not take iana.org off the table, I think it's a pretty simple issue.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 10 Oct 2014 10:42:24 -0700

Hello,
At 05:24 10-10-2014, Richard Hill wrote:
>As far as I can tell, the IETF protocol assignments page and the 
>IANA protocol assignments page are identical (which is obviously desirable).
>
>Since the source of the data is IETF, not ICANN, I don't understand 
>why the ICANN version is considered authoritative.

Please see below.

>In fact, I don't understand what the value-added is of ICANN 
>publishing this information. Wouldn't it be sufficient for the IETF 
>to publish it?

It has been published by IANA as part of the contract.  ICANN/IANA 
staff administer the assignments.  It is (currently) easier to have 
ICANN publish the information and it is better to identify IANA as 
the authoritative source.

It would cost the IETF to hire people to administer the information 
in the registries.  The easy path is to point to the IANA web 
site.  The problem is that there are some concerns about the 
contractual agreements.  Some people also do not like signing 
treaties.  In simple terms, the discussions are about filling a legal void.

Regards,
S. Moonesamy

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Fri, 10 Oct 2014 15:04:29 -0400

To be clear(er) -- my intention was to take discussion of it off the 
table _for now_.  Because everyone thinks the answer is obvious, it's 
just that not everyone thinks it's the same answer :-)   And arguing 
over obviousness is not moving us forward.

So, my hope was to focus rather on what specific problem are we trying 
to solve in the non-confusion aim.

Leslie.

--

---

From: Jefsey <[email-masked]>
Date: Sat, 11 Oct 2014 07:20:39 +0200

>treaties.  In simple terms, the discussions are about filling a legal void.

May be all this could be easily solved in buying back ianal.org?
jfc

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 11 Oct 2014 12:00:25 +0200

You say below:

> site.

But the actual information appears to me to be in RFCs, see:

That is, the IETF secretariat identifies specific RFCs that have an IANA
functions implication, and publishes those RFCs on the web page shown above.

Then ICANN does exactly the same thing, see:

  http://www.iana.org/protocols

So the IETF is already incurring whatever costs are needed, and it seems to
me that the easy path is just to decide that the authoritative information
is published on the IETF web site referenced above.

That is, I still don't understand what value is added by asking IANA to
republish in exactly the same format exactly the information that the IETF
publishes.

But I'm sure that people on this list will enlighten me (or at least attempt
to enlighten me).

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of S
> Moonesamy
> Sent: vendredi, 10. octobre 2014 19:42
> To: [email-masked]
> Cc: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 11 Oct 2014 16:22:09 +0100

Richard,

> But I'm sure that people on this list will enlighten me (or at least attempt

IANA review each IETF stream draft before the IESG approval and
often find ambiguities of various kinds (lack of distinction
between non-allocated values of various kinds, lack of clarity
as to which registry is intended, questions about the appropriate
update rules if the authors haven't specified that clearly etc.).
For registries with FCFS or expert review IANA can process
requests for allocations and do so together with the designated
experts chosen by the IESG, and IANA also check with the IESG as
needed. Basically, I'd consider it a bunch of skilled bookkeeping
as previously described that takes some effort and diligence.
You may be able to reverse engineer a bunch of those tasks from
RFC 5226. [1] I'm sure all the SLA stuff has more detail but
there's no question in my mind at least that the service IANA
provide is useful, well delivered and non-trivial (but is
still bookkeeping). There is also a bunch of tooling that IANA
use (I don't know details but I do see their ticketing system
from the outside) in order to carry out those tasks, so I'm
sure there are good enough reasons to publish direct from
their copies of the registries and no good reason to not do
so. The ietf.org mirror is just that and a useful backup.

But the main reason for not changing this IMO is: it works,
and we shouldn't meddle for no good reason. (So I hope that
folks don't now try to dissect all the tasks IANA do to see
which of those could be "better" with a little meddling;-)

Hope that helps,
S.

[1] https://tools.ietf.org/html/rfc5226

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 11 Oct 2014 17:28:16 +0200

Dear Stephen,

Thank for you this, it does clarify the situation.  People who are interested in the volume of work can get some idea from the statistics published by IANA at:

  https://www.iana.org/performance/ietf-statistics 

As far as I can tell, it is, on average, something like 5 requests per day, for all types of requests, including RFCs.

Best,
Richard

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: samedi, 11. octobre 2014 17:22
> To: [email-masked]; S Moonesamy
> Cc: [email-masked]

---

From: Seth Johnson <[email-masked]>
Date: Sat, 11 Oct 2014 12:52:24 -0400

So it's an information quality role.  Timeliness, some reasonableness
issues.  The issues relate largely to "Requirements for parameters in
[each] registry," their syntactic and semantic sensibleness and
clarity-challenged-ness (as defined by the IESG), and eliminating
single points of failure (per MoU:
https://www.icann.org/resources/unthemed-pages/ietf-iana-agreement-v8-2012-02-25-en).

Embedded down and upstream from a set of information producers and
stakeholders (represented by IESG Designated Experts, the IESG, the
IAB, the RFC Editor, and the requester) in the overall process.  See
the following from:
https://www.iana.org/performance/ietf-statistics/2014-01:

"ICANN/IANA has control over the functions it performs directly, e.g.,
receiving requests, making sure they are syntactically and
semantically sensible, forwarding the requests to Designated Experts
where appropriate, creating and modifying the registries, etc. The
IETF community has direct or indirect control over functions performed
by third parties, including IESG Designated Experts, the IESG, the
IAB, the RFC Editor, and the requester. As such, the processing of
requests has a “gross processing time” calendar days goal established
for each function and a “net processing time” calendar days goal to
reflect time expended directly by ICANN/IANA."

There's a process of reviewing issues in the MoU, chiefly in the form
of escalation and collaboration procedures related to  "Requirements
for parameters in [each] registry."

Right now, it's a system of experts working to produce information
that's clear and syntactically and semantically sensible.  If that
process gets transferred in some way, there could be embedded
presumptions presently encapsulated in the MoU processes, that could
be changed or lost without specific notice.  What's "semantically
sensible" can depend enormously on the functions the registries are
used for.  Entirely separate from more "substantive" issues related to
the broad scope of subjects of public policy that will more clearly
come into play as a transition to a dramatically different governance
context proceeds, the use of the registries in relation to governance
in new ways that can still be called basically "technical" will easily
color notions of "semantic sensibleness."

It would be good to be sure to note the relationship of this process
to broader stakeholders.

Seth

---

From: Seth Johnson <[email-masked]>
Date: Sat, 11 Oct 2014 14:13:45 -0400

Small insert -- left out the one quality attribute most emphasized in the MoU

On Sat, Oct 11, 2014 at 12:52 PM, Seth Johnson <[email-masked]> wrote:
> that's clear and syntactically and semantically sensible

that's timely as well as clear and syntactically and semantically sensible.

(eom)

> If that

---

From: Eric Burger <[email-masked]>
Date: Sun, 12 Oct 2014 06:31:12 -0400

I am not a lawyer :-)

On Oct 11, 2014, at 1:20 AM, Jefsey <[email-masked]> wrote:

>> It would cost the IETF to hire people to administer the information in the registries.  The easy path is to point to the IANA web site.  The problem is that there are some concerns about the contractual agreements.  Some people also do not like signing treaties.  In simple terms, the discussions are about filling a legal void.
>

---

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 13 Oct 2014 16:06:29 +0200

Leslie Daigle (TCE) wrote on 09/10/14 23:50:
> would like to suggest we take discussion of "1/" off the table.  

I agree. 1/ is a bit of a red herring and it will get us nowhere in
reasonable time, since we will have to discuss and converge with other
communities that I suspect may have similar arguments and claims.

> The

I am not sure we need to develop a precise solution to an unlikely
future divorce problem. John has kindly provided us with provisions from
the current  IANA Function Contract SOW (e.g. Provision C.7.3):
http://www.ietf.org/mail-archive/web/ianaplan/current/msg00553.html

Why don't we recommend that these (or similar) provisions are added to
the existing MoU, since, as we all agree, the existing system hasn't
raised any concerns for the IETF?

Andrei

---

From: JFC Morfin <[email-masked]>
Date: Mon, 13 Oct 2014 18:22:24 +0200

>At 23:08 12/10/2014, Bernard Aboba wrote:
>It is my assumption that the Trustees are following this discussion 
>and are thinking about next  steps.

If they discussed it in here, subject to the IETF consensus and to 
the IUsers' review, it could save us an appeal and possibly avoid a fork.

>At 00:08 13/10/2014, Brian E Carpenter wrote:
>IMHO that can include our expectations for any future additional 
>legal framework, plus the factual statement that the IETF Trust is 
>the responsible body for actual legal ink on paper.

Ink on paper without having something to say is just a blot. To 
decide what to say (and what to do) belongs to this WG.

>At 00:20 13/10/2014, Miles Fidelman wrote:
>Which, to me, says that:
>1. The WG charter is not sufficient to yield a complete response to 
>the TCG, and
>2. It is not at all clear how the parts of the response, outside the 
>WG's purview, are to be developed and coordinated.
>
>If the response is to be both complete, and the result of a 
>consensus process -- leaving those issues in limbo seems inappropriate.

Amen.

>At 01:28 13/10/2014, Suzanne Woolf wrote:
>The working group will not attempt to produce or discuss 
>documentation for these details, but will request the IAB or IAOC to 
>provide them separately.

Instead of updating the charter, I might just appeal for changing its 
name from "ianaplan" to "ianaplahplah"...

>The WG shall seek the expertise of the IAB IANA Evolution Program to 
>formulate its output. It is expected that members of the IAB IANA 
>Evolution Program will actively participate in the WG."

For our best common information: who in this debate is a member of 
the "IAB IANA Evolution Program"? How many here are in that Program 
and how many in total?

>At 09:25 13/10/2014, Stephen Farrell wrote:
> >On 13/10/14 04:52, Milton L Mueller wrote:
> > I hope to see some response to this point from responsible IETF 
> participants.
>You are an IETF participant since you are posting to this list.

Agreed! :-) However, this may call for a more in depth reading of RFC 3935.

>RFC 3935 - Definition of terms:
>- "Volunteer Core - our participants and our leadership are people 
>who come to the IETF because they want to do work that furthers the 
>IETF's mission of "making the Internet work better""
>- "Participants: Individuals who participate in the process are the 
>fundamental unit of the IETF organization and the IETF's work."
>- "Relevant: In this context, useful to some group of people who 
>have to make decisions that affect the Internet, including, but not 
>limited to, hardware and software implementors, network builders, 
>network operators, and users of the Internet.  Note that it does not 
>mean "correct" or "positive""

RFC 3935 - Mission Statement:
"The IETF has to make decisions.  And in some cases, people acting on 
behalf of the IETF have to make decisions without consulting the 
entire IETF first" - "Having a defined mission is one of the steps we 
can take in order to evaluate alternatives: Does this help or hinder 
the mission, or is it orthogonal to it? If there are limited 
resources, are there things that they could be invested in that help 
the mission better? Having a defined mission is one of the steps we 
can take in order to evaluate alternatives: Does this help or hinder 
the mission, or is it orthogonal to it? If there are limited 
resources, are there things that they could be invested in that help 
the mission better? (Another step is to choose leaders that we trust 
to exercise their good judgement and do the right thing.  But we're 
already trying to do that.)".

The leaders who we trust have exercised their good judgment and have 
done the right thing in changing the mission (and the standard 
process) of the IETF, through RFC 6852.

- From IETF: "to make the Internet work better" by rough consensus.
- To OpenStand IETF:  "to contribute to the economics of global 
markets fueled by technological advancements, in driving a global 
deployment of standards developed through an open participatory 
process and voluntarily adopted globally that support 
interoperability and foster global competition regardless of their 
formal status, serve as building blocks for products and services 
targeted at meeting the needs of the market and consumer, and thereby 
drive an innovation that in turn will result in the creation of new 
markets and the growth and expansion of existing markets."

As a result, we face a cultural difference between the traditional 
IETF "rough consensus" and the new ISOC/OpenStand RFC 6852 "broad 
consensus" documented by Lynn St-Amour/Don Tapscott's in the Internet 
multi-stakeholders GSN doctrine sponsored by Google/State 
Department/RBC, etc. and adopted, imposed, and propagated by the NTIA.

- in the IETF, the rough consensus is evaluated by the Chair,
- in a GSN environment, broad consensus is worked out among the 
WG-advised leaders of the mutually selected stakeholders in order to 
enforce the assigned goal.

In this case, the goal assigned to the WG is to document a seamless 
application of the NTIA ukase, thereby making the internet work better or not.

As if the govs and users were to seamlessly adopt a strategy that 
they have already voted gainst and will vote against - as they 
consider it preoccupying for democracy, people rights, development, 
and world peace as being demanded by the core (*) dominant state, the 
invading edge (*), and the spying leader (*) for economic reasons 
(*). Our best interest is the same as the US best interest, i.e. 
internet stability, neutrality, and transparency. Our duty is to make 
the NTIA understand that the way to reach that common goal is not the 
"status quo" and the ICANN being unilaterally global (BUG) to best 
serve a Business United Governance (BUG).

(*) <note>These terms are from/to be considered in relation to the 
RFC 3935 definition of the term "Internet": " The Internet: A large, 
heterogeneous collection of interconnected systems that can be used 
for communication of many different types between any interested 
parties connected to it.

The term includes both
- the "core Internet" (ISP networks)
- and "edge Internet"  (corporate and private networks, often 
connected via firewalls, NAT boxes, application layer gateways and 
similar devices).

The Internet is a truly global network, reaching into just about 
every country in the world.

The IETF community wants the Internet to succeed because we believe 
that the existence of the Internet, and its influence on economics, 
communication, and education, will help us to build a better human society".

At that time (10 years ago this month), the Internet was to influence 
economics rather than to be led by it. Its target was to build a 
better human society; not to reduce us into better consumers parked 
in global market communities.
<note>

>At 12:08 13/10/2014, Richard Hill wrote:
>The IGC charter says that the ICG will deliver its report to the 
>NTIA.  Since the discussions on this list are about replying to the 
>ICG, I think that we have to stick to what the ICG charter says.

We can certainly take into account what the IGC will tell ICANN to 
report to the NTIA on the IANA transition in response to their 
question on the DNS transition. However, don't you think we should 
mainly focus on telling the IESG that we want to stick to the way to 
make the internet work better under the new circumstances that we 
observe and expect?

>At 16:06 13/10/2014, Andrei Robachevsky wrote:
>Why don't we recommend that these (or similar) provisions are added 
>to the existing MoU, since, as we all agree, the existing system 
>hasn't raised any concerns for the IETF?

what about the wording/relation with RUSIANA, CNIANA, INDIANA, JFCIANA?

Cheers
jfc

---

From: John Curran <[email-masked]>
Date: Mon, 13 Oct 2014 11:55:49 -0700

On Oct 13, 2014, at 7:06 AM, Andrei Robachevsky <[email-masked]> wrote:
> ...

Thanks - I've copied them again below for easy reference (although these 
should be generalized from their present USG orientation at some point)

> raised any concerns for the IETF?

One advantage of noting a requirement in the plan that the arrangements must
facilitate future IANA operator transitions is that is specifies the desired
outcome, rather than the exact mechanisms (e.g. intellectual property issues, 
the exact contractual language, etc.) and as such is easier for discussion,
particularly among the various communities submitting proposals to the ICG.

If the final transition plan ends up including such requirements, then those
details will need to be filled in by requesting (as IANAplan charter notes) 
"the IAB or IAOC to provide them separately."

/John

Disclaimer: my views alone.  

=== Provision C.7.3 from the IANA Function Contract SOW

C.7.3 Transition to Successor Contractor – In the event the Government selects a successor contractor, the Contractor shall have a plan in place for transitioning each of the IANA functions to ensure an orderly transition while maintaining continuity and security of operations. The plan shall be submitted to the COR eighteen (18) months after date of contract award, reviewed annually, and updated as appropriate.

=== Provision I.61 from the IANA Function Contract SOW

I.61 52.237-3 CONTINUITY OF SERVICES (JAN 1991)

(a) The Contractor recognizes that the services under this contract are vital to the Government and must be continued without interruption and that, upon contract expiration, a successor, either the Government or another contractor, may continue them. The Contractor agrees to --

(1) Furnish phase-in training; and

(2) Exercise its best efforts and cooperation to effect an orderly and efficient transition to a successor.

(b) The Contractor shall, upon the Contracting Officer’s written notice,
(1) furnish phase-in, phase-out services for up to 90 days after this contract expires and

(2) negotiate in good faith a plan with a successor to determine the nature and extent of phase-in, phase-out services required.

The plan shall specify a training program and a date for transferring responsibilities for each division of work described in the plan, and shall be subject to the Contracting Officer’s approval. The Contractor shall provide sufficient experienced personnel during the phase-in, phase-out period to ensure that the services called for by this contract are maintained at the required level of proficiency.

(c) The Contractor shall allow as many personnel as practicable to remain on the job to help the successor maintain the continuity and consistency of the services required by this contract. The Contractor also shall disclose necessary personnel records and allow the successor to conduct on-site interviews with these employees. If selected employees are agreeable to the change, the Contractor shall release them at a mutually agreeable date and negotiate transfer of their earned fringe benefits to the successor.

(d) The Contractor shall be reimbursed for all reasonable phase-in, phase-out costs (i.e., costs incurred within the agreed period after contract expiration that result from phase-in, phase-out operations) and a fee (profit) not to exceed a pro rata portion of the fee (profit) under this contract.

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 13 Oct 2014 19:05:47 +0000

> > future divorce problem. John has kindly provided us with provisions
> > from the current  IANA Function Contract SOW (e.g. Provision C.7.3):

Is it not obvious that if the NTIA saw the need to at least contemplate a change of providers that a replacement regime should too? And who if not the IETF should be in a position to change providers? I really don't understand the resistance to this. 

> One advantage of noting a requirement in the plan that the arrangements
> must facilitate future IANA operator transitions is that is specifies the desired

I agree that we don't need exact contractual language, but I don't think the trademark issues are "exact mechanisms." Whatever transition plan is in place must handle the transfer of the recognized identifiers of the IANA in a responsible way. The domain and the trademark must be mentioned.

---

From: John Curran <[email-masked]>
Date: Mon, 13 Oct 2014 12:20:01 -0700

> I agree that we don't need exact contractual language, but I don't think the trademark issues are "exact mechanisms." Whatever transition plan is in place must handle the transfer of the recognized…

Milton - 

To be clear, there is a substantial difference between identifying a requirement
in the plan that the mechanisms establish must provide that IANA's recognized marks 
and identifiers must be transferred to an subsequent IANA operator, versus a plan 
which states that the IAB/IAOC/IETF Trust must go take possession of the "IANA marks
and domains" prior to the NTIA IANA Stewardship transition...

Which approach are you advocating?

/John

Disclaimers: my views alone. Note - due to related Internet identifier fun, 
I CANN't always respond to list email in a timely manner this week...

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 13 Oct 2014 12:24:23 -0700

I agree with Andrei and John -- this looks like a good approach to me.

Alissa

> On Oct 13, 2014, at 11:55 AM, John Curran <[email-masked]> wrote:
>

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 13 Oct 2014 15:56:34 -0400

As a first step, we might simply wordsmith those contract terms to 
replace "Government" with "IETF," tweak the wording to apply just to the 
functions under IETF jurisdiction, and include that in the IETF response 
to the TWG.  Obviously, the lawyers should review this.

And add a clause regarding IANA.org.  My preference would be to transfer 
registration to the IETF trust now, with the IANA contractor 
administering it on behalf of IETF, et. al.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 13 Oct 2014 20:15:59 +0000

> From: John Curran [mailto:[email-masked]]

> To be clear, there is a substantial difference between identifying a
> requirement in the plan that the mechanisms establish must provide that
> IANA's recognized marks and identifiers must be transferred to an
> subsequent IANA operator, versus a plan which states that the
> IAB/IAOC/IETF Trust must go take possession of the "IANA marks and
> domains" prior to the NTIA IANA Stewardship transition...

Yes, there is a difference and I see it.

> Which approach are you advocating?

Something in between. I could live with "a requirement in the plan that the mechanisms establish must provide that IANA's recognized marks and identifiers must be transferred to an subsequent IANA operator." 

But I would prefer "a requirement in the plan that the mechanisms establish must provide that IANA's recognized marks and identifiers must be transferred to IAB/IAOC/IETF Trust."

If IAB/IAOC/IETF Trust are in control of which operator can use them, why not just own the marks and domains itself and delegate them to whichever IANA operator it wishes? Of course, as a practical matter this doesn't need to happen until such time as a 'divorce' is requested.

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 13 Oct 2014 16:24:39 -0400

Milton L Mueller wrote:
> If IAB/IAOC/IETF Trust are in control of which operator can use them, why not just own the marks and domains itself and delegate them to whichever IANA operator it wishes?

+1
> Of course, as a practical matter this doesn't need to happen until such time as a 'divorce' is requested.
>
>

Unless someone wants to drag their feet.  Better to do it in advance.

Miles Fidelman

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 13 Oct 2014 20:46:48 +0000

Agree, this is a major concern.

---

From: Seth Johnson <[email-masked]>
Date: Mon, 13 Oct 2014 19:56:03 -0400

As I read it, all that's required is that the specifics of *how* be
left to the organs that normally develop those details.  They could
advise as experts that a requirement is not legally tenable, but what
we do is designate the elements, including aspects such as specific
ownership/assignment of exclusive rights like trademarks, that would
constitute a transition that's supported by the community.  I see
nothing that says we are barred from saying what the necessary
conditions of a plan we support would need to be. (In so saying, I am
not staking a position on possession of iana.org.  That's not a
concern of mine, except in a more abstract sense of recourse in
relation to what might happen with it in a "divorce.")

One could say this could turn into a ruse for developing details as
conditions, but I see the proscription as not assuming the role of
those organs that do certain things normally.  What we tell those
organs is needed is not taking on their role.  Any "details" discussed
would have to be things intended as conditions that are required, and
it should be reasonable enough to start saying we're getting into
unnecessary details and getting away from saying what we as a
community regard as conditions.  That will happen naturally in a group
discussion.  Some set of elements, including details of how those
elements need to be constituted, will constitute a sufficient set of
conditions stipulating what we hold is necessary to be developed in a
plan we support.

Seth

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Oct 2014 21:47:59 -0400

> Something in between. I could live with "a requirement in the plan that the mechanisms establish must provide that IANA's recognized marks and identifiers must be transferred to an subsequent IANA…

I'm comfortable with asking for that, because it's already in an
existing agreement and therefore isn't a new request.  In my opinion,
we should follow our charter and change things as little as possible.
A request to move marks or domain name registrations now held by one
party to another party is a change, and not an insignificant one.  But
the existing agreement requires certain actions by the existing
contractor, and we could certainly require that those actions end up
in a different agreement as part of the transition, without asking for
something new.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Seth Johnson <[email-masked]>
Date: Tue, 14 Oct 2014 01:58:05 -0400

> we should follow our charter and change things as little as possible.

A preference for minimal change in oversight, and no change if
possible, only says changes should be the minimum necessary, not how
minor changes would actually be.  It signals a preference to match how
things have worked as much as possible, a preference for minimal or no
change, but doesn't say how much change would be involved.

The key is the focus on "continuation of the current arrangements,"
which means addressing the implications of the transition for the
current arrangements.

Avoiding, and setting aside for later consideration, other topics
related to IANA besides planning the transition of NTIA out of its
present role, means anything that falls outside minimal changes in
order to maintain the current arrangements, or anything in the
documenting of the interaction between IETF and the operator that gets
into terms of agreements and procedures usually addressed by IAB/IAOC,
should be presented as adjunct topics to the plan, things we note
would need to be addressed outside our charter, but that it would
nevertheless be necessary to fully address.

Seth

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Tue, 14 Oct 2014 06:02:23 +0000

+1.

Eliot

> On Oct 14, 2014, at 4:48 AM, Andrew Sullivan <[email-masked]> wrote:
>

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 14 Oct 2014 09:50:13 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Andrew
> Sullivan
> Sent: mardi, 14. octobre 2014 03:48
> To: [email-masked]
> > Something in between. I could live with "a requirement in the
> plan that the mechanisms establish must provide that IANA's
> recognized marks and identifiers must be transferred to an
> subsequent IANA operator."
> >
>
> existing agreement

I don't see anything like that in the agreements between ICANN and the IETF.

And I don't see anything about transferring marks and identifiers in the
existing ICAN Functions contract between NTIA and ICANN.

But maybe I missed something.

Or maybe it is in the transition plan that ICANN has presumably prepared in
accordance with the existing IANA Functions contract.

ICANN's response to the NTIA RFP, which response is incorporated by
reference in the contract, includes the following:

"1.7.3 Transition to Successor Contractor [M.8; C.7.3]
ICANN will develop a plan for transitioning services, registries and
appropriate data stores to any successor contractor identified by the NTIA.
1.7.3.1 Transition Out Plan
ICANN will use its long-standing performance of the IANA Functions to
identify the key services and data that must be transitioned to a successor
contractor. This includes transitioning appropriate documentation of
services and the data for managing the services of the IANA Functions.
1.7.3.2 Submission of Plan
ICANN will develop a plan for transitioning the IANA Functions to a
successor contractor in several stages. See Figure 1.7-3."

The contract itself includes the following:

"C.7.3 Transition to Successor Contractor - In the event the Government
selects a successor contractor, the Contractor shall have a plan in place
for transitioning each of the IANA functions to ensure an orderly transition
while maintaining continuity and security of operations. The plan shall be
submitted to the COR eighteen (18) months after date of contract award,
reviewed annually, and updated as appropriate."

"M.8" refers to a section of the NTIA RFP. That section outlines the
criteria that NTIA will use to evaluate the responses to the RFP.  It does
not contain substantive text.

>and therefore isn't a new request.  In my opinion,
> party to another party is a change, and not an insignificant one.

Correct. But that significant change was made when the NTIA and ICANN
entered into the first IANA functions contract: the marks were registered by
ICANN and the domain name was transferred to ICANN.

Since NTIA is stepping out, it seems reasonable (and indeed necessary) to
discuss whether another change should be made.

>But

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 14 Oct 2014 08:39:22 -0400

> discuss whether another change should be made.

The RFP we're responding to, from the ICG, requires (among other things):

I. Description of Community’s Use of IANA Functions
II. Existing, Pre-Transition Arrangements
III. Proposed Post-Transition Oversight and Accountability Arrangements
IV. Transition Implications
(including)Risks to operational continuity and how they will be addressed.
(including)Description of any legal framework requirements in the 
absence of the NTIA contract.

Might I suggest that our response regarding the iana.org domain be 
framed in accord with this structure (and we should apply this to each 
function/issue in our formal response):

Specifically:

I. Description of Community’s Use of IANA Functions
- discussion of the role and use of the iana.org domain (web servers, 
email addresses, other) and associated content

II. Existing, Pre-Transition Arrangements
- history of the iana.org domain and its uses - including registration 
history

III. Proposed Post-Transition Oversight and Accountability Arrangements
- oversight and accountability has been of the functions that use the 
domain, not the domain itself - other than perhaps the rules that apply 
to all domain registrations and operations
- perhaps highlight that this has been an oversight - in that transfer 
of the domain to ICANN from SRI (?) was just done, nobody actually made 
a formal decision about ownership of either the name, the registration, 
or the associated intellectual property (content, software, etc.)
- proposal for ownership, control, and operation of the iana.org domain 
in the event of a change of contractors
<my preference: transfer ownership & control as part of the transition 
to the entity(ies) that replace NTIA as the party(ies) that contract for 
IANA functions, delegation of the use and operation of the domain is to 
the IANA contractor(s), if the contract is transferred, the outgoing 
contractor will cooperate in the transfer of .....>

IV. Transition Implications
(including)Risks to operational continuity and how they will be addressed.
- risks of confusion, conflicts, etc. if the IANA contractor is changed 
is changed
- elaboration of additional issues if the contractor for only one/some 
function(s) is(are) changed

(including)Description of any legal framework requirements in the 
absence of the NTIA contract.
- discussion of need for clarity of ownership and control of the 
iana.org domain, associated servers, and associated intellectual property
<suggestion: to effect minimal change, we need an entity or entities to 
take NTIA's place as the contracting party for dealing with the IANA 
contractor(s)>
<note: ultimately, we need to address whether we see a single 
contracting party, a different contracting party for each function 
(where things seem to be going)>
<suggestion: that party, one of those parties, or a joint entity needs 
to own, register, control, and delegate, and oversee the use and 
operation of the domain, associated servers, and associated intellectual 
property>

Miles Fidelman

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Oct 2014 08:36:11 +1300

> take NTIA's place as the contracting party for dealing with the IANA

For the IETF's interests we have them already: IASA (via ISOC)
and the IETF Trust.

> (where things seem to be going)

IMHO that's a given, in a multi-stakeholder world.

> operation of the domain, associated servers, and associated intellectual

That is why the IETF, via IASA and the IETF Trust, needs agreements
with the IANA operator.

I'm not sure what the new news is. What are your specific suggestions
for the text of draft-ietf-ianaplan-icg-response?

    Brian

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 14 Oct 2014 18:05:15 -0400

Those WERE my suggestions for text.

Classic RFP response - they give an outline, they ask for us to address 
specific points, in specific places.  Those were the bullet point 
answers that I suggest be in the document as regards ownership/control 
of iana.org.

---

From: Jefsey <[email-masked]>
Date: Wed, 15 Oct 2014 18:22:13 +0200

At 21:56 13/10/2014, Miles Fidelman wrote:
>replace "Government" with "IETF," tweak the wording to apply just to 
>the functions under IETF jurisdiction, and include that in the IETF 
>response to the TWG.  Obviously, the lawyers should review this.
>
>And add a clause regarding IANA.org.  My preference would be to 
>transfer registration to the IETF trust now, with the IANA 
>contractor administering it on behalf of IETF, et. al.
>
>Miles Fidelman

Seems good enough: this way the IETF Trust, i.e. ISOC, sovereignly 
owns the internet and decides about it through its global solution 
network, as per Don Tapscott. And ICANN runs the internet under the 
supervision of its US jurisdiction. At least this is clear, neat and 
simple. I said simple? I am not that sure.
jfc

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 15 Oct 2014 12:54:01 -0400

Jefsey wrote:
>> transfer registration to the IETF trust now, with the IANA contractor 

Wasn't that the original idea of ISOC? :-)

---

From: Jefsey <[email-masked]>
Date: Wed, 15 Oct 2014 19:22:21 +0200

At 18:54 15/10/2014, Miles Fidelman wrote:
>>>replace "Government" with "IETF," tweak the wording to apply just 
>>>to the functions under IETF jurisdiction, and include that in the 
>>>IETF response to the TWG. Obviously, the lawyers should review this.
>>>
>>supervision of its US jurisdiction. At least this is clear, neat 
>>and simple. I said simple? I am not that sure.
>>jfc
>

Yes. This means, the US enhanced cooperation (USG, Google, ISOC 
objective coalition)'s idea. It took the three of them 15 years to 
integrate ICANN under ISOC. The NTIA removal was planned for 2000. 
Without Edward it could have taken a decade more ...

jfc