Re: [dhcwg] Robert Wilton's Discuss on draft-ietf-dhc-slap-quadrant-09: (with DISCUSS and COMMENT)

CARLOS JESUS BERNARDOS CANO <> Fri, 31 July 2020 09:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7964F3A0FFA for <>; Fri, 31 Jul 2020 02:49:19 -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 fTosARYf6E41 for <>; Fri, 31 Jul 2020 02:49:17 -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 0D4483A11CD for <>; Fri, 31 Jul 2020 02:49:16 -0700 (PDT)
Received: by with SMTP id j8so18737504ioe.9 for <>; Fri, 31 Jul 2020 02:49:16 -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=eQyVWBD3sm3dV/y3BIavbonFRBGn2EtieFLur435gwE=; b=dGbgJkHBpVCyB8WjoyWYPwy9AA2wdvTyDq3GLS5OfTqgEHEUYniEt4NOu4/LIg0D+w /hDMDlclgaDA+4kgeiRn04pCLSG2ZTKamaWez4rTqm3YWxLHxs/LsFQGeYemxM5CIM/w uti0j1bltb+5vz+bRCX/LP1E4LF9eP4N3J1iMn29qtueu/6+ifIBd4MPeo0qLhIbI0a3 NDByybpD+9XEjoI3WJRrQd0uhrgr6ebJwE3qNIOdtz+2Eg9j5ajwOj/SKmceMuITWuTr W4je8NMyjRqdjicuSPZrBiqxtFHArYvwDzIYwXtgH3ToegZeJX2mYVfazzQ4lyQNN2OF AQBw==
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=eQyVWBD3sm3dV/y3BIavbonFRBGn2EtieFLur435gwE=; b=tXQIZsvo3fSniC4lzoD7AYS3AkIUm3hnpWAstkuXHK0pc4N0k281MvdWjbLyJAKMsF +arY6fZWjad2crswQyQ5v3t0fnelkEin2cCKFGKdbsjfEoajj4M6nmv5N5Zu4lu8gVo3 RJ3fFroZe1t9CfSU60tlLiIV9PWahJPmLjpsNxzJD0ipeTpng2UCGqXDFcZ/zKpbf1pz qYghzXGJjnHpCqCRlAf9bc2K2EhINMbpOMY/SV7AZmOIRDZUVo/Ypg+VtLXpV6Gtw69a KbNDBwqV4WtPbTcOTSG8OtS2ZTOCEpTlqDcpoOXc6n6Pz1mHaggLeh1sOZociVFZxJ/z OY3Q==
X-Gm-Message-State: AOAM530uo+ZJ/weu33th1Q2vgYIHZ4szPco5tFzS9unqMnAbn9mPuixm SqKSNekwnyULCv77HNwoL/kcwiKN0wZnIFmBkuRIMA==
X-Google-Smtp-Source: ABdhPJwCAwBwxlrsoGT/nUvks6GaW4I+ccL0i4lT+bt5hZ6Bxl/vKOy9QXJVtiM3+iHDUhKaOMs66x/6jHVq4VhxPaE=
X-Received: by 2002:a02:cc53:: with SMTP id i19mr4090973jaq.33.1596188955824; Fri, 31 Jul 2020 02:49:15 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Date: Fri, 31 Jul 2020 11:49:00 +0200
Message-ID: <>
To: Robert Wilton <>
Cc: The IESG <>,,, dhcwg <>, Tomek Mrugalski <>, Ian Farrer <>
Content-Type: multipart/alternative; boundary="000000000000b4f44d05abb9b3e5"
Archived-At: <>
Subject: Re: [dhcwg] Robert Wilton's Discuss on draft-ietf-dhc-slap-quadrant-09: (with DISCUSS and COMMENT)
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 09:49:20 -0000

Hi Robert,

First of all, apologies for the time it's taken to react to your e-mail.
One of the reasons of it is related to your DISCUSS.

Thanks a lot for your review. Please find below some comments from my side.

