<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- At the beginning of Section 3, before Section 3.1, we add something like:<br>
<br>
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.<br></blockquote><div><br></div><div>Looks good; I might say s/state/document/</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- In the rest of Section 3, we carefully make sure each section is written with the word "expectation" instead of anything stronger or weaker.<br></blockquote><div><br></div><div>Also good and wise.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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).<br></blockquote><div><br></div><div>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.<br></div><div><div dir="ltr"><br clear="all"><div>Cheers,</div>-- <br><div dir="ltr"><div dir="ltr">Wes Hardaker<div>USC/ISI</div></div></div></div></div></div></div>