<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Alissa<br>
    <br>
    Overlap.&nbsp; Some proposals may cover the same ground in related
    functions (overlap) but not interfere with each other and create no
    conflict.&nbsp; That is not an issue needing to be resolved.<br>
    <br>
    As to the ICANN accountability cross reference placeholder; it was a
    holdover question (do we need a placeholder with possible text if we
    do) more than a drafting suggestion.<br>
    <br>
    Joe<br>
    <br>
    n 12/9/2014 6:19 PM, Alissa Cooper wrote:<br>
    <blockquote
      cite="mid:1EE25B29-D5FC-4972-A00F-B0DD337AA81E@cooperw.in"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      I have consolidated the comments and edits from Milton, Adiel,
      Joe, and Russ in the attached v4 &lt;<a moz-do-not-send="true"
href="https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization%20process">https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization%20process</a>&gt;.
      I accepted changes on all the text where no one had commented for
      easier reading. I also inserted a few comments/edits of my own the
      proposed changes, which I repeat below.
      <div><br>
      </div>
      <div>Step 1a, bullet 3: Milton suggested using "Whether the
        proposal obtained consensus&#8221; instead of &#8220;How the proposal
        obtained consensus.&#8221;&nbsp;</div>
      <div>I am fine with &#8220;whether.&#8221; I would also be fine with &#8220;Whether
        and how.&#8221; &nbsp;In the RFP, we ask the communities to explain &#8220;the
        steps that were taken to develop the proposal and to determine
        consensus.&#8221; I would consider a list of those steps to be the
        &#8220;how.&#8221;</div>
      <div><br>
      </div>
      <div>Step 1b: Adiel suggested adding a bullet about timeliness.&nbsp;</div>
      <div>I do not think this is actionable and so should not be
        included. If we get a proposal after the target deadline, I do
        not believe we are in a position to do anything other than start
        conducting the assessment in step 1. Of course, if we get a
        proposal many weeks/months after the target deadline, it will
        create some chaos for all of the steps afterward, but I don&#8217;t
        really see a lot of value in specifying how we will handle every
        possible case of that sort that could arise depending on the
        exact timing and sequence of the arrival of the component
        proposals.</div>
      <div><br>
      </div>
      <div>Step 2: Adiel questioned whether the statement that the ICG&#8217;s
        role &#8220;is not to draft a single transition proposal&#8221; is accurate.</div>
      <div>I believe it is accurate, in the sense that we are not
        &#8220;drafting&#8221; or writing anything of our own. I added the words &#8220;of
        its own&#8221; to the end of that phrase to try to make this more
        clear.</div>
      <div><br>
      </div>
      <div>Step 2: Adiel questioned the use of the word &#8220;unifying.&#8221;</div>
      <div>I agree that &#8220;unifying&#8221; and &#8220;uniform&#8221; are confusing. I
        believe our task is one of assembly. Our goal is to end up with
        one document, but not to massage the text of the component
        proposals to achieve &#8220;unity.&#8221; I have replaced the word &#8220;unified&#8221;
        in this section with the word &#8220;single&#8221; to make this clear.&nbsp;</div>
      <div><br>
      </div>
      <div>Step 2a: Joe inserted &#8220;possibly conflicting&#8221; as a qualifier
        for &#8220;overlaps&#8221;</div>
      <div>I don&#8217;t understand what a conflicting overlap is, and I think
        the proposals need to have a coherent story about all overlaps.
        So I disagree with this addition.&nbsp;</div>
      <div><br>
      </div>
      <div>Step 2b: Joe asked whether we need to cross-reference the
        ICANN accountability work.</div>
      <div>I think this is already covered by the fact that we are
        already asking "Do the proposals together include appropriate
        and properly supported independent accountability mechanisms for
        running the IANA function?&#8221;</div>
      <div><br>
      </div>
      <div>Step 2c: There has been list discussion between Joe and Russ
        about testing.</div>
      <div>I suggested some text as a middle ground approach. In the RFP
        we do ask the communities to describe any testing they do. I&#8217;m
        not quite sure how the test results could conflict with each
        other or otherwise be problematic in combination, but I&#8217;m happy
        to check for that when we&#8217;re assembling the single proposal.</div>
      <div><br>
      </div>
      <div>Step 5: I have made the latest changes suggested on the list
        by Milton, which I think address everyone&#8217;s concerns.</div>
      <div><br>
      </div>
      <div>Alissa</div>
      <div><br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Internal-cg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Internal-cg@icann.org">Internal-cg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/internal-cg">https://mm.icann.org/mailman/listinfo/internal-cg</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>