On Mon, Jun 8, 2020 at 5:46 PM Robert Wilton via Datatracker <> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-dhc-slap-quadrant-09: 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Hi,
> Thanks for writing this document.  I have a few points that I believe are
> worthy of discussion.
> Disclaimer: I'm not familiar with IEEE 802.1CQ, nor am I a DHCPv6 expert
> ...
> Some of these questions/comments may have been answered there.
> My first question relates to process:  Have members of the IEEE 802.1WG
> had an
> opportunity to review and provide input into this document?  If not, then I
> think that it would be good for them to be given the opportunity to do
> so.  In
> particular, they might question whether it is appropriate for a client to
> be
> able to request MAC addresses to be assigned from the SAI or "reserved for
> future use" address pools.  It is worth noting that there is an IETF-IEEE
> liaison meeting on Mon 15th, that may help.

[Carlos] Even though we shared the document months ago (so we assumed that
they have no comments from their side), it was not until recently that IEEE
reacted. We have received comments from Roger Marks on both this document
and draft-ietf-mac-assign and we have taken them into consideration (mostly
the ones related to IEEE policy assignments).

These have been applied to -10 version, to be posted soon.

> I'm not sure that I really like how the algorithm is defined in this
> document
> (relative to draft-ietf-dhc-mac-assign).  In draft-ietf-dhc-mac-assign, the
> client makes a request, and the server can respond with a completely
> different
> smaller MAC address range, i.e. the client is just providing
> hints/suggestions
> to the server.  I would be much happier if the QUAD option specified in
> this
> document behaved similarly.  I.e. the QUAD option is used by a client to
> specify an ordered preference of quads to use, but otherwise the server is
> allow to offer up an address, or block of addresses, outside the preferred
> quads, which the client could choose to not accept, or release.

[Carlos] This is exactly the way the mechanism works. We have fixed one
point where originally the client was forced to reject an address
allocation not matching its preference. Now the draft allows the client to
accept an allocation that differs from the expressed preferred quadrants
(as you mentioned, the client can always not accept it and try with a
different server, for example).

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 1. Introduction
>    o  Quadrant "Administratively Assigned Identifier" (AAI) MAC
>       addresses are assigned locally by an administrator.  Multicast
>       IPv6 packets use a destination address starting in 33-33 and this
>       falls within this space and therefore should not be used to avoid
>       conflict with the MAC addresses used for use with IPv6 multicast
>       addresses.  For 48-bit MAC addresses, 44 bits are available.
> Multicast IPv6 packets shouldn't be a problem for the AAI range, on the
> assumption that only unicast MAC addresses get assigned.  Hence, probably
> the
> text related to Multicast IPv6 addresses can be deleted.

[Carlos] This has been deleted (the IEEE review also suggested to delete

> 3.  Quadrant Selection Mechanisms examples
> I see that this text as not being normative, and is potentially somewhat
> repeating what has been stated in the introduction.  I think that this text
> might be better moved to an appendix.
[Carlos] This is a point worth considering. I'm going to delay a decision
on this. Since I'm going through all pending reviews, I'll take a decision
at the end. I hope this is fine with you, even if at the end we decide to
keep the section on the main body.

> 4.  DHCPv6 Extensions
> The algorithmic description in this document seems to heavily overlap with
> the
> algorithm described in draft-ietf-dhc-mac-assign, with a fair amount of
> repetitive descriptive text of the algorithm.  I believe that it would be
> better if this option was written as a modification of the procedure
> defined in
> draft-ietf-dhc-mac-assign (particularly, if the algorithm is simplified as
> a I
> propose in my discuss).
> [Carlos] The algorithm should work as you mentioned. It's true that the
text overlaps a bit with draft-ietf-dhc-mac-assign, and it's probably my
fault as I tend to describe things maybe too much. However, at this stage,
with all the reviews the document has got, I'm very confident with all the
text there and I prefer to keep it.

Thanks a lot!