I have reviewed the document " Opportunistic Security: some protection most of the time" (draft-dukhovni-opportunistic-security-01) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Intended status: Informational Current draft status: In Last Call Summary: This memo defines the term "opportunistic security". In contrast to the established approach of delivering strong protection some of the time, opportunistic security strives to deliver at least some protection most of the time. The primary goal is therefore broad interoperability, with security policy tailored to the capabilities of peer systems. NITS: ** The document seems to lack an IANA Considerations section. (See Section 2.2 of http://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Minor Comments: Please reorder sections as follows: 1. Introduction 2. Terminology 3. Opportunistic Security Design Philosophy If you do this, all of the terms and acronyms used in "Opportunistic Security Design Philosophy" will be defined before they are used. Major Comments: The abstract claims that, "This memo defines the term "opportunistic security". However, I don't see a concise definition of the term "Opportunistic Security" in the document. One way to fix this problem would be to rename the section that is currently called "Opportunistic Security Design Philosophy" to "Definition of Opportunistic Security". Then, you can say that a system executes opportunistic security procedures if it complies with all of the requirements enumerated in the bullet points below. Currently, some of the bullet points use RFC 2119 language while others don't. Since they enumerate requirements, they should probably all use RFC 2119 language. Ron Ron Bonica