Subject: [Ianaplan] Question from the ICG

From: Alissa Cooper <[email-masked]>
Date: Thu, 24 Sep 2015 15:02:29 -0700

Dear IANAPLAN WG,

Based on comments received during the ICG’s public comment period, the ICG has a question for the protocol parameters community. We are requesting a response to this question ideally by 7 October at 23:59 UTC (prior to the ICG’s final call before ICANN 54 on October 8), or by 14 October at 23:59 UTC if the protocol parameters community requires more time. We realize this is an aggressive timetable, so please keep us informed if you feel you need further time.

The ICG would like to state explicitly that we do not expect a further ICG public comment period to be necessary on the combined proposal in response to the answers that the protocol parameters community may provide. While the ICG reserves the right to seek further public comment if we receive extensive amendments from any of the operational communities, we do not expect to do so at this time.

The three operational communities have a long history of cooperation as needed to help ensure the smooth functioning of the DNS and the Internet. A number of comments were concerned that the three IANA functions could end up being carried out by different operators and suggested that there was a need for some information exchange and coordination between the operational communities to ensure a proper understanding of the impact a change might have on the operation of the other functions (perhaps because of interdependencies between the functions or because of shared resources or key staff). This information exchange might also help in coordinating action in the case of remedying operational difficulties. For this to work, the three operational communities need to commit to coordinating and cooperating as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. Can the protocol parameters operational community provide such a commitment? If so, the ICG intends to reflect that and the commitments of the other communities in Part 0 of the transition proposal.

Please let us know if the question requires clarification.

Thanks,

Alissa Cooper on behalf of the ICG

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Sep 2015 18:26:01 -0400

I think that we should respond with a very simple confirmation that we plan to continue to coordinate with the other operational communities, but that we do not think that formal processes are necessary to do so.  This is consistent with the comments that were sent by the IAB to the ICG.  See https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-comments-on-icg-proposal/.

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Sep 2015 11:49:55 +1200

On 25/09/2015 10:26, Russ Housley wrote:
> I think that we should respond with a very simple confirmation that we plan to continue to coordinate with the other operational communities, but that we do not think that formal processes are necessary to do so.  

fwiw, I certainly agree with that.

  Brian

> This is consistent with the comments that were sent by the IAB to the ICG.  See
https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-comments-on-icg-proposal/.
>> The three operational communities have a long history of cooperation as needed to help ensure the smooth functioning of the DNS and the Internet. A number of comments were concerned that the three IANA functions could end up being carried out by different operators and suggested that there was a need for some information exchange and coordination between the operational communities to ensure a proper understanding of the impact a change might have on the operation of the other functions (perhaps because of interdependencies between the functions or because of shared resources or key staff). This information exchange might also help in coordinating action in the case of remedying operational difficulties. For this to work, the three operational communities need to commit to coordinating and cooperating as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. Can the protocol parameters operational community provide such a commitment?
 If so, the ICG intends to reflect that and the commitments of the other communities in Part 0 of the transition proposal.
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Sep 2015 15:02:58 +0200

Hi Russ,

I agree, but I also see a bit of confusion in the question that is being
asked with regard to "operator" and "operational communities".  While
different functions operators may be required in the future, the
policies governing a given IANA function do not change simply because
the operator changes.  Wisdom and operational experience have guided us
toward collaboration across the various communities with regard to these
policies thus far, and will continue to do so in the future.

Eliot

On 9/25/15 12:26 AM, Russ Housley wrote:
> I think that we should respond with a very simple confirmation that we
> plan to continue to coordinate with the other operational communities,
> but that we do not think that formal processes are necessary to do so.
>  This is consistent with the comments that were sent by the IAB to the
> ICG.
>  See https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-comments-on-icg-proposal/.
>
>
> Russ
>
>
>> Based on comments received during the ICG’s public comment period,
>> the ICG has a question for the protocol parameters community. We are
>> requesting a response to this question ideally by 7 October at 23:59
>> UTC (prior to the ICG’s final call before ICANN 54 on October 8), or
>> by 14 October at 23:59 UTC if the protocol parameters community
>> requires more time. We realize this is an aggressive timetable, so
>> please keep us informed if you feel you need further time.
>>
>> The ICG would like to state explicitly that we do not expect a
>> further ICG public comment period to be necessary on the combined
>> proposal in response to the answers that the protocol parameters
>> community may provide. While the ICG reserves the right to seek
>> further public comment if we receive extensive amendments from any of
>> the operational communities, we do not expect to do so at this time.
>>
>> The three operational communities have a long history of cooperation
>> as needed to help ensure the smooth functioning of the DNS and the
>> Internet. A number of comments were concerned that the three IANA
>> functions could end up being carried out by different operators and
>> suggested that there was a need for some information exchange and
>> coordination between the operational communities to ensure a proper
>> understanding of the impact a change might have on the operation of
>> the other functions (perhaps because of interdependencies between the
>> functions or because of shared resources or key staff). This
>> information exchange might also help in coordinating action in the
>> case of remedying operational difficulties. For this to work, the
>> three operational communities need to commit to coordinating and
>> cooperating as necessary when changing operator, whether by
>> leveraging existing coordination mechanisms or new ones. Can the
>> protocol parameters operational community provide such a commitment?
>> If so, the ICG intends to reflect that and the commitments of the
>> other communities in Part 0 of the transition proposal.
>>

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 25 Sep 2015 06:22:48 -0700

