- Gnso-newgtld-wg - lists.icann.org

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 02 June at 03:00 UTC for 90 Minutes
by Julie Hedlund May 28, 2020

May 28, 2020

Dear all, Please find below the proposed agenda for the call on Tuesday, 02 June 2020 at 03:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics: * Review "Can't Live With" comments on packages 1-3: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… b. Review Category 1/Verified TLDs in 2.3.2 Registry commitments / Public Interest Commitments: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…, page 139; see also the ICANN46 Beijing Communique’ at: https://gac.icann.org/contentMigrated/icann46-beijing-communique * DNS Abuse (time permitting) in 2.3.2 Registry commitments / Public Interest Commitments – see attached GAC comments and https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…, page 143 1. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 28 May 2000 UTC
by Julie Hedlund May 28, 2020

May 28, 2020

Dear Working Group members, Please see below the notes from the meeting on 28 May at 2000 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-05-28+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Types of New gTLD Subsequent Procedures WG outputs Implementation Guidance: -- Re: “However, the party to whom the action is directed must make all efforts to achieve the purpose behind the recommended action even if done through a different course.” ACTION ITEM: With respect to “purpose” -- add language about rationale and potentially, the high-level recommendation that the IG is applicable to. 2.4.2 Communications: Implementation Guidance xx: ACTION ITEM: WG reviewed and determined that the correct terminology is “should” rather than changing this to a recommendation (must). Add a bullet: “The impact of comments [made on applications] collected through the comment forums referred to in Implementation Guideline C is addressed separately (see xx Role of Application Comment).” ACTION ITEM: WG agrees with the addition and inserted “made on applications” after “comments”. 2.4.3 Systems: Re: It should not be possible to auto-fill responses to questions corresponding to the following questions in the 2012 Applicant Guidebook: [16], 18(a), 18(b), 19, 20, 21, [22], and 23 (but only if additional services are specified). It should not be possible to auto-fill Registry Voluntary Commitments (formerly called voluntary PICs). ACTION ITEM: Remove the brackets from 16 and 22 and clarify that the text “(but only if additional services are specified)” applies only to 23. Also, re: Question 23, draft a better definition of "additional services", ie "other than basic pre-approved services" 2.5.1 Application Fees & 2.5.2 Variable Fees Implementation Guidance xx (rationale 1): ACTION ITEM: WG agrees to keep the language as it was. Affirmation xx with modification (rationale 2): ACTION ITEM: The WG agrees to leave the language as it was. Implementation Guidance xx (rationale 3): ACTION ITEM: WG agrees to add the new Implementation Guidance. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should [must] be used to benefit one or more of the following elements of the New gTLD Program: ACTION ITEM: The WG agrees to change the text from Implementation Guidance to a Recommendation. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Types of New gTLD Subsequent Procedures WG outputs -- See: https://docs.google.com/document/d/1CYOruGqewTsu5ejL_zoom0ol6VA1xMLX2FXW2VA… -- Question: Definition of the status quo -- any issue other than the case of Closed Generics? Does “status quo” have a clear meaning for other issues? Answer: One is Closed Generics and the other is priority of IDN applications. -- What about Brands/Spec 13? Implementation Guidance: -- Re: “However, the party to whom the action is directed must make all efforts to achieve the purpose behind the recommended action even if done through a different course.” ACTION ITEM: With respect to “purpose” -- add language about rationale and potentially, the high-level recommendation that the IG is applicable to. No Agreement: -- Question: Is this meant to be “no consensus”? Answer: Not at this time, but it could be for the final recommendations. There is no consensus call for the Draft Final Report. 3. Discussion of Final Report Topics: a. Review "Can't Live With" comments on packages 1-3: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… 2.4.2 Communications: “Implementation Guidance xx: For timeliness, the Working Group believes that for the next subsequent round, the Communications Period should [must] begin at least six (6) months prior to the beginning of the application submission period.” C1.3 - Justine Chew proposed changing the word "should" to "must" in this sentence. Rationale: "1. Since insufficient awareness of the Program prior to the last round is well acknowledged, this Implementation Guidance ought to prescribe – not merely suggest – a minimum time period for the next round’s Communications Period. 2. Prior WG discussion on the distinction between the terms “must” and “should” and when either ought to be used, applies." ACTION ITEM: WG reviewed and determined that the correct terminology is “should” rather than changing this to a recommendation (must). d. Dependencies/relationships with other areas of this report or external efforts Add a bullet: “The impact of comments [made on applications] collected through the comment forums referred to in Implementation Guideline C is addressed separately (see xx Role of Application Comment).” JC1.2 - Justine Chew proposed adding new text. Rationale: "Proposed change does not impact rationale but instead adds necessary clarity by addressing omission of a dependency to theRole of Application Comment section." ACTION ITEM: WG agrees with the addition and inserted “made on applications” after “comments”. 2.4.3 Systems: Allow applicants to auto-fill information/documentation in multiple fields across applications. This functionality should only be enabled in a limited number of fields where it would be appropriate for responses to be identical. It should not be possible to auto-fill responses to questions corresponding to the following questions in the 2012 Applicant Guidebook: [16], 18(a), 18(b), 19, 20, 21, [22], and 23 (but only if additional services are specified). It should not be possible to auto-fill Registry Voluntary Commitments (formerly called voluntary PICs). ACTION ITEM: Remove the brackets from 16 and 22 and clarify that the text “(but only if additional services are specified)” applies only to 23. Also, re: Question 23, draft a better definition of "additional services", ie "other than basic pre-approved services" 2.5.1 Application Fees & 2.5.2 Variable Fees Implementation Guidance xx (rationale 1): [For example, if the Technical Evaluation Fee portion of the overall Application Fee is $US25,000, that portion of the Application Fee should only be charged to those applicants that do not select a pre-evaluated registry service provider (which has not been removed from the pre-evaluated registry acceptance list and does not have major incident reports pending against it).] KK1.2 - Kathy Kleiman proposed adding the text in bold to this sentence. No rationale was provided. ACTION ITEM: WG agrees to keep the language as it was. Affirmation xx with modification (rationale 2): [The Working Group believes, however, that for subsequent procedures the only historical costs that should be part of the cost structure in determining application fees are those actual and anticipated costs of implementation and subsequent administration of the New gTLD Program, including but not limited to costs arising from new legal compliance and/or policy development processes that may be required.] AAS1.2 - Anne Aikman-Scalese proposed alternate text for the second half of the sentence (in bold). Rationale: "The 2012 round demonstrates that significant costs can arise subsequent to applications being delegated. For the 2012 round, this included funding procedures for further policy development, interacting with regulatory authorities, launching an EPDP, and running the Sub Pro PDP. It’s not realistic to believe that ICANN can adequately determine and budget application fees without considering the ongoing indirect costs of the nature described above." ACTION ITEM: The WG agrees to leave the language as it was. Implementation Guidance xx (rationale 3): A reassessment should take place prior to each application round to estimate the application fee that would be necessary to achieve cost recovery. In the event that the estimated application fee, based on the revenue neutral principle, falls below a predetermined threshold amount (i.e., the application fee floor), the actual application fee should be set at that higher application fee floor instead. Neustar1.2 - Donna Austin comment: "It’s not a cannot live with issue, but rather one of clarity: In reading the whole section it is unclear to me whether the ‘application fee floor’ can be used in the next Subsequent Procedure or only in rounds that follow. I don’t recall the intent so have not suggested any language, but I do believe this is something that should be an explicit recommendation particularly if the intent is that an application fee floor not be used in the initial Subsequent Procedure." New text: Implementation Guidance xx (rationale 3): The development of the Application Fee should be fully transparent with all cost assumptions explained and documented. Neustar1.3 - Donna Austin/Neustar proposed adding new Implementation Guidance. Rationale: "This section would benefit from Implementation Guidance that requires ICANN to be transparent in how they arrived at the Application Fee amount for the Subsequent Procedure and all rounds that follow. Particularly when a value has been determined for an application fee floor. One of the challenges we experienced in discussion the application fee for 2012 was the lack of information available on how the fee was determined." ACTION ITEM: WG agrees to add the new Implementation Guidance. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should [must] be used to benefit one or more of the following elements of the New gTLD Program: Neustar 1.1 - Neustar proposed changing "should" to "must" in this sentence. Rationale: "ICANN should not have any discretion regarding excess fees." JC1.4 - Justine Chew proposed changing "should" to "must." Rationale: "1. The word “should” used here suggests that there is an option to use excess fees to benefit one or more of the 4 stated elements (a) to (d). There should be no such option in event there is excess fees. 2. Unlike the Implementation Guidance xx (rationale 4) relating to application fee floor not being implemented where returning of any excess fee to applicants may not be possible, no such limitation is envisaged in respect of excess fees – collected in the event of application fee floor being used – being applied towards the 4 stated elements of the Program." ACTION ITEM: The WG agrees to change the text from Implementation Guidance to a Recommendation.

