Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id DAE6912D143
 for <tls@ietfa.amsl.com>; Tue, 14 Jun 2016 03:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.348
X-Spam-Level: 
X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01,
 RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id IL93Eeu5ndZ1 for <tls@ietfa.amsl.com>;
 Tue, 14 Jun 2016 03:23:19 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id F369512D097
 for <tls@ietf.org>; Tue, 14 Jun 2016 03:23:18 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id D536C7D0FD;
 Tue, 14 Jun 2016 10:23:16 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com
 [10.34.0.107])
 by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 u5EANFJJ019092
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Tue, 14 Jun 2016 06:23:16 -0400
From: Hubert Kario <hkario@redhat.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Tue, 14 Jun 2016 12:23:05 +0200
Message-ID: <1843800.YErRuY4C85@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.12-200.fc22.x86_64; KDE/4.14.17; x86_64; ;
 )
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz>
 <22902566.AuEvmjhU12@pintsize.usersys.redhat.com>
 <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart5844766.OFXazMUsBD";
 micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.5.110.27]); Tue, 14 Jun 2016 10:23:18 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wLcr5gxmVi4L99KIb2yXlVrKc_M>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Adoption of TLS-LTS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working
 group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>,
 <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>,
 <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2016 10:23:21 -0000

--nextPart5844766.OFXazMUsBD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Monday 13 June 2016 19:51:42 Peter Gutmann wrote:
> Hubert Kario <hkario@redhat.com> writes:
> >to be pedantic, the RFC describes itself "a profile" while in realit=
y
> >it modifies the protocol in a way that will make it incompatible
> >with "vanilla" TLS 1.2 implementations
> >
>=20
> Oh, right.  Well that's easily fixed, I used "profile" because I
> couldn't think of a better term, the best I could come up with is
> "plan", but it's not really a plan either.  If people think "plan" is=

> better than "profile", and it deals with Russ' objection, I'll change=

> it to that.  Alternatively, if you can think of a better term than
> "plan", let me know (or forever hold your peace
> :-).

"TLS refitting for Long Term Support"

"Adaptation of TLS for Long Term Support"

"LTS revision of TLS"

"LTS addendum to TLS 1.2" (amendment?)


If "revision" does not overload the word too much in this context, it's=
=20
the one I would vote for.
=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi=
c
--nextPart5844766.OFXazMUsBD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJXX9sJAAoJEJKo0bgB0vX1kMMP/3Kd2n7j8fAJyX2WqTojtT9g
18jyTdbMSUUwpQ6h9L4tQt9oF5Ge5zOPlEkvnt0R7p6D4qA9zEo0jniAS3VzEiMh
RMdzIJ51bALKIGh257GaYQZYt/y7y4bM0GnmRpOvL2zYZ8nvh75Y1OCDAm20dnHg
FEijLOqqY1/xiWbr2BTJi4zr97ukRD6DKsc7ia+K2wgcVVv8GMp/VQhDhDro52sz
fxavGer+Ltn9zCiA0iF7KXcBOFkEQew6WLP8OOYMNuTPMxPExYBrLXbmXZ84RHZA
B53bWp8O+Gkch8/J70Kq0s+kT8tL8COYUkDYglZvzUwz6B2FQJ3HgcrOqYqP312U
knXjUbZz1GGyUTJTTZfkVKVIDIBN9EeaQ5cpj+7f+coSLM88R/ROpmh5TZyIBAJi
alxqgIo76APdDXFg4e2xJaFI7kZXVGcCtNZdB3l+7RuoNXZJgKubmlbhZasbhyeP
X8qTBjrDMMQ3x85LmsQUrjJjWQSS2vdJHEA23B6UR1fniTYl7w41zkDDtb7gfbfi
eY17O/5HRhr/TRqFDoW3cCdhIBJXazwaY32XTUarjvpp8GMLauf9u4gK41E3von1
uKGTWYPXotcFPBZ49W3ORPhVlrzpC4uUUt61KepYSoHxVqZ+KtMfMnSWi3Bzq5if
mE/7TTv8i2UDIqVr9Oti
=HfTq
-----END PGP SIGNATURE-----

--nextPart5844766.OFXazMUsBD--

