September 2018 - GNSO-RPM-WG

Identity Theft -- how it affects various proposals submitted
by George Kirikos Sept. 7, 2018

Sept. 7, 2018

Hi folks, Reviewing some of the proposals that were submitted by last night's deadline, I think that they'd encounter some very serious problems in terms of implementation, because of lack of WHOIS verification and vulnerabilities associated with identity theft. For example, there were multiple "loser pays" submissions (I too am on the record as being strongly in favour of "loser pays" as a concept, but I qualified my support, noting (without going into too much detail): https://mm.icann.org/pipermail/gnso-rpm-wg/2018-August/003226.html that (in point #11) the system had to be carefully constructed, with systems of checks and balances in place. While I made submissions on other topics, folks will note I didn't submit one on "loser pays" at this time, because I realized that in order to properly implement a loser pays system one would need to solve a whole series of other problems first. And to solve those other problems first might become a monumental task (I'd be up to that monumental task, but not sure the rest of the PDP members would be willing to do it! If the rest of the group does want to solve them, I'd love to rise to the challenge too). So, here's just one of the major problems that would need to be solved before implementing "loser pays" or penalties --- lack of WHOIS verification which relates to identity theft. Registrars generally don't have any "Know Your Client" requirements and there is no real verification of the true identity of the person/entity that purports to be the registrant. There might be verification that the email address and/or the telephone number are verified. But, all the rest of the fields in the WHOIS can easily be faked, or used to impersonate others to commit identity theft. This is not some theoretical issue. I know first hand, as someone using a Chinese registrar copied my company's WHOIS for a malware domain, see the historical WHOIS at: https://research.domaintools.com/research/whois-history/search/?q=antivirus… (I had a Google Alert triggered, and that's how I noticed it; the attacker changed the phone number by 1 digit from my real phone number, but copied my name, company name, fax, address, and used a gkirikos@ address (obviously not matching my real email address). [I complained to the registrar, and also using an ICANN WHOIS complaint] [NB: with GDPR and redacted WHOIS out there, it could be happening *now* -- how would I know??] This has even happened within UDRP cases, where there has been identity theft, see: http://www.udrpsearch.com/search?query=identity%20theft&search=text&results… for various matches. e.g.: http://www.adrforum.com/domaindecisions/1774660.htm http://www.wipo.int/amc/en/domains/search/text.jsp?case=D2017-1843 So, let's consider various scenarios. If there's a "loser pays" system, new vulnerabilities would be created if a system is not carefully constructed. An attacker could copy someone else's name/identity, use it for cybersquatting, and "lose" a UDRP/URS. Now that victim of identity theft would potentially have a liability for damages on a domain they never actually registered, using a registrar that they never had any relationship with. Most of the time, the registrar simply has a relationship with a purported identity, not a verified identity with a verified relationship (i.e. "Tom Cruise" is a real person, but the famous actor Tom Cruise is unlikely to be the actual registrant with a real relationship with a registrar, if that actor's name is placed into the WHOIS by an attacker). One of the proposals went even further, saying: https://community.icann.org/display/RARPMRIAGPWG/URS+Proposals "the penalties should include (i) a requirement that the registrant deposit funds into an escrow account, or provide an equivalent authorization on a credit card, with each new domain registration (such funds could be dispersed to prevailing complainants in future domain name disputes against that registrant as part of a “loser pays” system), and (ii) a universal blocking of all domain registrations for a set period for the registrant (i.e. “blacklisting” the registrant on a temporary basis)" (from proposal #30) It should be fairly obvious that such a scheme would enable an attacker to engage in a Denial of Service attack against a victim, by impersonating them (stealing their identity). e.g. (a) spend $20 total on a few dozen "throwaway" domains that have a sub-$1 dollar promo price (b) copy the victim's identity on a series of "famousbrand-authorized-store.newgtld" domains (c) wait for the victim to lose the URS/UDRP and be labelled a "repeat offender" or "high volume cybersquatter" Now when the *real* victim wants to register a domain at their real registrar, they'll suddenly encounter their name on a "blacklist"!! To show how truly vulnerable the system is to an attack, there's likely no real verification by the URS/UDRP providers that a *Complainant* is who they say they are! So, let's suppose the "victim" is "John Smith". The attacker has created the cybersquatting domains under the "John Smith" name, using multiple trademarks of Amazon, for example. Instead of waiting for the brandholder Amazon to file a URS (i.e. step (c) above), a truly motivated attacker (think state-funded actors, as an example, that want to interfere with a business competitor or an election) could go even further, and go impersonate the brandholder and file the URS or UDRP actions as a complaint! This email's getting long, and the more sophisticated readers can see where this takes us. I won't go into too much more detail now (can expand later, if desired), but you'd need to develop a system not only to verify identity properly, but also a system to *DISAVOW* domain name registrations. That disavowal system would be very hard for domains (a disavowal system was developed by Google for backlinks, https://support.google.com/webmasters/answer/2648487?hl=en , but that's much easier). [Real verification could take place via a digital signature system, like the one that exists in Estonia, for example] And even if one did verify identity properly (e.g. "John Smith" is labelled a serial cybersquatter), there are so many people that share common names (think China, India) that the blacklist would have collateral damage on many innocent registrants. And here's the thing -- an attacker can simply create a new real identity (even a "verified" one) very cheaply. For £12, (USD $15.59 at the time of this post), one can create a real UK company online within 24 hours: https://www.gov.uk/limited-company-formation/register-your-company (or effectively "free" if one uses a stolen credit card, as criminals tend to do!) So, even a "properly" implemented system would not be effective, if one can create new verified identities at low cost. The only real parties within the ICANN system that *are* verified are registrars and registries, and I think they would likely push back very hard if they are the "losers" who have to pay up. [an unverified Complainant can put up a security bond before filing a complaint, and to that extent that bond could also represent security if the Complainant loses, albeit the Complainant themselves may not be who they say they are. [by the way, I do like the idea of posting security bonds, but not in the manner that the proposals have suggested --- I would want security bonds as a means for registrants to completely *opt-out* of URS/UDRP, so that any disputes for a "bonded" registrant/domain can be handled only by the courts] Even the real legal system (court system) could be subject to attempts at foul play using these kinds of tricks. However, real courts have much stronger due process mechanisms and machinery (e.g. court orders, contempt, etc.) to deal with them (e.g. subpoena the registrar who enabled the identity theft, discovery, etc.) and the real victim would have to be properly served, etc.. URS/UDRP providers don't have those strong mechanisms or powers. So, I'm very sympathetic to the motivation behind these proposals, and the objective to go after the bad guys. I want loser pays too, in order to protect my company from frivolous complaints. I know others with valuable domains want the same thing. But, the proposals on the table right now will need much, much more work before I can support them. All the various vulnerabilities that are present in the system *today* will be magnified if "loser pays" or "penalties" are adopted without addressing issues like verification and identity theft first. Sincerely, George Kirikos 416-588-0269 http://www.leap.com/ P.S. I don't know if we have any SSAC members on this PDP, but the broader issue of vulnerabilities and identity theft might be passed on to them for advice.

2 1

URS Proposal Submissions - 06 Sep 2018 & Final Count
by Ariel Liang Sept. 7, 2018

Sept. 7, 2018

Dear RPM WG members, This is to let you know that fourteen (14) URS Proposals were submitted by COB today (06 Sep 2018). Today is the deadline for individual WG members to submit Proposals for URS policy and operational recommendations. The SurveyMonkey form has been closed. By the deadline, thirty-three (33) URS Proposals have been submitted. You may see all the Proposals uploaded to the wiki page here: https://community.icann.org/x/aACNBQ Best Regards, Mary, Julie, Ariel & Berry

1 0

Correction: URS Proposal Submissions - 05 Sep 2018
by Ariel Liang Sept. 6, 2018

Sept. 6, 2018

Dear All, Correction – yesterday (05 September 2018), Kristine Dorrain submitted one (1) URS Proposal and George Kirikos submitted five (5) URS Proposals. Staff erroneously mentioned Zak. Apologies for the confusion. Best Regards, Mary, Julie, Ariel & Berry From: Ariel Liang <ariel.liang(a)icann.org> Date: Wednesday, September 5, 2018 at 9:31 PM To: "gnso-rpm-wg(a)icann.org" <gnso-rpm-wg(a)icann.org> Subject: URS Proposal Submissions - 05 Sep 2018 Dear RPM WG members, This is to let you know that George Kirikos submitted five (5) URS Proposals and Zak Muscovitch submitted one (1) URS Proposal by COB today (05 Sep 2018). You may see the proposals uploaded to the wiki page here: https://community.icann.org/x/aACNBQ Best Regards, Mary, Julie, Ariel & Berry

1 0

Re: [gnso-rpm-wg] URS / UDRP proposals -- data on registrar/registry compliance costs
by George Kirikos Sept. 6, 2018

Sept. 6, 2018

Hi Maxim, On Thu, Sep 6, 2018 at 4:10 AM, Maxim Alzoba <m.alzoba(a)gmail.com> wrote: > These days, criminals interact on purely economical basis, and weakened > interaction between Yes, that's a very important point that should not be lost in all this debate. The URS and UDRP don't really attack the economic aspect of cybercrime (including cybersquatting) very well, in my opinion. That's why the Verizon/iREIT lawsuit was so effective (as previously discussed on this mailing list), as was as the Verizon/OnlineNic case: https://www.nytimes.com/2008/12/25/technology/companies/25verizon.html https://www.theregister.co.uk/2009/08/27/onlinenic_verizon_ruling_upheld/ Remember that scene from Batman? https://www.youtube.com/watch?v=DJS7NaktQ8g "I want you to tell all your friends about me." Those highly publicized cases told active and prospective cybersquatters all about Verizon, and not to mess with them. I'm sure many cybersquatters cleared out their portfolios of anything Verizon-related due to these actions. We've also seen evidence of the decline in the profitability of cybersquatting by looking at how many UDRP cases CitizenHawk has filed over time: http://www.udrpsearch.com/search?query=citizenhawk&search=text&results=100&… Just 3 cases in 2018 so far. As many members of this PDP are likely already aware, they file UDRPs on behalf of companies at no cost up front, but in exchange they monetize the traffic from the domains that are won: https://icannwiki.org/CitizenHawk The fact that we've seen such a sharp decline in cases they've brought is consistent with the fact that cybersquatting is less profitable than it used to be, because the problem has been addressed in other ways (e.g. getting domains banned at various monetization services like Google Adsense or parking companies, affiliate programs, credit card processors, hosting companies, Google Safebrowsing, etc.). CitizenHawk is driven purely by economics, so there are just fewer profitable typosquatting domains out there that they can successfully target via their business model. In conclusion, consistent with your statement, attacking the economics of cybercrime in more targeted manner (to deter the practice because it's simply unprofitable) is far more effective than to try to "punish" the criminals with a "weak" domain transfer (UDRP) or suspension (URS). The biggest criminals tend to be highly rational economic actors, otherwise they don't survive in "business" very long. Sincerely, George Kirikos 416-588-0269 http://www.leap.com/

