[TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)

Martin Vigoureux <martin.vigoureux@nokia.com> Thu, 05 April 2018 09:31 UTC

Return-Path: <martin.vigoureux@nokia.com>
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B396D126579; Thu, 5 Apr 2018 02:31:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Vigoureux <martin.vigoureux@nokia.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-record-limit@ietf.org, Sean Turner <sean@sn3rd.com>, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.77.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152292067172.25904.6713770378882293720.idtracker@ietfa.amsl.com>
Date: Thu, 05 Apr 2018 02:31:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vZKXgubp27czk7h6OsXvx1lIQfE>
Subject: [TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 05 Apr 2018 09:31:12 -0000

Martin Vigoureux has entered the following ballot position for
draft-ietf-tls-record-limit-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hello, I'm not a TLS expert so please disregard if this is irrelevant.
Document says:
   Clients that depend on having a small record size MAY continue to
   advertise the "max_fragment_length".

Do you mean:
   Clients that depend on having a small record size MAY continue to
   advertise the "max_fragment_length" *only*.

If so, what would be the behaviour of a server that supports both
"max_fragment_length" and "record_size_limit" in that situation?