1 0

Re: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 28 May at 20:00 UTC for 90 Minutes
by Emily Barabas May 28, 2020

May 28, 2020

Dear all, The Co-Chairs will reference one additional document on today’s call, available here: https://docs.google.com/document/d/1CYOruGqewTsu5ejL_zoom0ol6VA1xMLX2FXW2VA… This short document contains draft definitions of terms that are used in the draft Final Report sections, including Affirmation, Affirmation with modification, Recommendation, Implementation Guidance, and No Agreement. It also discusses use of the terms “should” and “must.” Kind regards, Emily From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, 26 May 2020 at 20:56 To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 28 May at 20:00 UTC for 90 Minutes Dear all, Please find below the proposed agenda for the call on Thursday, 28 May 2020 at 20:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics: a. Review "Can't Live With" comments on packages 1-3: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> b. Review Category 1/Verified TLDs in 2.3.2 Registry commitments / Public Interest Commitments: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>, page 139; see also the ICANN46 Beijing Communique’ at: https://gac.icann.org/contentMigrated/icann46-beijing-communique [gac.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gac.icann.org_contentM…> 1. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie

3 2

Deadline 4 June - Comments on Revised Draft Recommendations - Package 4
by Emily Barabas May 28, 2020

May 28, 2020

Dear all, The leadership team is releasing the fourth set of revised draft recommendations for your review. 1. There are 7 topics in package 4 here, beginning on page 43: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> · 2.3 Role of Application Comment (last discussed 25 Feb<https://community.icann.org/display/NGSPP/2020-02-25+New+gTLD+Subsequent+Pr…>) · 2.7.2 Registrant Protections (last discussed 2 Mar<https://community.icann.org/display/NGSPP/2020-03-02+New+gTLD+Subsequent+Pr…>) · 2.7.4 String Similarity Evaluation (last discussed 30 Mar<https://community.icann.org/display/NGSPP/2020-03-30+New+gTLD+Subsequent+Pr…>) · 2.7.5 Internationalized Domain Names (last discussed 28 Apr<https://community.icann.org/display/NGSPP/2020-04-28+New+gTLD+Subsequent+Pr…>) · 2.7.6 Security and Stability (last discussed 28 Apr<https://community.icann.org/display/NGSPP/2020-04-28+New+gTLD+Subsequent+Pr…>) · 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services (last discussed 27 Feb<https://community.icann.org/display/NGSPP/2020-02-27+New+gTLD+Subsequent+Pr…>) · 2.7.8 Name Collisions (last discussed 30 Apr<https://community.icann.org/display/NGSPP/2020-04-30+New+gTLD+Subsequent+Pr…>) 1. Please limit comments to items in the revised sections that you absolutely “cannot live with.” If there is text that you cannot accept, please fill out the attached form and send it to the WG by email. Please do not provide your input in any other format. 1. Deadline for comments is Thursday 4 June at 23:59 UTC 1. Comments will be tracked here: https://community.icann.org/x/JDKJBw. Kind regards, Emily

1 0

ICANN68 GNSO Policy Briefing Available for Download
by Julie Bisland May 28, 2020

May 28, 2020

Dear All, On behalf of the GNSO Team, I am happy to report that the GNSO Policy Briefing for ICANN68 is now available for download at http://go.icann.org/gnsobriefing [go.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__go.icann.org_gnsobriefi…> Thank you. Kind regards, Julie -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Re: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 21 May at 03:00 UTC for 90 Minutes
by Steve Chan May 26, 2020

May 26, 2020

Dear WG Members, One of the action items from the 18 May WG call was to develop a process flow chart to help illustrate how the SPIRT may operate. Attached, please find a draft prepared by staff and WG leadership. Note, we try to share documents at a minimum, 24 hours ahead of the call, but there was a short turnaround between calls in this instance. Hopefully this document is still helpful to the discussions for the upcoming call. Best. Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, May 19, 2020 at 10:46 AM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 21 May at 03:00 UTC for 90 Minutes Dear all, Please find below the proposed agenda for the call on Thursday, 21 May 2020 at 03:00 UTC for 90 minutes. Proposed Agenda: Review Agenda/Updates to Statements of Interest Discussion of Final Report Topics: a. 2.2.2 Predictability: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT…, start at page 10 b. Review "Can't Live With" comments on packages 1-3, time permitting: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org. Kind regards, Julie

4 6

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 28 May at 20:00 UTC for 90 Minutes
by Julie Hedlund May 26, 2020

May 26, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 28 May 2020 at 20:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics: * Review "Can't Live With" comments on packages 1-3: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… * Review Category 1/Verified TLDs in 2.3.2 Registry commitments / Public Interest Commitments: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…, page 139; see also the ICANN46 Beijing Communique’ at: https://gac.icann.org/contentMigrated/icann46-beijing-communique 3. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 26 May 1500 UTC
by Julie Hedlund May 26, 2020

May 26, 2020

Dear Working Group members, Please see below the notes from the meeting on 26 May at 1500 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-05-26+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.2.2 Predictability: Predictability Framework: Categories of Changes to the New gTLD Program after Approval of the Applicant Guidebook ACTION ITEM: Leadership will re-write the section and chart based on the discussion. 2.2.2 Predictability: Predictability Framework: Categories of Changes to the New gTLD Program after Approval of the Applicant Guidebook Possible Policy Level Changes [Changes that May Have a Policy Implication] ACTION ITEM: WG should review the change and indicate whether members agree. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics: a. 2.2.2 Predictability: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT… Predictability Framework: Categories of Changes to the New gTLD Program after Approval of the Applicant Guidebook Possible Policy Level Changes [Changes that May Have a Policy Implication] Discussion: -- SPIRT is not starting a policy development process. -- Looks like they are -- this is a change in terms of how the Council has functioned. -- It would be a change, but more as an advisory role. -- If there’s an issue that may be policy, the standing committee is a tool to allow the Council to operate more efficiently to determine whether something is policy. -- With the wording as it is it seems that the SPIRT would be the first of all advisors. -- GNSO Council can take an issue away from the SPIRT at any time. -- Question: Could it go to the Council first? Then if not policy it goes to the SPIRT? Answer: The problem is that the Council takes a minimum of 60 days on any issue. -- Should circumvent the Council because it takes too long. -- The biggest issue is how you determine which bucket the issue belongs in - A, B, C, D, or E - Council has to have the final say on that. but there is an issue as to how quickly Council could make that determination. -- GNSO Council aside, don't forget that the Board and ICANN Org could also send things to SPIRT. -- We have different understandings of what the SPIRT is supposed to do. It needs to be more than a sorting function. If it decides something is an operational issue it should work with ICANN Org to see if the solution makes sense. -- What if the SPIRT said something is a policy issue but if you did it another way it wouldn’t be policy, when working with ICANN Org? -- What is the check/balance to keep staff from determining something is operational and not sending it to the SPIRT? ACTION ITEM: Leadership will re-write the section and chart based on the discussion. b. Review "Can't Live With" comments on packages 1-3: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… 2.4.2 Communications: First comment re: Affirmation xx: The Working Group affirms Implementation Guideline C and Implementation Guideline M from the 2007 Final Report: * Implementation Guideline C: “ICANN will provide frequent communications with applicants and the public including comment forums which will be used to inform evaluation panels. JC1.1 - Justine Chew proposed adding a footnote. Rationale: "Proposed change does not impact rationale but instead adds necessary clarity by addressing omission of a dependency to the Role of Application Comment section." Staff added a footnote: “Usage to inform evaluation panels is addressed more specifically in section xx Role of Application Comment.” Second comment re: Implementation Guidance xx: Re: “For timeliness, the Working Group believes that for the next subsequent round, the Communications Period should [must] begin at least six (6) months prior to the beginning of the application submission period.” JC1.3 - Justine Chew proposed changing the word "should" to "must" in this sentence. Rationale: "1. Since insufficient awareness of the Program prior to the last round is well acknowledged, this Implementation Guidance ought to prescribe – not merely suggest – a minimum time period for the next round’s Communications Period. 2. Prior WG discussion on the distinction between the terms “must” and “should” and when either ought to be used, applies." Staff changed to [must] in brackets. ACTION ITEM: WG should review the change and indicate whether members agree.

1 0

Post call | New gTLD Subsequent Procedures Working Group call | Tuesday, 26 May 2020 at 15:00 UTC
by Julie Bisland May 26, 2020

May 26, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Tuesday, 26 May 2020 at 15:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/y4PsBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards Julie

1 0

MUST, SHOULD, SHALL etc
by Aikman-Scalese, Anne May 26, 2020

May 26, 2020

Jeff, Cheryl, et al - below I paste the IETF definitions that were linked - note, for example, that "should" says "can be ignored" under certain circumstances - not sure anyone in the WG ever had that understanding of "should". Anne Network Working Group S. Bradner Request for Comments: 2119 Harvard University BCP: 14 March 1997 Category: Best Current Practice Key words for use in RFCs to Indicate Requirement Levels Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Abstract In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119<https://tools.ietf.org/html/rfc2119>. Note that the force of these words is modified by the requirement level of the document in which they are used. 1<https://tools.ietf.org/html/rfc2119#section-1>. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2<https://tools.ietf.org/html/rfc2119#section-2>. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3<https://tools.ietf.org/html/rfc2119#section-3>. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4<https://tools.ietf.org/html/rfc2119#section-4>. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Bradner Best Current Practice [Page 1] ________________________________ <https://tools.ietf.org/html/rfc2119#page-2> RFC 2119<https://tools.ietf.org/html/rfc2119> RFC Key Words March 1997 5<https://tools.ietf.org/html/rfc2119#section-5>. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 6<https://tools.ietf.org/html/rfc2119#section-6>. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. 7<https://tools.ietf.org/html/rfc2119#section-7>. Security Considerations These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification. 8<https://tools.ietf.org/html/rfc2119#section-8>. Acknowledgments The definitions of these terms are an amalgam of definitions taken from a number of RFCs. In addition, suggestions have been incorporated from a number of people including Robert Ullmann, Thomas Narten, Neal McBurnett, and Robert Elz. Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D63340.C252AD10] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> [cid:image003.jpg@01D63340.C252AD10] Because what matters to you, matters to us.(tm) ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. ?2510-2521.

4 4