Re: [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08


Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EBF03A0861 for <>; Tue, 19 May 2020 07:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DTpP7cuJcvAr for <>; Tue, 19 May 2020 07:33:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63DEE3A085A for <>; Tue, 19 May 2020 07:33:14 -0700 (PDT)
Received: by with SMTP id a14so8244197ilk.2 for <>; Tue, 19 May 2020 07:33:14 -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=Ai/2tmIwItD15yzJRDge/vUFRheUyjSyLM0x4TMrOaQ=; b=NpqWI7IGb8dlHSNzSrLTcOkxVHpZ0ODC6fkYx72HYzdnlYA+Nm48koXzCNLLo0TaU7 Q7zOEJt0UzM4+6ZyqpaMv4aRRGvmkLAlIMLsQfm33ME4/tqXm4rxi+UYnCOFc4eWYsb+ J32ukFxfcqga1oeEzE7jWtUNXnG4MStUkzOsLx3Zpi5IcXPJaTe/qQ0dyzUL77gKlfcr iyw0h7iIV33altOD6V0/+tBDWsudx5L3aQyLUR8GhKNaTz6GUP/zkJoDSeb1lOu2G9dL 3IMTNdEbc9BC5Hga9SfJLcrLeM3VsZIrFrWevFVNp7Yig12tPyJbVv0x73sZ7RPjrPVF 574A==
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=Ai/2tmIwItD15yzJRDge/vUFRheUyjSyLM0x4TMrOaQ=; b=k4rykUBdvvI8ekWyOQvR+4wP92LvBQXBgrQBif9WFkc10XwFV+OB2//DTnOFktKz9k o7Un7lelUYyLnjjyFCgN1I/VZQudLXPt0uBBvcTMQdYQ76thqAAFkKeLZV9LAcK5Ivh/ zw3bKjO1jmGDcH20SG++ZlELgainexsDxccY08Y9F1XJYvsvBFbJ1n0O2YnqzwGZoFji uSfH/7pTqqURQCDN6PG1/OufXqagte3DniyiJVZdC0LL8rvse5ihzECx8HvUj6a+ouWG b8a3iFNZbnLWWlNYJvmHhNMrWPVf11drSGbJlLPA8m0a+lHEXBq7EnFpWXW0ocF5dmRU T4vg==
X-Gm-Message-State: AOAM531DhQED87iWw3DY+EGEHWO6VmFEh+7mYHcBwxqDh9ekKK4fMTCh VDRGYuN9b5AsMfeQgqTPnoet0IHhut3mym1RwU8A/Q==
X-Google-Smtp-Source: ABdhPJzh90CXNJrv0AM+adkWVaD46X1SqSrCnQg1NOsg+P6RT6OuF7+Lxud/x917eTL+mvbPjTIaSVDnZWPi6vyUDJ8=
X-Received: by 2002:a05:6e02:686:: with SMTP id o6mr10788595ils.280.1589898793270; Tue, 19 May 2020 07:33:13 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Date: Tue, 19 May 2020 16:32:57 +0200
Message-ID: <>
To: Tatuya Jinmei <>
Cc: "<>" <>,, dhcwg <>,
Content-Type: multipart/alternative; boundary="000000000000cdab9505a60128d1"
Archived-At: <>
Subject: Re: [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 May 2020 14:33:17 -0000

Thanks a lot for your detailed comments. I'll go through them and provide
our responses in the following days.


On Mon, May 18, 2020 at 10:41 PM Tatuya Jinmei via Datatracker <> wrote:

> Reviewer: Tatuya Jinmei
> Review result: Ready with Issues
> I am an assigned INT directorate reviewer for
> draft-ietf-dhc-slap-quadrant. These comments were written primarily
> for the benefit of the Internet Area Directors. Document editors and
> shepherd(s) should treat these comments just like they would treat
> comments from any other IETF contributors and resolve them along with
> any other Last Call comments that have been received. For more details
> on the INT Directorate, see
> This draft defines a new DHCPv6 option that is supposed to be used
> with draft-ietf-dhc-mac-assign.  The new option makes it possible for
> a client to specify its preferred "type" (SLAP) of MAC addresses to be
> assigned and for the server to make the assignment decision based on
> the preference.
> The draft is generally well written.  I think it's basically ready,
> but there are several points not very clear to me.  I guess these are
> largely editorial glitches or simply due to my lack of understanding of
> the background rather than substantial technical issues.  As a reader
> I'd feel happy if my questions are clarified, but I'd leave these to
> authors.
> Specific comments:
> - Section 4.1-3
>        [...]  The client SHOULD NOT pick a server that does not
>        advertise an address in the requested quadrant.
> Does this mean if a client follows this "SHOULD NOT" and receives
> Advertise messages from servers that don't understand the new QUAD
> option, then the client can't choose any server?  If so, is it okay?
> - Section 4.1:
>    5.  When the assigned addresses are about to expire, the client sends
>        a Renew message.  It includes the preferred SLAP quadrant(s) in
>        the new QUAD IA_LL-option, so in case the server is unable to
>        extend the lifetime on the existing address(es), the preferred
>        quadrants are known for the allocation of any "new" addresses.
> It's not clear to me what 'the preferred quadrants are known for the
> allocation of any "new" addresses' means.  Does this mean the server
> will assign a new address from the specified quadrant(s) in response
> to the Renew in this situation?
> - Section 4.2-3
> The preference between client's supplied QUAD and relay supplied QUAD
> (or whether it matters) isn't clear to me.   What if these are
> inconsistent?  Perhaps this paragraph at the end of Section 4.2
> answers the question?
>    The server SHOULD implement a configuration parameter to deal
>    with the case where the client's DHCP message contains an instance of
>    OPTION_SLAP_QUAD, and the relay adds a second instance in its relay-
>    forward message.  [...]
> If so, it might be more reader friendly if 4.2-3 gives a forward
> reference to this consideration.  Also, this paragraph seems to
> suggest the server may (only) process the relay's instance of the QUAD
> option.  If so, and it's incompatible with the client's option, then I
> guess the same question as Section 4.1-3 applies here.
> - Section 5.1
>    [...]  Note that a quadrant - preference tuple is
>    used in this option (instead of using a list of quadrants ordered by
>    preference) to support the case whereby a client really has no
>    preference between two or three quadrants, leaving the decision to
>    the server.
> What does "a quadrant - preference tuple is used in this option" mean?
> >From the context I guess it tries to talk about using the same
> preference for multiple quadrants, but the actual text doesn't really
> read that way to me...
> - Section 5.1
>    [...]  If the server can provide an assignment from one of the
>    specified quadrants, it SHOULD proceed with the assignment.  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.
> The first and second sentece seem to contradict each other.  If, for
> example, two quadrants Q1 and Q2 are specified and the server can only
> provide an assignment for Q1, what should it do?  The first sentence
> seems to say the server should proceed with the assignemtn for Q1; the
> second sentence seems to say the server MUST NOT assign any address
> and simply return NoQuadAvail.
> BTW, the second sentence also seems to contradict Section 4.1?  4.1-2
> states:
>        [...] If
>        the client specified more than one SLAP quadrant, the server MUST
>        only return a NoQuadAvail status code if no address pool(s)
>        configured at the server match any of the specified SLAP
>        quadrants.
> Nits
> Section 2: s/in in/in/
>    relay         A node that acts as an intermediary to deliver DHCP
> [...]
>                  functionality as described in in [RFC8415].
> Section 2: s/it can be/if it can be/ ?
>       quadrant might be different.  For example, it can be managed, this