1 1

URS Proposal Submissions - 05 Sep 2018
by Ariel Liang Sept. 6, 2018

Sept. 6, 2018

Dear RPM WG members, This is to let you know that George Kirikos submitted five (5) URS Proposals and Zak Muscovitch submitted one (1) URS Proposal by COB today (05 Sep 2018). You may see the proposals uploaded to the wiki page here: https://community.icann.org/x/aACNBQ Best Regards, Mary, Julie, Ariel & Berry

1 0

Actions & Notes: RPM PDP WG Meeting 05 Sept 2018
by Julie Hedlund Sept. 5, 2018

Sept. 5, 2018

Dear All, Please see below the action items and notes captured by staff from the RPM PDP Working Group call held on 05 September 2018 (12:00-14:00 UTC). Staff have posted to the wiki space the action items and notes. Please note that these will be high-level notes and are not meant as a substitute for the recording. The recording, AC chat, and attendance records are posted on the wiki at: https://community.icann.org/display/RARPMRIAGPWG/2018-09-05+Review+of+all+R…. See also the attached referenced documents. Best Regards, Julie Julie Hedlund, Policy Director == ACTION ITEMS: Page 6, First Bullet: ACTION ITEM 1: Change “WHOIS” to “WHOIS/RDDS” and “Providers should modify their operational rules in terms of automatically populating the Complaint Form using WHOIS data [using WHOIS/RDDS data consistent with applicant ICANN Consensus Policies]” ACTION ITEM 2: Ask the Providers Sub Team to rework the language. Page 6, Second Bullet: ACTION ITEM: Ask the Providers Sub Team to clarify the notion of developing rules. Page 10: ACTION ITEM: Check that the reference to 4.2 is the intended reference. Pages 27-28: ACTION ITEM 1: Review the language in the recommendations to capture the compliance concept while leaving the implementation details open, but seek community feedback. ACTION ITEM 2: Staff to inquire and then inform the WG which ICANN body is responsible for enforcing URS Provider MOUs -- GDD Compliance, ICANN Legal, or both? NOTES: 1. Review Agenda/Statements of Interest Updates -- Maxim Alzoba: Selected as GNSO Council representative from the Registry Stakeholder Group to be seated at ICANN63. -- Kathy Kleiman: Upcoming update -- starting at Princeton as a visiting scholar. -- Brian Beckham: Updated that he has been an observer to the IGO Curative WG and that he is a Co-Chair of the RPM PDP Working Group. 2. Reminder Concerning the Procedures for URS Policy and Operational Recommendations and Revised Proposal Submission Deadline of COB on September 6th (see attached document) 3. Begin Discussion of URS Policy and Operational Recommendations (see attached Super Consolidated URS Topics Table): Operational Fixes Page 4 -- Proposal: Fully automate the list of cases with a centralized database/single repository of all cases provided in .XML format. The question of how a centralized database would be paid for and managed could be included in the Initial Report to seek feedback as there are different opinions on how to implement the recommendation. For example, this might be achieve via the inclusion of an EPP extension showing that there is a pending URS/UDRP proceeding, although this would require at least 180 days for implementation. -- Rule 3(g) “A URS Complaint may not be filed against a domain name that is part of an open and active URS or UDRP case” governing the overlapping of cases suggested that the implementation of this operational fix should be in the form of a suggestion, rather than a policy. It could become part of the Providers pre-action checklist. WG Agrees with the operational fix and on seeking feedback on ways to implement it. Page 6: First Bullet: -- Rationale for the operational fix: Post GDPR many complaints will be brought where the registrant is unknown. The Sub Team wanted to find a way to update the complaint to be able to indicate who the registrant is. ACTION ITEM 1: Change “WHOIS” to “WHOIS/RDDS” and “Providers should modify their operational rules in terms of automatically populating the Complaint Form using WHOIS data [using WHOIS/RDDS data consistent with applicant ICANN Consensus Policies]” ACTION ITEM 2: Ask the Providers Sub Team to rework the language. Second Bullet: -- Rationale for the operational fix: UDRP Rules, para 4(a) and 4(b) on the notion of a registry responding to a request. -- The public should have input on the development of any rules. Could change to "proposed rules that are approved by the GNSO". -- Note that the URS is currently not a Consensus Policy, so it is binding on registry operators via contract. Anything we would propose would require sufficient lead time and discussion. ACTION ITEM: Ask the Providers Sub Team to clarify the notion of developing rules. Page 10: WG agrees that ADNDRC should change its operations to come into compliance. There is a separate question of compliance generally and which topics fall into that general category. General suggestion: when the WG develops the text for the recommendations and proposals for the Initial Report, the text should be changed to phrase it without mentioning a particular provider. ACTION ITEM: Check that the reference to 4.2 is the intended reference. Page 11: -- There is a GDD portal through which ICANN contacts registries and registrars, but not sure we need to specify that at this point. There is no third party access currently. Best we could expect is that URS Providers could view the current list of contacts. WG agrees with the operational fix on the need for ICANN, Registries, Registrars, and Providers to have access to up-to-date contact information and for interaction. Page 16: -- Rationale for the operational fix: Envisioned that this would be a light recommendation to supplement existing policies, rather than creating a new policy. -- Possible questions for feedback in the Initial Report: Who would pay for this and does it also apply to examiners? Who would have responsibility for the overarching guidance repository? -- Educational materials should be made public. -- Note that this language was recently modified in the last iteration of the Super Consolidated document. -- Could be a more generalized suggestion, with this language being a possible implementation detail. -- Suggested including the text: "Any materials should be translated in the UN 6 languages." WG agrees with the operational fix on the need to develop educational materials, but wording could be rephrased to leave out specific implementation details, such as hiring Researchers/and or Academics. Page 17: -- Possible questions for feedback in the Initial Report: Who should have the responsibility to develop guidance and pay for the development? WG generally agrees with the operational fix that there should be guidance for practitioners and examiners; companion concept would be for a checklist; also in general for the public, including registrants and complainants. Page 27: -- Seems to be an umbrella theme of compliance. -- Could apply to URS and UDRP, but there doesn't seem to be a reason to hold up a recommendation for the URS. -- Is this a job for ICANN Compliance (which enforces Registry/Registrar contracts) or for ICANN Legal? The Providers MOUs are entered into by ICANN. So perhaps it should be just ICANN. -- There is a difference between monitoring and responding to complaints. Monitoring is a larger undertaking/responsibility. Typically ICANN Org does not continuously monitor these types of issues; a complaint is first filed. -- A Provider could be subject to an audit. -- The MOU contains a termination clause for Provider's failure to comply with terms of MOU or the URS Procedures or Rules. -- Question to staff: Is it already possible to register a complaint through ICANN's complaint portal? Answer: For the URS typically these are handled by ICANN Compliance. The complaint or question must first be addressed to the URS Providers directly. There also are forms where a Provider or a Complainant can file a complaint. See: https://www.icann.org/resources/pages/urs-2013-10-31-en. WG generally agrees with the operational fix, but may ask the WG to reword it with respect to either proactive or reactive monitoring by ICANN. Pages 27-28: -- Any thoughts on how this effort could be achieved? Registries and Registrars must comply with their contracts and there are already ways to enforce compliance. URS is a policy both Registrars and Registries have to follow, and it is enforceable (Registry has to lock in 24 hours), but there is an implication with an extension for a year. -- There is a gap throughout the recommendations: database, compliance monitoring, publication of educational guides. Consider as a WG whether there needs to be some kind of URS/UDRP Commissioner to provide oversight, or an Ombudsperson for URS/UDRP. Could also be a standing advisory committee; however, there is a big distinction between the advisory committees and other structures under the Bylaws. -- There is an effort in the GNSO to review all consensus policies. Also, for PDP WGs to include metrics. Some WGs are developing recommendations for when and how policies could be reviewed. The WG could consider these points. WG generally agrees with the operational fix and the concept of increased monitoring and/or compliance. The WG should seek community feedback on how to implement/activate. ACTION ITEM 1: Review the language in the recommendations to capture the compliance concept while leaving the implementation details open, but seek community feedback. ACTION ITEM 2: Staff to inquire and then inform the WG which ICANN body is responsible for enforcing URS Provider MOUs -- GDD Compliance, ICANN Legal, or both? Page 33: The WG has discussed already in detail and agrees with the operational fix. Page 39: -- The WG may want to reword the operational fix so that it is not specific to ADNDRC. -- there are individual proposals which suggest rewording of Rule 6(a) "Each Provider shall maintain and publish a publicly available list of Examiners and their qualifications". See: https://community.icann.org/display/RARPMRIAGPWG/URS+Proposals The WG agrees with the operational fix, pending discussion of related proposals.

