Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Sun, 08 March 2020 10:31 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D195F3A092F for <dmm@ietfa.amsl.com>; Sun, 8 Mar 2020 03:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 qXysmjCCL071 for <dmm@ietfa.amsl.com>; Sun, 8 Mar 2020 03:31:09 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E6D3A0926 for <dmm@ietf.org>; Sun, 8 Mar 2020 03:31:09 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id m13so8413655edb.6 for <dmm@ietf.org>; Sun, 08 Mar 2020 03:31:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=owhJNtNFF8T1ihwkjZu/C9ORkTJ5XjocLqKJs5Tr83U=; b=kW4ZBnIaXDZ9k2Wn9AUBlNeIMC+lZL7aSQ1RGCnOFLDadiC36Ld4cgal0Jx/hz3jz0 JS1Rm9aJUtL93XapLZMlodZklapB7hXvYqwUJoGJ+v+C/TS8t6qYqAVWPwziWz3dcDvR ET/AAz+PQkggRQjQ3ep4Bf/kauPumHDb+2jICYm5W4+LoijDB+GXFGT+1fRATP9lBDxA iv0EG5YC0h+Yl02NjG6H2ljHO/MsyD8MDo4YQzfQNfMgJr3N075Ieb15mNZ3jXBKrWC+ 85RLwsoyqQN++k8++asMeOrTV3gANToze7PzZjBX/ebAElMzE+SpURnHQHRsDlUlEhvj 7GmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=owhJNtNFF8T1ihwkjZu/C9ORkTJ5XjocLqKJs5Tr83U=; b=F7E7SRZsQDSIeePsppOZCWOqkZRyaOlK77dRP0x927X6ywsXbm4+pI4mjW/0rfresC ZhKAYy/+DIayy2ypdmug1v8lbYAFX4q2XSYtnqqrL8Hn+GyFekZygSR4d9w3Oaahm7iZ 2Y5AsmjqQ+7WfrcdJy3Mmjpcki27JexXp2qcePJAn4HLI5IGB5csrsGExgGCiGmjRuIP kJRioVgJEphf/oE8jbaiwGmCo4zMvF1Y80jxGAotOYxZdpWNHXPDnZ8ZaIlt6cV7VLDv s3CI7y9oxZL9LEK+nef2mojZyS9RQsy9CdsMYhB9Bv1bH0xIPQJ1j2HoyXH2m0p/24au AzEA==
X-Gm-Message-State: ANhLgQ3blCjmrWZsYckUNcf6HRREsfmObNW1sLopKSrliis2dOC6h1DF e8hiJFgrhjCTtFopJlQULnSn9GRcwsCeFj9NIsnOFUPmOi/LfQ==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vv/TpToVizf2bAgMx/wyBo3GCrKQ2FOn7eHDoBC?= =?utf-8?q?7FIx1aKhA46aU7hn8iArN13Lq2J7QOGn6PMbKfW2hJfxEQ8=3D?=
X-Received: by 2002:a17:906:76c6:: with SMTP id q6mr10432689ejn.176.1583663467718; Sun, 08 Mar 2020 03:31:07 -0700 (PDT)
MIME-Version: 1.0
References: <158290959879.22292.8550769571577161380@ietfa.amsl.com>
In-Reply-To: <158290959879.22292.8550769571577161380@ietfa.amsl.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Sun, 8 Mar 2020 11:30:50 +0100
Message-ID: <CALypLp9Y4JP4R6TonK7BGFXgknP_UYiG56kRZB3RXRs+t4EtuQ@mail.gmail.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs <dmm-chairs@ietf.org>, dmm <dmm@ietf.org>, Dapeng Liu <max.ldp@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="000000000000700da005a05562e0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/zrCsY3G-tAzZd_Rl4C9N7pi_1vA>
Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-pmipv6-dlif-05=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Mar 2020 10:31:26 -0000

Hi Mirja,

Thanks a lot for your review. Please see below my comments.

On Fri, Feb 28, 2020 at 6:06 PM Mirja Kühlewind via Datatracker <
noreply@ietf.org> wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-dmm-pmipv6-dlif-05: 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-dmm-pmipv6-dlif/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Sec 3.2:
> "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD
>    be used for configuring the retransmission timer."
> Use of this timeout from RFC6275 is fine. However, you should also indicate
> that the rest of the specified retransmission mechanism should be used as
> well.
> That means exponential backoff as well as a max number of retries. Further
> I
> think it would also be important to overall rate-limit the traffic e.g. as
> specified in RFC6275: "The mobile node MUST NOT send Mobility Header
> messages
>    of a particular type to a particular correspondent node more than
>    MAX_UPDATE_RATE times within a second."
>
> [CB] This is a good point. I've added some text along the lines you
proposed in a new section "3.6.  Retransmissions and Rate Limiting"


> In addition the same mechanisms should probably be also required for any
> (new)
> message sent by the P/S-MAAR in other modes.
>

[CB] The new section 3.6 referred to in my previous comment applies to all
the nodes (CMD or MAAR) sending a message.


>
> Finally in the security consideration section I see this:
> "The CMD SHOULD use a pacing approach to limit
>    this amplification risk."
> Which is good! But why is that a SHOULD and not a MUST?
>

[CB] I was not sure whether to go for a SHOULD or a MUST. I agree with you
it's better to use a MUST there. I've replaced it.


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Editorial comments/nits:
>
> 1)Sec 1: "Following this idea, in our proposal, the central anchor is..."
> Maybe remove "in our proposal" as this is not a proposal only anymore when
> published.
>

[CB] Fixed.


>
> 2) Sec 2:
> "The following terms used in this document are defined in the DMM
>    Deployment Models and Architectural Considerations document
>    [I-D.ietf-dmm-deployment-models]:"
> As there doesn't seem to be any plan to actually publish
> draft-ietf-dmm-deployment-models anymore, maybe move the respective
> definitions
> into this document.
>

[CB] Done.


>
> 3) Sec 3: "Note that a MN MAY move across different MAARs"
> This should be lower case "may".
>

[CB] Done.


>
> 4) As section 3.6 talks mainly about implementation details, I suggest to
> move
> this section into the appendix.
>

[CB] While it's true that it's mainly about implementation details, I
prefer to keep it in the main body, as it explains a mechanism that enables
hiding the change of
 anchors from the mobile node.

>
> 5) In the appendix you always talk about "our solution". This is rather
> uncommon for an RFC. I recommend to chance to e.g. "the solution specified
> in
> this document".
>
> [CB] Right, fixed.


> 6) Are both appendices A and B are still needed?
>

[CB] Here I'm neutral. I think they offered value when the document was
discussed at the WG. But I agree now they can be perfectly removed. I'm
removing them in version -06 (to be submitted soon), but if the IESG
believes it is better to put them back, I can easily do it.


>
> 7) One overall editorial comment which might be too late to address: I
> would
> have found it more easy to read if you would have first introduced the new
> messages and then used the concrete message names in the description in
> section
> 3.
>

[CB] I prefer to keep the document as is. I think it is a matter of
personal preferences, and now it would involve lots of changes.

Thanks again for all your good cooments.

Carlos