[CWG-Stewardship] Names Community vs the other two communities

[Greg Shatan]

All:

In relation to this point, Section 1 of the RFP asks for the following:

A  description  of  any  overlaps  or  interdependencies  between  your
IANA  requirements and  the functions  required  by  other customer
 communities.

The current (October 16) IETF draft proposal (
https://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01) has the
following response:

IETF Response:

   In this context, the IETF considers "overlap" to be where there is in
   some way shared responsibility for a single registry across multiple
   organizations.  This is the case with both names and numbers, as
   described in the paragraphs below.  In all cases, the IETF engages
   directly with the appropriate organizations to ensure that each
   organization's policies are followed.

   It is important to note that the IETF includes anyone who wishes to
   participate, including anyone from ICANN or the regional Internet
   registries (RIRs), and many people from those organizations regularly
   do.

   o  The IETF has specified a number of special use registries with
      regard to domain names.  These registries require coordination
      with the Generic Names Support Organization (GNSO).  We already
      perform this coordination.[RFC6761 <https://tools.ietf.org/html/rfc6761>]

   o  The IETF specifies the DNS protocol.  From time to time there have
      been and will be updates to that protocol.  We will continue to
      coordinate with ICANN regarding those changes.

   o  The IETF specifies minimum requirements for root servers.  Should
      those requirements change, we will inform ICANN.

   o  The routing architecture has evolved over time, and is expected to
      continue to do so.  Such evolution may have an impact on
      appropriate IP address allocation strategies.  As and when that
      happens, we will consult with the RIR community, as we have done
      in the past.

   o  The IETF has established registries with IANA for special IPv4 and
      IPv6 assignments.  These are specified in [RFC6890
<https://tools.ietf.org/html/rfc6890>].  The IETF
      coordinates such assignments with the RIRs.

   o  IETF standards changes may have impact on operations of RIRs and
      service providers.  A recent example is the expansion of the BGP
      community field from 16 to 32 bits.[RFC6793
<https://tools.ietf.org/html/rfc6793>]  It is important to
      note that this change occurred out of operational necessity, and
      it demonstrated strong alignment between the RIRs and the IETF

Greg

On Fri, Oct 17, 2014 at 10:08 PM, Greg Shatan <gregshatanipc at gmail.com>
wrote:

> Just to be clear, I did not ask the group to come up with a proposal that
> related to all three areas (I am quite clear about our mandate).  Rather,
> the issue is whether our proposal can be unrelated to the proposals from
> the other two areas.
>
> Maybe any proposal we come up with (regardless of what it is) will work
> with any proposals that the other two communities come up with.   But I do
> not think we can merely assume that without some discussion and testing of
> hypotheses along the way.  It may also require some horizontal coordination
> across the 3 groups preparing proposals.
>
> If the best proposal for stewardship, oversight and accountability over
> the names related IANA functions in a post-NTIA world involves moving these
> functions out of ICANN, so be it (assuming it is feasible).  But we will
> need to be very confident that this does not compromise the IANA
> operations, both overall and relating to names.
>
> Greg
> On Oct 17, 2014 11:33 AM, "Milton L Mueller" <mueller at syr.edu> wrote:
>
>>  Chuck,
>>
>> It’s kind of a minor quibble, isn’t it? The second statement was more
>> specific and precise, of course, but Greg was asking us to come up with a
>> proposal that related to all three areas, so my first sentence just made
>> the point that our work focuses on names, not on numbers or protocols.
>>
>>
>>
>> *From:* Gomes, Chuck [mailto:cgomes at verisign.com]
>> *Sent:* Friday, October 17, 2014 10:32 AM
>> *To:* Milton L Mueller; Greg Shatan; WUKnoben
>> *Cc:* cwg-stewardship at icann.org
>> *Subject:* RE: [CWG-Stewardship] Names Community vs the other two
>> communities
>>
>>
>>
>> Milton,
>>
>>
>>
>> I like your second formulation of our task (“We need concrete proposals
>> for the names part of the IANA functions that deal with the problem of the
>> end of NTIA oversight of IANA and the accountability of ICANN.”) better
>> than your first: “Our job is to come up with a transition proposal for DNS,
>> for names.”  I know you know this but just to avoid possible
>> misunderstanding by others in the group, we are not tasked with coming up
>> with a transition proposal for DNS but rather with that portion of the DNS
>> that relates to the services provided by NTIA with regard to the IANA
>> naming functions, which is what you essentially said in your second
>> paragraph.
>>
>>
>>
>> Chuck
>>
>>
>>
>> *From:* cwg-stewardship-bounces at icann.org [
>> mailto:cwg-stewardship-bounces at icann.org
>> <cwg-stewardship-bounces at icann.org>] *On Behalf Of *Milton L Mueller
>> *Sent:* Friday, October 17, 2014 12:45 PM
>> *To:* Greg Shatan; WUKnoben
>> *Cc:* cwg-stewardship at icann.org
>> *Subject:* Re: [CWG-Stewardship] Names Community vs the other two
>> communities
>>
>>
>>
>> Greg:
>>
>>
>>
>> Our job is to come up with a transition proposal for DNS, for names.
>>
>> The holistic issue of whether the three different aspects of IANA should
>> remain in the same organization or not is outside the scope of this group.
>> Moreover, the results of the other two processes are not known, so I am not
>> sure where you get the idea that the other 2 communities are leaving IANA
>> “as is.” And even if they were, I don’t see how that affects the solution
>> set for names.
>>
>>
>>
>> What we need in this group are more than simple assertions that something
>> is “unnecessary or undesirable.” We need concrete proposals for the names
>> part of the IANA functions that deal with the problem of the end of NTIA
>> oversight of IANA and the accountability of ICANN.
>>
>>
>>
>> As someone with a bit more operational knowledge, I can tell you that the
>> staff members in IANA who deal with names, numbers and protocols are
>> different and there is very little linkage between their day to day tasks,
>> though occasionally there is a need to exchange information and coordinate
>> with the customers of IANA.
>>
>>
>>
>>
>>
>>
>>
>> *From:* cwg-stewardship-bounces at icann.org
>> [mailto:cwg-stewardship-bounces at icann.org] *On Behalf Of *Greg Shatan
>>
>>
>>
>> I don't think it's necessary or desirable to split IANA into 3 IANAs (or
>> 2 IANAs, since the other two communities are leaving IANA "as is" and not
>> splitting it up).  It may not even be possible.  (Those with more
>> operational knowledge of IANA can weigh in here.)
>>
>> Without excluding possible solutions, our fundamental task is to
>> transition stewardship of IANA from the NTIA to some other group, entity or
>> process, not to transition IANA.
>>
>> Greg Shatan
>>
>> On Oct 15, 2014 5:10 PM, "WUKnoben" <wolf-ulrich.knoben at t-online.de>
>> wrote:
>>
>>   Guru,
>>
>>
>>
>> 1. I’m not able to comment on any hypothetical approaches rather than
>> looking forward to the incoming substantial proposals.
>>
>>
>>
>> 2. I’m in agreement that all possible options have to be taken into
>> consideration diligently.
>>
>>
>>
>> 3. In order to achieve a common consensus based proposal there is
>> obviously extensive communication needed between the 3 lines already
>> throughout this process and not after the different proposals have been
>> submitted to the ICG. I’m hoping that your hypotheses are still hypotheses.
>>
>> Best regards
>>
>> Wolf-Ulrich
>>
>>
>>
>> *From:* Guru Acharya <gurcharya at gmail.com>
>>
>> *Sent:* Wednesday, October 15, 2014 3:53 PM
>>
>> *To:* WUKnoben <wolf-ulrich.knoben at t-online.de>
>>
>> *Cc:* Gomes, Chuck <cgomes at verisign.com> ; Krishna Seeburn
>> <seeburn.k at gmail.com> ; cwg-stewardship at icann.org
>>
>> *Subject:* Re: [CWG-Stewardship] Names Community vs the other two
>> communities
>>
>>
>>
>> What do you mean when you say that all three proposals have to be treated
>> in the same way?
>>
>>
>>
>> Hypothetically, consider that the current proposals of the numbers
>> (AOC+SLA with NRO) and protocol (MOU with IETF) community are their final
>> proposal to the ICG. Also consider that Option (i) mentioned in this mail
>> is the final proposal of the names community to the ICG.
>>
>>
>>
>> I believe that all three proposals can co-exist as the new entity
>> suggested in Option (i) will only have oversight over the IANA that relates
>> to the names community - assuming we can structurally separate the IANA of
>> the three communities. Do you think that such structural separation of the
>> three IANAs is feasible?
>>
>>
>>
>> On Thu, Oct 16, 2014 at 3:34 AM, WUKnoben <wolf-ulrich.knoben at t-online.de>
>> wrote:
>>
>>   +1
>>
>>
>>
>> and btw the reference line quotes “Names Community *vs* the other two
>> communities”.
>>
>>
>>
>> There is nothing “versus” between these 3 lines. They have to be treated
>> in the same way regarding the outcome of a *common* proposal.
>>
>> Best regards
>>
>> Wolf-Ulrich
>>
>>
>>
>> *From:* Gomes, Chuck <cgomes at verisign.com>
>>
>> *Sent:* Wednesday, October 15, 2014 2:43 PM
>>
>> *To:* Krishna Seeburn <seeburn.k at gmail.com> ; Guru Acharya
>> <gurcharya at gmail.com>
>>
>> *Cc:* cwg-stewardship at icann.org
>>
>> *Subject:* Re: [CWG-Stewardship] Names Community vs the other two
>> communities
>>
>>
>>
>> Forgive me for being slow but it is not obvious to me that option 1 makes
>> sense, i.e., ‘create a new legal entity’.  I see it as one option, but
>> before we decide it is the best option we should explore as many options as
>> possible.  Even if we eliminate the other options mentioned below, we
>> should not assume that we have considered all possible options.
>>
>>
>>
>> Chuck
>>
>>
>>
>> *From:* cwg-stewardship-bounces at icann.org [mailto:
>> cwg-stewardship-bounces at icann.org] *On Behalf Of *Krishna Seeburn
>> *Sent:* Wednesday, October 15, 2014 5:30 PM
>> *To:* Guru Acharya
>> *Cc:* cwg-stewardship at icann.org
>> *Subject:* Re: [CWG-Stewardship] Names Community vs the other two
>> communities
>>
>>
>>
>> Thanks for those acharya.
>>
>>
>>
>> IETF and the RIRs were already working in that direction from the very
>> start and even before the official formal announcement from icann / ntia.
>> These were already talks and were well ahead of anything.
>>
>>
>>
>> The option 1 makes sense and in fact i am wondering how much more talks
>> we will have before we can decide on what is more than obvious.
>>
>>
>>
>> The names community however have a different but more challenging
>> approach. As much as we are technical but we have a different impact on the
>> community. Our challenges are way different for sure.
>>
>>
>>
>> But good thinking .., perhaps yes a good way forward. But a consensus in
>> way forward is what matters and we all need to agree and that is the bigger
>> challenge. In whatever we come up with we will need a mid platform to agree
>> with everyone to some point.
>>
>>
>>
>> My 2 cents
>>
>>
>> *Kris Seeburn*
>>
>> skype: kris_seeburn30
>>
>> Linkedin:mu.linkedin.com/in/kseeburn
>>
>>
>> On Oct 16, 2014, at 1:10 AM, Guru Acharya <gurcharya at gmail.com> wrote:
>>
>>   How the names community approach will differ from the approach adopted
>> by the numbers community and protocols community?
>>
>>
>>
>> Numbers Community: APNIC has reached consensus on its proposal. According
>> to the proposal, IANA will continue to reside in ICANN. It proposes to
>> replace NTIA oversight with a Service Level Agreement (SLA) and Affirmation
>> of Commitment (AOC) between NRO and ICANN.
>>
>> www.slideshare.net/fullscreen/apnic/report-ianatransition/1
>>
>>
>>
>> Protocols Community: The IETF draft proposal suggests that no structural
>> changes are required as a result of the transition. The MOU between ICANN
>> and the IETF community will continue to govern the existing relationship.
>> Again, IANA will continue to reside in ICANN.
>>
>> http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-00
>>
>>
>>
>> Therefore, neither the numbers community, nor the protocol community
>> appear to be in the direction of suggesting a new MS Oversight Entity to
>> replace NTIA and its oversight. Merely contracts between existing entities
>> will be updated to replace NTIA oversight.
>>
>>
>>
>> Can the names community adopt a similar approach? Can a contractual
>> agreement (SLA/AOC/MOU) between ICANN and GNSO/CCNSO be expected to replace
>> NTIA oversight?
>>
>>
>>
>> Clearly NO! This approach can not be adopted by the names community
>> because the names community resides within ICANN, which is also the IANA
>> operator. Specifically, GNSO and CCNSO are essentially subsets of ICANN,
>> and therefore a contractual agreement (SLA/AOC/MOU) between ICANN and
>> GNSO/CCNSO can not be expected to replace NTIA oversight.
>>
>>
>>
>> Therefore, it is essential to either
>>
>>
>>
>> Option (i): create a new legal entity, which has a contractual oversight
>> relationship with ICANN. This would be similar to
>> http://www.internetgovernance.org/2014/08/04/students-school-faculty-on-iana-transition-the-meissen-proposal/
>>
>>
>>
>> Option (ii): expect ICANN to self-regulate
>>
>>
>>
>> Option (iii): make a new legal entity comprising of CCNSO and GNSO that
>> is structurally independent of ICANN and require that new entity to enter
>> into a contractual oversight agreement (SLA/AOC/MOU) with ICANN.
>>
>>
>>
>> From the above three options, clearly option (ii) is not acceptable
>> because of the lack of trust in the ICANN enhanced accountability process.
>>
>>
>>
>> I also feel that option (iii) is not feasible because the CCNSO and GNSO
>> are heavily integrated with ICANN and structural separation of these two
>> communities from ICANN will be in-feasible.
>>
>>
>>
>> Also, from the Jordan Carter document, the option on page 7 can be
>> discarded, which makes ICANN the oversight body, as IANA will continue to
>> reside in ICANN, as clearly suggested by the proposals of the protocols and
>> numbers community.
>>
>>
>>
>> Therefore, option (i) is clearly the only option available with the names
>> community.
>>
>>
>>
>> Regards,
>>
>> Acharya
>>
>>
>>
>>  _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>
>>   ------------------------------
>>
>> _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>
>>
>>
>>
>> _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141018/f1a8b87c/attachment-0001.html>