1 0

Recordings, attendance & AC chat from Review of all Rights Protection Mechanisms (RPMs) PDP Working Group call on Wednesday, 05 September 2018
by Andrea Glandon Sept. 5, 2018

Sept. 5, 2018

Dear all, Please find the attendance and AC Chat attached to this email, and the MP3 & AC recording below for the Review of all Rights Protection Mechanisms (RPMs) PDP Working Group call held Wednesday, 05 September 2018 at 12:00 UTC. Attendance and recording of the call is also posted on agenda wiki page: https://community.icann.org/x/YAKNBQ MP3: https://audio.icann.org/gnso/gnso-rpm-review-05sep18-en.mp3 <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p6xwhm4cskm/<https://participate.icann.org/p6xwhm4cskm/?OWASP_CSRFTOKEN=1878425a032e0b15…> The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-rpm-wg/ Main wiki page for the working group: https://community.icann.org/x/wCWAAw [community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> Thank you. Kind Regards, Andrea Glandon

1 0

URS Proposal Submissions - 04 Sep 2018
by Ariel Liang Sept. 5, 2018

Sept. 5, 2018

Dear RPM WG members, This is to let you know that George Kirikos submitted three (3) URS Proposals by COB today (04 Sep 2018). You may see the proposals uploaded to the wiki page here: https://community.icann.org/x/aACNBQ Best Regards, Mary, Julie, Ariel & Berry

