Re: [dane] [saag] Need better opportunistic terminology

Stephen Farrell <> Tue, 11 March 2014 22:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D111C1A0851; Tue, 11 Mar 2014 15:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rhgV4EP3-a0W; Tue, 11 Mar 2014 15:14:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D832D1A0843; Tue, 11 Mar 2014 15:13:58 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 447F2BE4D; Tue, 11 Mar 2014 22:13:51 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eTuJkgCtOkcp; Tue, 11 Mar 2014 22:13:50 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 35616BE3F; Tue, 11 Mar 2014 22:13:50 +0000 (GMT)
Message-ID: <>
Date: Tue, 11 Mar 2014 22:13:49 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stephen Kent <>,
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 12 Mar 2014 05:46:19 -0700
Subject: Re: [dane] [saag] Need better opportunistic terminology
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Mar 2014 22:14:05 -0000


(Bcc'ing dane and saag for reasons that'll become obvious:-)

On 03/11/2014 09:53 PM, Stephen Kent wrote:
> I prefer that we stick with that definition of the term,
> which is IPsec-specific. 

I don't think we need to face any such constraint at all.
We might choose to, but there's no reason our definitions
need to honor previous ones since any use of the OE term
will conflict with someone's understanding. I also don't
want us to end up with IPsec (or TLS) specific terminology.

> I have suggested "opportunistic keying" as a
> preferred term, since
> its the key management, not the encryption per se, that distinguishes
> other proposed modes of
> operation for IPsec, TLS, etc. The breakout group at the STRINT workshop
> that discussed terminology
> suggested using the term noted above.

I agree the OK term is better for the reasons you state.
(And Pete Resnick likes the idea of OK protocols:-)

If/when we re-do the MPLS thing we'll move to use that
and I think it'll be useful if other folks do too.

And speaking of terminology, I canvassed a few folks last
week and there was reasonable support for doing the draft
that defines these terms within the UTA WG. So I'd suggest
we move the discussion there if that's ok just to try get
it in one place.