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

CARLOS JESUS BERNARDOS CANO <> Sun, 08 March 2020 10:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D195F3A092F for <>; Sun, 8 Mar 2020 03:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qXysmjCCL071 for <>; Sun, 8 Mar 2020 03:31:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87E6D3A0926 for <>; Sun, 8 Mar 2020 03:31:09 -0700 (PDT)
Received: by with SMTP id m13so8413655edb.6 for <>; Sun, 08 Mar 2020 03:31:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
In-Reply-To: <>
Date: Sun, 8 Mar 2020 11:30:50 +0100
Message-ID: <>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>
Cc: The IESG <>,, dmm-chairs <>, dmm <>, Dapeng Liu <>
Content-Type: multipart/alternative; boundary="000000000000700da005a05562e0"
Archived-At: <>
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-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Sec 3.2:
>    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.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.