Re: [multipathtcp] 6824bis-11 review

Xavier de Foy <> Wed, 19 September 2018 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D24AC131065 for <>; Wed, 19 Sep 2018 09:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xPilCah24Kxi for <>; Wed, 19 Sep 2018 09:38:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA274131031 for <>; Wed, 19 Sep 2018 09:38:24 -0700 (PDT)
Received: by with SMTP id u83-v6so5646642lje.12 for <>; Wed, 19 Sep 2018 09:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+RVZKpF8mN5POgKS2fAXpFPHM6JAXT9AgbDAQD/22Po=; b=BSw6VqyFc4MJCiKjH836RsM4Hbv56OhYyrN3tRXtECNvDRKbRMFbW94PJoSjYIC6pj 3OlUgY1X4XZ+TBVZrLTHMZs7T+VsjeTZdUDBJRJDgP47VIVKFceZcF4byjuC4PUCUTft s6S4GL5hiN/UG+pfD+/cOqs+ASSfJbI6PikUX2P6nM9tFO2jka3n4IL0X6H2W2gnNF+3 UF2Djoqk0euvOl2t1dJfXl9PtPivbSiDj/n8hlYnrdA+uBJJPazNA/ezD6lNOIaz0+Fo cHwbBUwysvkekpe9G+jQF5ytIakC270NlZMhO3gZ5w4v63lliR/wCGaAW3l8RF51PRvk npPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+RVZKpF8mN5POgKS2fAXpFPHM6JAXT9AgbDAQD/22Po=; b=b00kGS1Hn5jJl0UcLunLip604ToS5fKxPy8IL9G0LjKrU57i+Z7QObx+eRl4tgpfun bC9wWNsCCDE02CMi3SLYdk6GE/BjRg/6RQvu/dZozIaTaktrSwNwJfZrhJFmq830v9SW Lhnf31fyduLBalPdCui/oqlQ6r/l8PY4PNJBcqo9Ww7dhRBtO2BdI9sQtQslmJWTw7qf YyCwxMnhaIGXKxI+hl+9hEaH8dcqFM5p9pIJ2Z7noe84/oywyIEDFLbKs3TTksmLQCsJ J90m5OID2ZomhufF42/3igztGdabNgJImow2490K7sXFAiWj4aKQPbi6S6rjcv+rw1Oj wGcQ==
X-Gm-Message-State: APzg51CSYMYfSM5tsH/FbkfOUhWSCIMw4m6ek6ZbIjzLdIfsdP6+ORO8 nGGrtomhXzSu5pz8pffo4A5Bf3r7AH0isw8Gi7c=
X-Google-Smtp-Source: ANB0Vda8f8J5DHHB9L4gJhQnmGRTD8VV5shsEHPA4j88kNZqebUWi6yRH4d/Kxm5hFULZCtjBG/xHze6Jxov6HmTwpI=
X-Received: by 2002:a2e:9a93:: with SMTP id p19-v6mr19579455lji.108.1537375102826; Wed, 19 Sep 2018 09:38:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Xavier de Foy <>
Date: Wed, 19 Sep 2018 12:38:09 -0400
Message-ID: <>
Cc: multipathtcp <>
Content-Type: multipart/alternative; boundary="000000000000e3fd9305763c08a5"
Archived-At: <>
Subject: Re: [multipathtcp] 6824bis-11 review
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Sep 2018 16:38:34 -0000

Thanks Alan for addressing the comments, and for the additional details you
provided. I agree with your responses, with just one possible clarification
below, and an answer to your question. There is no open issue with this
review, from my standpoint (the following points are minor).

>"The Address ID MUST uniquely identify the address for the sender of the
option (within the scope of the >connection), but the mechanism for
allocating such IDs is implementation specific."

Even after this rephrasing I still wonder if address ID #1 can designate an
IP address local to peer A, and the same ID #1 can (in the same session)
designate another IP address local to peer B. Would you find the following
phrasing clearer?

"The Address ID MUST uniquely identify the address within the scope of the
connection (uniqueness is only required among the IP addresses local to the
sender of the option), but the mechanism for allocating such IDs is
implementation specific."

>> *3.8. Error Handling
>> - Is the list of errors complete? (e.g. ADD_ADDR errors seem to belong
to the same class as remove request)
>What kind of ADD_ADDR error are you thinking of?

For example: adding an address with an invalid HMAC, or invalid values in
some fields. Also (based on your recent edits) existing address ID but a
different IP address. More generally, the goal of my comment was just to
bring your attention on the fact that not all classes of errors may be
covered. But it's possible that the authors only wanted to cover high level
error handling strategies. So it's really an editorial choice, please feel
free to address this comment as you see fit, there is no need to follow-up
on this.

Best Regards,