Hi Russ, all

While making ability to change operator an independent decision of each
operational communities, and your "simple" comment about continuous
coordination is fine. I think it may be good for other operational
communities to be aware (carried along) when any of the 3 Identifier
communities initiates its/her operator change process and i think it may be
good to have formal commitment to that.

This definitely does not mean views from other operational community would
necessarily have effect in the decision making of the community intending
to change operator.

Regards

On Thu, Sep 24, 2015 at 3:26 PM, Russ Housley <[email-masked]> wrote:

> plan to continue to coordinate with the other operational communities, but
> that we do not think that formal processes are necessary to do so.  This is
> consistent with the comments that were sent by the IAB to the ICG.  See
> Based on comments received during the ICG’s public comment period, the ICG
> has a question for the protocol parameters community. We are requesting a
> response to this question ideally by 7 October at 23:59 UTC (prior to the
> ICG’s final call before ICANN 54 on October 8), or by 14 October at 23:59
> UTC if the protocol parameters community requires more time. We realize
> this is an aggressive timetable, so please keep us informed if you feel you
> need further time.
>
> The ICG would like to state explicitly that we do not expect a further ICG
> public comment period to be necessary on the combined proposal in response
> to the answers that the protocol parameters community may provide. While
> the ICG reserves the right to seek further public comment if we receive
> extensive amendments from any of the operational communities, we do not
> expect to do so at this time.
>
> The three operational communities have a long history of cooperation as
> needed to help ensure the smooth functioning of the DNS and the Internet. A
> number of comments were concerned that the three IANA functions could end
> up being carried out by different operators and suggested that there was a
> need for some information exchange and coordination between the operational
> communities to ensure a proper understanding of the impact a change might
> have on the operation of the other functions (perhaps because of
> interdependencies between the functions or because of shared resources or
> key staff). This information exchange might also help in coordinating
> action in the case of remedying operational difficulties. For this to work,
> the three operational communities need to commit to coordinating and
> cooperating as necessary when changing operator, whether by leveraging
> existing coordination mechanisms or new ones. Can the protocol parameters
> operational community provide such a commitment? If so, the ICG intends to
> reflect that and the commitments of the other communities in Part 0 of the
> transition proposal.
>

-- 
------------------------------------------------------------------------

*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>[email-masked]
<[email-masked]>*

Bringing another down does not take you up - think about your action!

---

From: JFC Morfin <[email-masked]>
Date: Fri, 25 Sep 2015 13:11:04 +0200

Fwiw:

We are entangled in France with the begining of a 
national debate initiated by the Government over 
a law proposition for a "numeric Republic". Due 
to the NTIA transition delay, I have proposed the 
XLIBRE bootstrap to focus on this 
regalan/private/civil issue and to exempllify it 
with an XMP2P/IP oriented architecture and r&d 
(the interest is not that much the result, but 
the cooperative proprietary/Libre research, 
development and experimentation experience we can use in this debate).

1. this means that I suspect the XLIBRE VGNS 
(virtual glocal network set) will not interfere in IETF/ICANN VGNS areas.
2. the "FL" class experimentation has started 
through different test hypothesis, but is not our 
priority anymore since the main project may 
request somme additional DDDS services we want to consider first.

Therefore the aggregation of the IETF to the 
ICANN community is no more a problem for us, as 
long as IP is not modified and the test "FL" CLASS remains an options for all.

Best regards
jfc

At 01:49 25/09/2015, Brian E Carpenter wrote:

