Use of "expectations" in RSSAC001v2
This idea is meant to start a discussion of what we "expect" of RSOs. I thought that, if we can deal with this first, it will make the rest of the work on RSAAC001v2 easier to understand. In the current RSS, there is no way for an administrative body to remove an RSO for not performing the tasks in RSAAC001v1. RSSAC001v2 should not (cannot!) change that. So, starting with that understanding, I propose the following. - At the beginning of Section 3, before Section 3.1, we add something like: In this document, the word "expectation" indicates a task that each RSO is generally expected to perform if it is possible for them to do so. There may be reasons than a particular RSO cannot perform a particular expectation; in that case, the RSO is expected to state those reasons. - In the rest of Section 3, we carefully make sure each section is written with the word "expectation" instead of anything stronger or weaker. - Remove Section 5, since these are not recommendations to the ICANN Board (which is the normal use of such sections in RSSAC and SSAC documents). --Paul Hoffman
- At the beginning of Section 3, before Section 3.1, we add something like:
In this document, the word "expectation" indicates a task that each RSO is generally expected to perform if it is possible for them to do so. There may be reasons than a particular RSO cannot perform a particular expectation; in that case, the RSO is expected to state those reasons.
Looks good; I might say s/state/document/ - In the rest of Section 3, we carefully make sure each section is written
with the word "expectation" instead of anything stronger or weaker.
Also good and wise.
- Remove Section 5, since these are not recommendations to the ICANN Board (which is the normal use of such sections in RSSAC and SSAC documents).
I suspect we should talk about that. RSSAC does publish documents that are not always advice for the board to act on, as does SSAC I think. But your point is valid that we need to be careful about how we word things to be clear about who the audience is. Cheers, -- Wes Hardaker USC/ISI
On Sep 7, 2022, at 10:27 AM, Wes Hardaker <hardaker@isi.edu> wrote:
- At the beginning of Section 3, before Section 3.1, we add something like:
In this document, the word "expectation" indicates a task that each RSO is generally expected to perform if it is possible for them to do so. There may be reasons than a particular RSO cannot perform a particular expectation; in that case, the RSO is expected to state those reasons.
Looks good; I might say s/state/document/
Yes, that's a better word.
- In the rest of Section 3, we carefully make sure each section is written with the word "expectation" instead of anything stronger or weaker.
Also good and wise.
- Remove Section 5, since these are not recommendations to the ICANN Board (which is the normal use of such sections in RSSAC and SSAC documents).
I suspect we should talk about that. RSSAC does publish documents that are not always advice for the board to act on, as does SSAC I think. But your point is valid that we need to be careful about how we word things to be clear about who the audience is.
A section called "Recommendation" should recommend something, and if we are stating expectations, there is nothing to recommend beyond the expectations. Of course, if we want to do the typical thing of recommending something to the ICANN Board with respect to the expectations, that's fine, and we can just re-write the recommendations in the section. --Paul Hoffman
A section called "Recommendation" should recommend something, and if we are stating expectations, there is nothing to recommend beyond the expectations. Of course, if we want to do the typical thing of recommending something to the ICANN Board with respect to the expectations, that's fine, and we can just re-write the recommendations in the section.
The section currently does have recommendations. Just not to the board.
On Wed, Sep 7, 2022 at 12:58 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
This idea is meant to start a discussion of what we "expect" of RSOs. I thought that, if we can deal with this first, it will make the rest of the work on RSAAC001v2 easier to understand.
In the current RSS, there is no way for an administrative body to remove an RSO for not performing the tasks in RSAAC001v1. RSSAC001v2 should not (cannot!) change that. So, starting with that understanding, I propose the following.
- At the beginning of Section 3, before Section 3.1, we add something like:
In this document, the word "expectation" indicates a task that each RSO is generally expected to perform if it is possible for them to do so. There may be reasons than a particular RSO cannot perform a particular expectation; in that case, the RSO is expected to state those reasons.
"...in that case, the RSO is expected to state those reasons." It seems like this is a recursive expectation. If we can't state the reasons then what is expected of us? I think we should choose a different word. "in that case, the RSSAC requests that the RSO document those reasons". I think that has similar pitfalls but at least gets away from the term reuse. s/reasons than/reasons that/ - In the rest of Section 3, we carefully make sure each section is written
with the word "expectation" instead of anything stronger or weaker.
Agree with this, just not in the same sentence as defining the word. - Remove Section 5, since these are not recommendations to the ICANN Board
(which is the normal use of such sections in RSSAC and SSAC documents).
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (3)
-
Paul Hoffman -
Peter DeVries -
Wes Hardaker