Re: Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear IESG,

I have a question and several comments (with proposed edit) for your and the author's consideration.

First, and most abstractly, this document defines opportunistic security solely in terms of encryption.  Indeed Section 2 states:
   In summary, opportunistic security is an umbrella term that
   encompasses protocol designs that remove barriers to the widespread
   use of encryption in the Internet.
My question: are there other forms of opportunistic security that this definition would foreclose?  For example, might taking advantage of physical presence also be a form of opportunistic security?

Second, the abstract doesn't match the document.  The abstract states that "This memo defines the term "opportunistic security".  It goes much further than defining that term.  Rather it specifies requirements for and characteristics of opportunistic security, complete with normative language.  My suggestion would be to restate the abstract as follows:

OLD:

   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.


NEW:
   This memo defines the term "opportunistic security" and its attributes,
   and specifies requirements for implementing it in IETF protocols.  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.

If people think the word "requirements" is too strong, then perhaps "guidance".  Given the use of normative language, you may also wish to consider making this document a BCP and reviewing it in that light.

Finally, an editorial nit: I suggest that the 2119 boiler plate be moved up to prior to first use of 2119 normative language (like bottom of Section 1).

Eliot

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]