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

CARLOS JESUS BERNARDOS CANO <> Fri, 31 July 2020 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D2EF3A0CAB for <>; Fri, 31 Jul 2020 11:42:36 -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 35_j5w8s-103 for <>; Fri, 31 Jul 2020 11:42:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CC7C3A0B8D for <>; Fri, 31 Jul 2020 11:42:33 -0700 (PDT)
Received: by with SMTP id g19so20544169ioh.8 for <>; Fri, 31 Jul 2020 11:42:33 -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=Xr2/0c54SLmDEN01LdSFZKYMsPC9vefTZkYdRjN/QNw=; b=BtEHc8MDWK0jq4u1Xw7BZs9RJfPojmLlO8O8IuyB+tjywrQCMgcnr3bENnlOOOEQcA TvZI9N1FrGdGaFnLl39cLADlZ359aEPtutA4o94Q9m1Cyp/rXyldVCjQvaF9AfA6dqlP lOnAoqs0N05ULyggw3uYLeGwbrqBSvnhroIEmTP6qmM6/zbjWKZodeqwI0levaZd6L8j 9uvnrWOQEgvfILogRuJCIMbuFoxnsU6OgLROpKO6l4SPRbT2D7LX7/DH+0v/uHHP02KX zGeZ0Qyg+J9VSSCGSJ89UJF0cf96AcP8KsQQqYwxFjzU7ALfGLBsJKcMDde+WvYj6Cza mZFA==
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=Xr2/0c54SLmDEN01LdSFZKYMsPC9vefTZkYdRjN/QNw=; b=ipUk9PCY+XkjEd0iciND77YZsS2mpdybYT5t4yLPSgLiUyhyf8ZcelAX/1PS521M23 jp9FoAHcQqMA0JwHaxI52Uvgeqr+h/cn+TPYF2uAu9jA8Xf8NCcz5QZe0I6ylup+Y/HB 0UWN2J57TcgyhesErhY4a4qju4502KZwxhZ0oZT2ptcSi8jf5oo8g0A5DrD+drsruEIq 37tFR5tN2nVmwGe/KNBH/bFVal421vWPlkJWBqJ/e8m8l/91I3bPagn9D4FwL0V9ltBE UqpOyOIsuIcjbgc+oQfK5igOppgRJhyCCsunYzSCxG4j3DJUqA8YaagF3hIsguukd4kF NyWw==
X-Gm-Message-State: AOAM531xhu3n+QbpQMIcT0HxGmh8tQSB9XeAhVhaBC4L5jJKft/hr2h9 CmBn5z/sJzcwtG+PE9lkB0/EHKeGvVy3nxof+VpfOlZI713Dtg==
X-Google-Smtp-Source: ABdhPJxfnswHWcLlDg9Uhzm+v/wS7Y7hZyQp1UMV6SbHvlBXHPBGEqHEuLqs8uSSNoZHItPKDUIGlZ2+Dj1CTDXe+EY=
X-Received: by 2002:a6b:5c17:: with SMTP id z23mr4877261ioh.67.1596220952963; Fri, 31 Jul 2020 11:42:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Date: Fri, 31 Jul 2020 20:42:16 +0200
Message-ID: <>
To: Tomek Mrugalski <>
Cc: dhcwg <>
Content-Type: multipart/alternative; boundary="000000000000e296de05abc126f0"
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: Fri, 31 Jul 2020 18:42:38 -0000

Hi Tomek,

I've gone through all your comments. I've addressed them all, and I only
have one comment, please see inline below.

Changes are included in -10, to be submitted soon.



On Mon, Jun 8, 2020 at 3:31 PM CARLOS JESUS BERNARDOS CANO <>

> 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.
> Thanks,
> Carlos
> On Mon, Jun 8, 2020 at 3:11 PM Tomek Mrugalski <>
> wrote:
>> 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?
[Carlos] I discussed this with Bernie and he suggested changing MUST to
MAY. The relay can only add up to ONE QUAD option. It may not add any, or
add one.



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