Re: [saag] 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]

 



On Fri, Jul 11, 2014 at 01:46:18PM +0100, ianG wrote:

> In the below, I experiment with the term 'complete protection' rather
> than 'strong security'.
> 
> > The draft makes a stab at calling the alternate 'strong protection' but
> > does not go much further.
> 
>    Abstract.
> 
>    This memo defines the term "opportunistic security".  In contrast to
>    the established approach of delivering complete protection when
>    possible, and none if not possible, ...
>
> [...]

So is "complete protection" as proposed by "iang" a better term
for the historical alternative?  The plausible choices are the
current language "strong security", iang's "complete security", or
perhaps "comprehensive security" (which arguably avoids the maximality
of "complete" or "strong").

None of the above are established terminology, so a related question
is whether whatever term is used requires a brief detour to define
it?  My initial goal was to strive to avoid detours, and focus on
defining opportustinic security.  It was my hope that other terms
are either sufficiently clear from context, or that defining them
precisely is not essential to the task at hand.

Perhaps in this particular case a sentence or two in the introduction
would not be too much of a distraction, but if this does not
significantly aid the clarity of the definition of opportunistic
security at the bottom of section 2, maybe defining legacy practice
is best done in another draft?

More than anything else I want it to be clear that opportunistic
security is not limited to just unauthenticated encryption.  The
last paragraph of section 2 attempts to address that goal.  If that
paragraph is not sufficiently clear, I am open to suggestions of
how to make it more so.

I am inclined to adopt the suggestion of the Gen-ART review to
change "MUST/SHOULD" to "must/should" in the last two paragraphs
of section 2.  If anyone prefers the current language, please
speak up.

-- 
	Viktor.





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