[multipathtcp] Alissa Cooper's Discuss on draft-ietf-mptcp-rfc6824bis-15: (with DISCUSS and COMMENT)
Alissa Cooper via Datatracker <noreply@ietf.org> Mon, 13 May 2019 20:22 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 9C09612004A; Mon, 13 May 2019 13:22:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper 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: Alissa Cooper <alissa@cooperw.in>
Message-ID: <155777895763.23745.13998665596170215423.idtracker@ietfa.amsl.com>
Date: Mon, 13 May 2019 13:22:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/3wxz6UvrNGxF6BGtG_z4e3YfmEs>
Subject: [multipathtcp] Alissa Cooper's Discuss on draft-ietf-mptcp-rfc6824bis-15: (with DISCUSS and 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: Mon, 13 May 2019 20:22:38 -0000
Alissa Cooper has entered the following ballot position for draft-ietf-mptcp-rfc6824bis-15: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a question about the interaction between the protocol versioning and the way the flags B-H are defined. This doc specifies that B MUST be set to 0 and that future specs might require it to be set to 1, which could alter the meanings of the C-H flags. This is the same way that B is defined in RFC 6824. This spec goes on to define C and H differently from how they are defined in RFC 6824. Thus, both v0 and v1 implementations will have B set to 0, but they will have C and H defined differently. I guess it depends on how you interpret "extensibility flag," but my interpretation of this is that the version number negotiated using MP_CAPABLE is the actual extensibility mechanism that this specification is making use of, because although it changed C and H it did not change B. Is this right? If so, I'm wondering what the threshold is for defining new versions of this protocol versus using this extensibility mechanism based on the B flag. Given the way the version negotiation mechanism is defined -- requiring extra round-trips in the event of a fallback attempt, and it being subject to a downgrade attack -- I'm wondering if some guidance needs to be provided about which sorts of protocol changes are expected to be made using the B-flag mechanism versus using the version negotiation mechanism. I guess the drawback of using the B-flag mechanism is that once a future spec sets it to 1, from then on logic within implementations will be required to interpret potentially multiple different semantics of C-H. I guess this potentially raises another question, which is why the B flag isn't just deprecated given the addition of the version negotiation mechanism. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.7: s/the lost of MPTCP options/the loss of MPTCP options/ Appendix E should be titled "Changes from RFC 6824"
- [multipathtcp] Alissa Cooper's Discuss on draft-i… Alissa Cooper via Datatracker
- Re: [multipathtcp] Alissa Cooper's Discuss on dra… Alan Ford
- Re: [multipathtcp] Alissa Cooper's Discuss on dra… Alissa Cooper
- Re: [multipathtcp] Alissa Cooper's Discuss on dra… Alan Ford