[RZERC] RZERC Procedures redline and clean copy docs

[Russ Mundy]

Duane,

I’d be okay with this wording.  I also got email from Peter asking if we could have a face to face chat in Johannesburg which is now possible since I arrived (2 days late :-(( ) this evening.

I’m trying to get my schedule nailed down but I’ll try to get together with Peter while we’re here - would you like to join us?

Russ

> On Jun 27, 2017, at 1:05 AM, Wessels, Duane <dwessels at verisign.com> wrote:
> 
> Russ/Peter, how does this text strike you?
> 
> For the types of proposals that RZERC expects to receive, the ICANN Board
> is likely to receive input from other groups, supporting organizations,
> and advisory committees.  RZERC's recommendations on a given proposal
> may not necessarily be in alignment with these other groups, including
> those that have appointed members to RZERC.
> 
> DW
> 
> 
> 
>> On Jun 23, 2017, at 9:25 AM, Russ Mundy <mundy at tislabs.com> wrote:
>> 
>> Peter,
>> 
>> It’s entirely possible that we have different views on this but I’ll see if some clarifications help.  
>> 
>> While I agree that there is nothing in the RZERC charter that restricts any other activity (I agree that this is the right way to have a charter written), I can say from my experience in the whole combination of SO/ACs & CCWGs that worked on the IANA transition (which is where the need for an RZERC was identified), some noticeable number of people thought that RZERC would effectively be _the_ most influential body WRT root zone architecture changes.  The end result of which is that recommendations to the Board from, for example, SSAC or RSSAC, would not be as “important” or “influential” as those from RZERC and the Board would be somehow ‘required’ to follow the RZERC recommendations if other activities did not have the same recommendation.  
>> 
>> Additionally, there were some (usually other) people had the view that a requirement existed or some “magic process” would be run whereby the recommendations from RZERC and all of the designating activities would somehow be in total alignment.  
>> 
>> The words that I tried to craft to carefully say:
>> 
>> - RZERC is not required to align their recommendations with those of the designating organizations & visa versa; (if this is not true then it would directly impact RZERC operational procedures)
>> 
>> - The RZERC mission is to provide information to the Board - it is strictly up to the Board (since they are the decision makers) what they do with the information from RZERC (as well as any other organization that provides them with information) (BTW, I used the word ‘additional’ since the Board has not previously received such information, it’s probably best to not use it.)
>> 
>> Hopefully, does this provide useful clarification?
>> 
>> Russ
>> 
>>> On Jun 23, 2017, at 3:14 AM, Peter Koch <pk at denic.de> wrote:
>>> 
>>> Russ, all,
>>> 
>>> On Thu, Jun 22, 2017 at 06:44:36PM -0400, Russ Mundy wrote:
>>> 
>>>> Organizations/groups that designate RZERC members might also submit recommendations or comments to the ICANN Board of Directors on the proposed changes.  RZERC recommendations should be considered additional information that the ICANN Board may use to make their decisions on the proposed changes. RZERC recommendations are not intended to be a substitute for recommendations/comments made by the organizations/groups that designate RZERC members.
>>> 
>>> while I think I understand where you're coming from, this text is not
>>> covering procedures internal to RZERC. The current charter does not
>>> constrain any existing AC/SO/others in its rights or duties, whereas the
>>> first sentence above would generate additional opportunities for
>>> such those entities not already in an advisory position (the truism
>>> that anybody might write to the ICANN Board anytime anyway set aside).
>>> Also, the instrument of minority statements is already in the draft.
>>> The second sentence above turns the RZERC mission upside down by
>>> qualifying RZERC output "additional information". And again,
>>> the internal procedures cannot guide the ICANN Board which
>>> "additional information" it may or may not use.
>>> 
>>> I do  not agree with this proposed change.
>>> 
>>> Regards,
>>> Peter
>> 
>