I also got the impression that "spec" was also being used in the same sense as SA, i.e., protocol/algorithm + configuration parameters.
Regardless, though, the point seems clear - reuse the style of terms from other security docs ... Joe On 7/5/2016 12:18 PM, Black, David wrote: > We're in semi-violent agreement on protocol vs. protocol specification. > >> I would suggest using different terms as needed in different places, and >> copying the terms from IPsec where relevant here. > The analogous IPsec term would be "protocol" for things like tcpcrypt and > the TLS profile, with "protocol specification" as a natural term for a > document. > As the draft currently stands, the result would be "encryption protocol" and > "encryption protocol specification" both of which could be prefixed by TCP > for precision. > > If needed, the IKEv2 term "transform" could be used to refer to elements > of a TCP encryption protocol. > > Thanks, --David > >> -----Original Message----- >> From: Joe Touch [mailto:[email protected]] >> Sent: Tuesday, July 05, 2016 2:21 PM >> To: Black, David; tcpinc >> Subject: Re: [tcpinc] What to use instead of "spec" >> >> >> >> On 7/5/2016 10:52 AM, Black, David wrote: >>> Like Kyle, I'm also uncomfortable with the use of the word "spec." >>> >>> How about "mechanism" instead? That enables separation between >>> - Encryption mechanism (what is done to produce the bits "on the wire") >>> - Specification of an encryption mechanism or encryption mechanism >>> spec[ification] (what's in the doc) >>> >>> The latter specifications are actually protocol specifications (e.g., they >>> include >>> key exchange in addition to encryption). >> FWIW,: >> >> 1) protocols are more than just what's "on the wire" >> They are the sum of the state machine on each end, the interfaces to >> layers above and below, and the messages (on the wire). >> >> 2) a specification is a *description* of a protocol, algorithm, or mechanism >> It is distinct from the concept thereof and the implementations thereof. >> We tend to refer directly to the protocol/algorithm/mechanism >> (unless we're updating a spec thereof). >> >> 3) I agree the doc uses "spec" to mean too many things: >> - TCP option variant >> - security transform (from IPsec, i.e., algorithm) >> - security association (from IPsec, i.e., transform and its >> configuration parameters for a given TCP connection) >> >> I would suggest using different terms as needed in different places, and >> copying the terms from IPsec where relevant here. >> >> Joe >> >> _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