1 0

Revised Proposed Procedures for URS Policy and Operational Recommendations
by Julie Hedlund Sept. 4, 2018

Sept. 4, 2018

Dear RPM PDP Working Group members On behalf of the Co-Chairs, please see the attached revised Proposed Procedures for URS Policy and Operational Recommendations. As noted previously, the Co-Chairs believe that these procedures will efficiently and fairly facilitate the RPM PDP Working Group discussion and development of URS policy and operational recommendations over the course of the upcoming Working Group meetings in September, beginning with our next meeting. Please note that the deadline for submission of member proposals for URS operational and policy modifications has been extended to COB on Thursday, September 6th. The Co-Chairs have fully discussed and considered the comments on the initial version of the Proposed Procedures. As a result, the attached revised document, with changes in redline, includes the following changes from the version initially sent on 21 August, and revised per the Working Group discussion at the meeting on 22 August: Section 1, bullet 1: Add the sentence, “The WG will be working off from the “Super Consolidated URS Topics Table” for the review of the URS Sub Teams’ operational and policy proposals.” Section 1, bullet 2: Date for commencement of staff presentations of Sub Team proposals changed to August 29. Section 2, bullet 1: Clarification that the WG will be addressing Sub team “operational and policy” proposals. Section 2, bullet 6: Change the deadline for proposal submissions from COB Friday, 31 August to COB Thursday, 06 September so that the Co-Chairs will begin to consider proposals at their weekly meeting on Friday, 07 September. Section 3, new bullet 4: Added a procedure to address Phase 2 proposals. Section 6: Change “significant support” to “adequate” (meaning support from Working Group members that in the Co-Chairs’ judgment is of a level for which public comments should be sought via the Initial Report) throughout. Under the heading “During the presentation”: Bullet 3: add “However, if there is exceptionally high interest in a topic, the Co-Chairs would have discretion to increase the discussion time.” Bullet 4: change “two (2) minutes” to “four (4) minutes” to allow individual proposers more time to respond to comments. Section 7: Change “significant support” to “adequate support” throughout. Bullet 1: add “the Co-Chairs may suggest for WG consideration a consolidated proposal that includes elements of the multiple related proposals.” Bullet 2: change “substantial opposition” to “substantial material opposition” and after “Initial Report” add, “for the purpose of soliciting public comment thereon.” Additional language also clarifies that Sub Team proposals only enjoy a rebuttable presumption of adequate support for inclusion in the Initial Report to solicit community input, but no advantage over individual proposals for inclusion as Final Report recommendations. The Co-Chairs would like to re-emphasize that the Working Group faces a significant challenge in adhering to its current timeline and completing its URS work for the Initial Report by the end of September. It is therefore imperative that the Working Group agrees on tight procedures that provide a fair opportunity for all members to propose operational and policy modifications to the URS. In addition, the procedures should facilitate identification of those proposals that lack an adequate level of support as well as those that may be deferred to Phase Two of the Working Group’s efforts because they are substantially intertwined with UDRP issues. The Co-Chairs note that there have been questions raised as to the role of Sub Teams vis-à-vis that of the full Working Group, particularly in relation to the treatment of Sub Team proposals. Under the GNSO Working Group Guidelines, Sub Teams may be used “as an efficient means of delegating topics or assignments to be completed [and] sub-teams report their results to the whole Working Group for review and approval” (Section 2.3). The three URS Sub Teams have spent a considerable amount of time and conducted extensive deliberations that have resulted in their various reports to the full Working Group and the findings and proposals now reflected in the Super Consolidated URS Topics Table. As highlighted during the last Working Group call, the full Working Group is now being requested to carefully review and discuss those proposals. It is also important to note that the Working Group Guidelines “encourage representational balance [on Sub Teams] to the degree possible. However, it should be understood that there will not always be volunteers from every interest group and that it is often acceptable to have a small sub-team that is not totally representational perform an initial role that will later be reviewed by a broader more representational group” (Section 2.2.). In any event, the revised Procedures make clear that Sub Team recommendations only have a rebuttable presumption, subject to Working Group feedback, of enjoying an adequate level of support to be included in the Initial Report for the purpose of soliciting community input; and that Sub Team proposals, like those from individuals, will only become Final Report recommendations if they achieve Full Consensus or Consensus. Unless Working Group members have specific objections to the revisions or wish to raise concerns that have not been voiced to date, these Proposed Procedures will go into effect as of the next Working Group meeting on Wednesday, 05 September, during which the Working Group will use the “Super Consolidated URS Topics Table” (as updated by staff following the last Sub Team calls) for the review of the URS Sub Teams’ proposals. A new version of that document will be sent shortly and Working Group members are requested to be prepared to discuss the Sub Teams’ proposals for policy or operational changes. For those instances where Sub Teams have agreed that no additional policy work is required, WG members can propose otherwise. Best regards, Mary, Julie, Ariel & Berry On behalf of the RPM PDP Working Group Co-Chairs

2 1