> > I think that we should respond with a very 
> simple confirmation that we plan to continue to 
> coordinate with the other operational 
> communities, but that we do not think that 
> formal processes are necessary to do so.
>
> >> Based on comments received during the 
> ICG’s public comment period, the ICG has a 
> question for the protocol parameters community. 
> We are requesting a response to this question 
> ideally by 7 October at 23:59 UTC (prior to the 
> ICG’s final call before ICANN 54 on October 
> 8), or by 14 October at 23:59 UTC if the 
> protocol parameters community requires more 
> time. We realize this is an aggressive 
> timetable, so please keep us informed if you feel you need further time.
> >>
> >> The ICG would like to state explicitly that 
> we do not expect a further ICG public comment 
> period to be necessary on the combined proposal 
> in response to the answers that the protocol 
> parameters community may provide. While the ICG 
> reserves the right to seek further public 
> comment if we receive extensive amendments from 
> any of the operational communities, we do not expect to do so at this time.
> >>
> >> The three operational communities have a 
> long history of cooperation as needed to help 
> ensure the smooth functioning of the DNS and 
> the Internet. A number of comments were 
> concerned that the three IANA functions could 
> end up being carried out by different operators 
> and suggested that there was a need for some 
> information exchange and coordination between 
> the operational communities to ensure a proper 
> understanding of the impact a change might have 
> on the operation of the other functions 
> (perhaps because of interdependencies between 
> the functions or because of shared resources or 
> key staff). This information exchange might 
> also help in coordinating action in the case of 
> remedying operational difficulties. For this to 
> work, the three operational communities need to 
> commit to coordinating and cooperating as 
> necessary when changing operator, whether by 
> leveraging existing coordination mechanisms or 
> new ones. Can the protocol parameters 
> operational community provide such a commitment?
>  If so, the ICG intends to reflect that and the 
> commitments of the other communities in Part 0 of the transition proposal.
> >>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Sep 2015 22:01:30 -0400

> I think that we should respond with a very simple confirmation that we plan to continue to coordinate with the other operational communities, but that we do not think that formal processes are nece…

Yes. And we are. That is, we have always and will continue to coordinate with the other operational communities on matters where coordination is necessary. And that existing coordination models are sufficient.

Jari

---

From: "John Levine" <[email-masked]>
Date: 28 Sep 2015 01:55:44 -0000

>I think that we should respond with a very simple confirmation that we plan to continue to coordinate with the other
>operational communities, but that we do not think that formal processes are necessary to do so.

I completely agree.  It is not a good use of anyone's time to invent
complex processes for hypothetical situations.  Particularly since if
the problem actually comes to pass, it will certainly do so in a way
different from what the invented processes anticipate.

R's,
John

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 28 Sep 2015 16:15:51 +0200

On Fri, Sep 25, 2015 at 12:26 AM, Russ Housley <[email-masked]> wrote:
> I think that we should respond with a very simple confirmation that we plan
> to continue to coordinate with the other operational communities, but that
> we do not think that formal processes are necessary to do so.  This is

agree

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Sep 2015 11:15:42 -0400

Hi,

> good to have formal commitment to that.

I appreciate the sentiment here, but how is that any different from
the existing informal co-ordination we already do?  I don't see how
it'd even be possible, given the transparent way each community works,
for any of the other communities to be oblivious to the coming change
unless there really were no inter-community participation.  If we get
to that point, we'll have many formal communications to set up, not
just this one.

Not to put too fine a point on it, two of the communities work in very
lightly structured ways with mostly informal mechanisms of
communication and as few hard process rules as is possible.  They
produced fairly short proposals in time for the original ICG deadline.
Another community appears to structure itself rather formally, with
consituencies, formal membership rules, and attempts at strict
representativity.  That community has, well past the original
deadline, produced a proposal for the ICG; yet even that proposal
depends on _another_ proposal that still isn't complete and, in draft
form, is complicated and controversial.

I am therefore not convinced even a little bit that additional formal
commitments, rules, processes, or anything of that sort, are
advisable.  The goal is to make the Internet better, not to achieve a
nicely designed process.  As the WG (and, in other contexts, the IAB)
said, the appoach we're using today (which is mostly informal) is
working well.  There is no reason to invent new ways of ensuring that
communication when the communication now flows without such
inventions.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Tue, 29 Sep 2015 18:23:45 +0100

> communication when the communication now flows without such

