[multipathtcp] Éric Vyncke's No Objection on draft-ietf-mptcp-rfc6824bis-15: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 16 May 2019 08:15 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: multipathtcp@ietf.org
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83830120075; Thu, 16 May 2019 01:15:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mptcp-rfc6824bis@ietf.org, Philip Eardley <philip.eardley@bt.com>, mptcp-chairs@ietf.org, philip.eardley@bt.com, multipathtcp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <155799454052.19780.6873325590867396631.idtracker@ietfa.amsl.com>
Date: Thu, 16 May 2019 01:15:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/VQRsDQ-1KEaPr0uMhv3EsNSaERA>
Subject: [multipathtcp] Éric Vyncke's No Objection on draft-ietf-mptcp-rfc6824bis-15: (with COMMENT)
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2019 08:15:41 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-mptcp-rfc6824bis-15: 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-mptcp-rfc6824bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work everyone has put into this document and moving from v0 to v1 of MPTCP. The document is also very easy to read even with its length ;-) Congratulations! I am also trusting my SEC AD peers about whether the fixed length of the 160-bnit HMAC/ 32-bit random number fields will still be valid in the future. == COMMENTS == -- section 3.4.1 -- "for example, IPv6 addresses when it has IPv4 only" when talking about what about "an implementation MAY discard incoming address advertisements at will" but what about a device getting IPv6 connectivity after the initial connection? Or the other way round, finally getting an IPv4 address via DHCPv4 'long after' IPv6 SLAAC+ optimistic DAD are executed? I understand that this is a MAY but... -- section 3.4.2 -- An IPv6 address can also become no more preferred as you know, so may I suggest to add this case in addition to 'interface disappears' ? -- section 6 -- While indeed MPTCP can increase the number of false positives in IPS/IDS, I would be more concerned by false negatives (== not detecting a threat) or are we using different meanings for 'false positive' ? Perhaps worth writing in the clear 'not detecting a threat' ? == NITS == --section 3.1-- the bits labelled 'A'to 'H' could have been numbered or labelled with 'meaningful' letters.
- [multipathtcp] Éric Vyncke's No Objection on draf… Éric Vyncke via Datatracker