Re: [dhcwg] A late review of draft-ietf-dhc-slap-quadrant-09

CARLOS JESUS BERNARDOS CANO <> Mon, 08 June 2020 13:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 752DC3A07DC for <>; Mon, 8 Jun 2020 06:31:32 -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 nlBVbXHlKzRx for <>; Mon, 8 Jun 2020 06:31:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0ACEF3A07DB for <>; Mon, 8 Jun 2020 06:31:29 -0700 (PDT)
Received: by with SMTP id d5so18594582ios.9 for <>; Mon, 08 Jun 2020 06:31:29 -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=c0qMYxyXEsYJBwI7825GlsRWJAqRapo42419d16FY+s=; b=Nlh/r+Q6BpezlrsZ54F2x9a+6wasOFczhU1vc7sIXAmfPAVnCmfBkcHlO/dL/NZcGv RWeNy1wjaGFhIjR+A0+q2uOHwRaCxcXFnqWmAYMFzuXlNHOyTADvfK0JV5aC42d9COJv eXza/3LIVkx1HLD8+WTpMxKaRfSd8mIfks0MCtLLNEfmf3TOOr0mS9mrlo/a2G6cqDoz zQDKx+6MYy+PLhSOp+w0rx9xg/5VY19EkMQKH12aWlrDbDdnycxpTxCeVK0HxmC7iEu1 Rgqw/eKh7VcBmeFROeGpuU6+NLavklztxLvBmXLuhQR3cisGokmirOuk7LN/putKkSct 0lwQ==
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=c0qMYxyXEsYJBwI7825GlsRWJAqRapo42419d16FY+s=; b=AK6sLkWNGaeByGX/AH0hR6Z+nOp/Mm/nOpZcL7TrT8yK8LqAQHMnL0eKzGhoY9asc1 IKiRMF1tMMPR6FKU85mW9tEx8k5idPGHq+XgaD94Sc4PNNt7HM0irDRAubxpG0xiplyc VaHev1wZSYKFvxrgrM1CeIQ1WtzkNlSSWKcKTawBXVGBnqTwS+ALrC4niZMUfGy2HiJC jbvw3+FubSJ6pzVcx93U5dyKw57M7nMeUZOkGgCIdZUq3DayEX8Vc0Q8RkRKEamfh6ww i0CfEbp4zl7l/Y9gOXSliiw9AypVzc3/Khpy7+FqZ9CIr1mhn+XpxcfAO4luE59uF0n1 P4aw==
X-Gm-Message-State: AOAM533WGNn7++sBey5iLV1W2kU6Wz+i+AXJYrFST489NJ1jkNTeuXSS /kokDn4Dv78k0NgwIBA/MLC84PzReFKfZyOg3+Qlzw==
X-Google-Smtp-Source: ABdhPJw6S3tzt9QO3iN39yqVUv/K/AgPHVSjX/EMVxvhwjMEzvk0c3rM7AzJmqleZFTDQvwU4HDaorVyf6eSxF11/NQ=
X-Received: by 2002:a02:810:: with SMTP id 16mr22346910jac.17.1591623088879; Mon, 08 Jun 2020 06:31:28 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Date: Mon, 8 Jun 2020 15:31:12 +0200
Message-ID: <>
To: Tomek Mrugalski <>
Cc: dhcwg <>
Content-Type: multipart/alternative; boundary="000000000000d45e4105a792a0be"
Archived-At: <>
Subject: Re: [dhcwg] A late review of draft-ietf-dhc-slap-quadrant-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jun 2020 13:31:33 -0000

Hi Tomek,

Thanks for your review. I quickly went through your comments and I think I
mostly agree, but I'll come back to you with my responses to each of your
comments in the following days.



On Mon, Jun 8, 2020 at 3:11 PM Tomek Mrugalski <>

> Hi,
> I was requested by IANA to do an expert review of dhc-slap-quadrant-09.
> I did as requested and in the process I have reviewed the whole draft.
> It's a bit late for editorial changes, but I was not able to dedicate
> any time sooner. Sorry for that.
> The proposed changes are mostly editorial in nature, except the one
> about what the client should do if receives an address from different
> quadrant than requested.
> Abstract: "A new DHCPv6 option (OPTION_SLAP_QUAD, or QUAD)". Please pick
> one name that you want to use for the option and stick with it. Using
> alternate names is confusing. I'd prefer to not mention
> OPTION_SLAP_QUAD, because that the constant representing a specific
> value. The abstract should convey general idea, not the implementation
> details.
> Section 4.1, bullet 2: "The server, upon receiving an IA_LL option,
> inspects its contents. [...] If suitable addresses are found, the server
> sends back an Advertise message". This is imprecise. It can easily be
> misunderstood as "if there's IA_LL option, always send Advertise,
> regardless of if the client sent Solicit, Request or Renew.
> This must be rephrased. I suggest something like "The server, upon
> receiving an IA_LL option in Solicit, inspects its contents.".
> Section 4.1, bullet 5: "When the assigned addresses are about to expire,
> the client sends a Renew message." This is usually not true. The client
> sends Renew after T1, which usually (as recommended by RFC8415) is set
> to 50% of a valid lifetime.
> Section 4.1, bullet 6: " 6.  The server responds with a Reply message,
> including an LLADDR option with extended lifetime." This can easily be
> misinterpreted as "the server sends LLADD as a top-level option in
> Reply". This is not true. The LLADDR option is always supposed to be
> sent in IA_LL.
> "The client SHOULD check if the received MAC address comes from one of
> the requested quadrants.  Otherwise, the client SHOULD NOT configure
> the obtained address." What if the relay inserted a different an option
> asking for a different quadrant and the server's policy used that?
> Client following the text as written would drop the option and will not
> used the LL address assigned. So how exactly the server policy would
> work if anything the client didn't request would be dropped? The policy
> could only possible rearrange order of quadrants that the client said is
> willing to accept.
> I don't particularly like that. There are many mechanisms in DHCPv6
> where the client sends some options as hints or suggestions, but it's
> not really a negotiation. The server knows best. Would you be willing to
> change that, so the client always accepts what the server had said?
> If you want the client to pick a different server, you can do so when
> evaluating received Advertises. The text as written allows the client
> to change his mind when Reply is received.
> Section 4.2, bullet 2: "if a client sends multiple instances of the
> IA_LL option in the same message, the DHCP relay MUST only add a single
> instance of the QUAD option." What if the relay supports this draft,
> but isn't configured to insert specific value?
> Section 4.2, bullet 9: The same issue as 4.1, bullet 5 (sends renew
> when address about to expire).
> Section 5.1 "If the server cannot provide an assignment from one of the
> specified quadrant-n fields, it MUST NOT assign any addresses and return
> a status of NoQuadAvail (IANA-2) in the IA_LL Option." from one => from
> any.
> I support the draft moving forward and I'll pass a note to IANA about my
> positive expert review for the option format.
> Tomek
> _______________________________________________
> dhcwg mailing list