I understand the reticence in "if it ain't broken, don't fix it". The
recommendation was made by several entities, including the ALAC. We were
concerned that whilst today there appears to be several informal
channels, the future might not keep it this way. So we felt that it
would be a good idea to keep at least a formal channel open so that we
don't end up with one operational community deciding to split without
finding a way to keep the three functions operated by the same IANA
functions operator.
I'd see it as an opportunity to enhance collaboration between
operational communities. As individuals we are not immortal. I have no
idea what the next generations will be like and whether this collegial
collaboration will continue.
Kindest regards,

Olivier

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Sep 2015 13:34:27 -0400

Hi,

> finding a way to keep the three functions operated by the same IANA

With respect, that is exactly how bureacracies get built: people try
to replace a functioning rough-and-ready system with something that is
formal and well-built.  Once you establish such formal rules, it is
almost impossible to resist the temptation to continue to build more
formalism, and soon you have people following the rules instead of
getting the work done.  It is far from clear to me that the much more
formal communication paths among the various intra-ICANN
constituencies are more resilient or reliable than the informal
communication paths that exist inter-community.

> collaboration will continue.

If we (as communities) see those bonds start to fray, then we will
have a responsibility to set up the relevant communication mechanisms,
with that responsibility being one of the tasks that is handed along
between generations of people.  The IAB already has this
responsibility not just with ICANN but with any other organization
that impinges on the IETF.  I don't think the IANA-community
relationships are unusual in any important way as compared to other
such relationships, so I think the formal commitment from the IETF
already exists.  This is expressed in RFC 2850 section 2 item (f).

So if something special is wanted, we can point to that.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Sep 2015 19:52:48 +0200

Greetings Olivier,

> collaboration will continue.

It is certainly the case that we can all do better, but I think we do
reasonably well.

We should keep in mind that some formal mechanisms do exist, even if
they are somewhat loose.  For instance, there is the istar CEO group. 
That group is not always sufficient to the task.  And so there is the
internet collaboration activity.  Both of these have been driven by
ISOC, and it's all institutional.  Personally I expect all of that to
evolve over time, but how I can't say.  And in my experience, when there
is a need the IAB does liaise.  ICANN currently has quite a number of
IETF representatives appointed into various positions, including the
TLG, the board (liaison), RSAC (liason), and I'm sure one or two more. 
Again, I expect all of that to evolve over time, and again I can't say how.

Beyond that, with the RIRs, it is a bit more informal.  But that doesn't
mean communications are bad.  We all see John Curran here, and a few of
us participate in some of their activities, from time to time.   Alvaro
teed up a great outreach partnership with the good folks at LACNIC with
the help of Christian at ISOC.  It'd be good if we could replicate that
elsewhere.  These are real communications whether they are formal or
not.  Many of the formal liaisons twiddle their fingers (having been a
finger twiddler myself) with nothing much to say.  I expect all of that
to evolve over time, but how I cannot say.

Eliot

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Sep 2015 14:00:51 -0400

> finding a way to keep the three functions operated by the same IANA

Please take a look at the comments from the IAB to the ICG (see https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-comments-on-icg-proposal/).  This part is especially relevant here:

   Informal and loosely-coupled coordination
   has worked well in the past, and it produced the coherent ICG proposal
   without formal liaisons among the communities.  We believe that this web
   of relationships is a strong expression of the multistakeholder model,
   and that there is no need to concentrate these relationships within new
   ICANN structures.  The IAB does not oppose additional formal links in
   principle if they are found to be useful in the future, and we believe
   we have all of the necessary mechanisms for adding them.  In general,
   however, we prefer informal coordination and communication among the
   communities, and we generally prefer to avoid creating additional
   organizational structures.  We believe this organizational model
   reflects the way the Internet works.

> collaboration will continue.

The operational communities need to have informal communication among themseleves whether they share the same IANA functions operator or not.

To me, the best response to the ICG is that informal coordination existed today and we will continue it in the future.

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Sep 2015 10:32:35 +1300

On 30/09/2015 07:00, Russ Housley wrote:

...
> To me, the best response to the ICG is that informal coordination existed today and we will continue it in the future.

Agreed. All our collective experience with liaisons with numerous other organisations
has surely taught us that informal methods and overlapping participants work much
better than formal liaisons with their slow and sometimes Kafkaesque paper-pushing
mechanisms (even with virtual paper).

Of course we can be formal if circumstances force us into it, but there's
nothing to be gained by making it sound like a good thing.

    Brian