This document has been in last call previously, and one issue in particular caused concern. A design team was created in May 2015 to address this issue, and the document has also otherwise been updated. See further below for a detailed list of changes and history. The sponsoring Area Director believes a new formal last call is needed to ensure that the resulting document matches the community's expectations on this important topic. The sponsoring Area Director also believes that this is a topic where it is important to have an official IETF policy. Policies relating to human behaviour can be difficult topics to deal with, particularly in the all-cases-fully-specified manner that we are accustomed in our technical work. However, policies can be also be updated if later experience proves they have issues. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. - 'IETF Anti-Harassment Procedures' <draft-farrresnickel-harassment-08.txt> as Best Current Practice The file can be obtained via https://datatracker.ietf.org/doc/draft-farrresnickel-harassment/ Changes since the previous last call can be seen via https://tools.ietf.org/rfcdiff?url1=draft-farrresnickel-harassment-05.txt&url2=draft-farrresnickel-harassment-08.txt Adrian Farrel, one of the document editors stated this as a summary of the changes on the IETF list (the email is copied below and originally from http://www.ietf.org/mail-archive/web/ietf/current/msg94129.html): ---- After some very fruitful mail exchanges on and off the list and some detailed discussions face-to-face in Prague, we have produced a new revision of the anti-harassment process document. Some of the changes are quite large. Others are small, but subtle. I recommend reading the whole document, but if you want to look only at changes, I suggest you diff against -05, the version that was updated after IETF last call and went to the IESG for evaluation In checking to see what changes were made and whether they addressed your comments, please bear in mind that there were a lot of comments made in a conversational manner and it was quite hard to round them up and determine exactly what changes needed to be made. Ines did a great job helping as Shepherd, but if we have missed something you said, it is not because we are ignoring you: it's just that we lost the point amongst other comments and discussions. Additionally, I'd ask you to think about whether what we have is "good enough" to act as a starting point. I'm conscious that we have been debating having this piece of process for a long time and that my personal preference is to get something going (a beta release?) and then tune it as we go forwards. In the light of that I know that consensus on some parts of the document may be a little rough. This mainly happens when the opinions on an issue are very divergent and not easily brought together. I hope that we have done a good job at building bridges, but will not be surprised or upset if some of you are not happy. I'm responsible for most of the edits in this round (with assistance from multiple people) so please blame me (and complain about me to Pete) for any nonsense. As to process, I suggest that this document needs to be taken around for another IETF last call, but I leave that to Jari as the responsible AD. Thanks, Adrian ------ In summary... Abstract: clarify the nature of updates to existing RFCs. Introduction: s/interpersonal/personal/ Definitions: Clarify that the definition of harassment is deliberately not a closed list. Definitions: Add a paragraph (loosely based on the IEEE's equivalent policy) to scope when harassment applies within the IETF. Definitions: Add a clause recommended by our lawyers about applicable law. Ombudsteam: Clarify "recompense" to mean "compensation from the IETF". Term of Service: Add paragraph for when an Ombudsperson's term ends while they are acting as Lead Ombudsperson . Term of Service: Add a note about likelihood of reappointment. Compensation: Clarify "recompense" to mean "compensation from the IETF". Removal: Expand the times that an Ombudsperson can be removed. Handling Reports: Fix email address and URL. Handling Reports: Clarify that remedies are imposed only after completing investigations. Operating Practices: Expand on confidentiality expectations. Operating Practices: Clarify that the Respondent is contacted and given an opportunity to interact before a remedy is imposed. Operating Practices: Add when the Ombudsteam must commit things to writing. Remedies: Add that mediation ned not be an end point. Remedies: Show how remedies may be actioned through the Secretariat or IAD. Remedies for Respondents in IETF Positions: Add substantial new section. Purpose of Remedies: Expand on the details and theme of "not as punishment" remedies. Confidentiality: Add new section to describe expectations. Acknowledgements: What a lot of you have helped with this document!
