Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

ianfarrer@gmx.com Tue, 07 January 2020 15:10 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E3812001A for <dhcwg@ietfa.amsl.com>; Tue, 7 Jan 2020 07:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMIab2bmReed for <dhcwg@ietfa.amsl.com>; Tue, 7 Jan 2020 07:10:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB9E120142 for <dhcwg@ietf.org>; Tue, 7 Jan 2020 07:10:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578409838; bh=i4U5B2OK/+RFkYk8sB19Hux01f95YWgrMOmbImjDeLQ=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=aubqZ0uYmv+N8GJwbEGyGr9ZMLZcNUpsFwK3QyJynrlGQ6VF6LS7mLSpB1mAPFLFp V4+kjQ/Zh6pNFRoPY/7UJp6j492XAfCq/ZPXawMWg1bwkoB2KBR0/RkwPDHVKb3uS6 z6PFwqMTA/2GdLigcgzKh75F6DYTpttn+bcBtCfI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.117] ([80.159.240.69]) by mail.gmx.com (mrgmx004 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MG9gE-1iuLju2Za8-00GZTu; Tue, 07 Jan 2020 16:10:38 +0100
From: ianfarrer@gmx.com
Message-Id: <CD79D9E3-4B44-4D9D-85A6-849EC540DCA4@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_88A952D1-639E-4CDE-A724-7D24530E10CC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 07 Jan 2020 16:10:37 +0100
In-Reply-To: <c9976d83-7243-cf44-a9c6-ff858afb5247@gmail.com>
Cc: dhcwg@ietf.org
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
References: <c9976d83-7243-cf44-a9c6-ff858afb5247@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:nekq+u+DtyrhXwSralD2hmgf/SnF0vpV2HmaTjWTGNrEy1uuGWS hAbJxrihtB57qH1y1DMv/6Ooa2Ei8lV+a471RXkRhDWSodlLIgRUIQhn+Kh01TrdiWrqti0 KUWsj7pOo7ev+AR/M0ZB0mGoHgYoBhpQLH9eL5x0bt/fiACiHeYUQvB0ZRy0g9eZ3AburD1 H9+O0VRQtzmr3Dheu7h9Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:kOSd0Yk3Fag=:zbCPTjLcDvpH77SYXxlz84 aIuobEAbDaJXn8KAkhNnMdEGYlyy0isJlsA3C2IUHhNnqBNpFbw1F4xQXNsje01Kuj6SocE6u q/Wpli7pTm3yIZXB7ENkqcgGBeknef7hWecSCZLp/YPhsYN46SFO8QOOSMYTCivBkG4ZyPMA+ hY6bj9+RnZHSanrU0HGKGR4cLagv5fDLF0K/6ZqBY+gle+LV5BzKfyktK6Pc/lVfipIR2xO3C JLRgtDIDjGyN2camEz6x5ZtnbixWdXxcSMVeWyEHvofVkwmJAVb9d4FTq+K7myUh4jXb2eIOa spSAFEcNPFR4byRbyyxLblj4GkT5ENDOpFQxPClAu5Jy8c72o9d6GFHkZY+u+Bte6m49VN+kH rwOxnTX+ZApX4H6sOihSdawmG3AG4QV33C1kky57qOOqTy/mmKe+HqFpWScu0xYvZFmJ3Tbmu DbQOKz+rmCp8CFxp8S76z1j7Xr+lIDgoTOV+9kaJjhfxze27O488JZyOXn7Sk/XSlZho/xl8E LL59LJtUERifAjx1zOIQRld3IK6A7EoAZDTPzmm5rNLTj5a5ZSQdIzVb1aF/6YrxkPE+yMZq0 a76j8/iyCEFUQZHlgoinREpyKK2vtSxPJE7hJAtgb1TaHw/EgirxsX6F+XdC3C1PvKAi252dV mw/Z1k3hThcXeZsLlZc/gituKrJdxBsbpXR+8qoHnweNcRfZKMnWgYSCOozf9hdcyt1H0seLB o5vES20N5P8Ef6c+EZrZ106hSKvqIsF7A4EPmogd0JcF3pTSodEtF/iZeSvtwpvJYJefoq6I4 KvOeFj3ZfAMrL/jrL+dCaL8BdTJEHcBLwqs3dSqlohAEqzxxiXyschDt5+06q0hB724CmX8M9 vDvcj9MklVV0RtSZlHxOu3c3UiUXKw6weVDkj3BNpy1Eb7fWiwJ5DQXbvb0O46XNBxDsiZan3 RrlQ8KZeZSTs7gV/bSnvGm1G16NCFjTumaJw9e18S1wPfpSWNL97q4MNEUu5IuaqvzKbvNa/m Vhso9QTHwwKe3qvKY5xeIID/SYNsdM6roSBDEhoTP1qxUZglGiSOsVzZi31NBCRN9OLYyZrwF bzZWcztH+6j0iC4HL8xc4w28vxrV9Xyn/NVS06Bj+IOUK+BPNZmG06IsYj8kKUlgM0Dc9Lb90 dCxiU+WwE+RNQN1BSpxjNFUJjOxU7DQ2wPU27yJGwOd7B429MI50Uhm1GPiDzgscXfuKKXlgs jf2C72dWz8e9WMZUutro7TyoT97iIQl722DDLMTd6tcR7q5HqGqAbw5A/Yb0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/5y7IVjcSxLyMPhnFFVkK-IZup9Q>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 15:10:57 -0000

Hi,

As mentioned in my previous email, here is my review of draft-ietf-dhc-slap-quadrant-01.

Thanks,
Ian


Major Comments
———————————

Section 4.2

If the relay needs to insert the Quad option, then as I understand it, the right way to do this would be for the relay to put it into a Relay Supplied Option Option
(RSOO RFC6422). This requires an update to the IANA table at:

https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#option-codes-s46-priority-option
-----

Step 3. If the client is sending multiple instances of the IA_LL, how are these associated to the relevant Quad option(s) added
by the relay, or is only a single quadrant possible for all of the IA_LLs in the client’s message?
------

Section 5.1

The structure of the option seems needlessly complex and introduces problems/exceptions that currently aren’t discussed, but could be 
avoided. i.e. what happens if a quadrant id appears more than once? What if two id’s have the same preference values?

Couldn’t a simple, ordered list be used here? This would be processed in order (first to last) until a match is found. RFC8026 provides
an example of this.
———

I’m not sure if a new IANA registry of the valid values for the 'quadrant-n’ field is necessary. I’d appreciate the Chairs input on this.
--------


Sections 6 and 7.


The IANA and Security Considerations need to be completed. I’ve indicated necessary registry updates where relevant.



Minor Comments
-----------------------

Section 3.

"Migratable/non-migratable VM.  If the function implemented by the VM is subject to be moved
to another physical server or not.”

Is the above statement accurate? Surely it’s the migration of the VM (and its function) to a new
physical server that matters here.
———

Section 4.1

A ’NoQuadAvail’ error code is mentioned, but this is the only place in the document it occurs. If a new
DHCPv6 error code is being created, then this needs to be defined and the IANA registry updated:
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5

———
Section 5.1
The ERO option is introduced here, but I’m not sure how/why this would be used. If the server was to echo a Quad option back
to a relay, what does it do with the received information?




Grammar / Wording comments
-----------------------------------------


1.1.1. Wifi Devices
"but ELI/SAI quadrants might be more suitable in some scenarios,
such as if it is needed that the addresses belong to the CID
assigned to the IoT communication device vendor.”

Wording is quite cumbersome, suggest:

"but ELI/SAI quadrants might be more suitable in some scenarios,
such as if the addresses need to belong to the CID assigned to the IoT communication
 device vendor.”
——

1.1.2 Hypervisor: migratable vs non-migratable functions

If a VM (providing a given function) might  need to be potentially migrated
to another region of the data center (due to maintenance, resilience,
end-user mobility, etc.) it is needed that this VM can keep its
networking context in the new region, and this includes keeping
its MAC addresses.

The language is a bit redundnat in this sentance. Suggested re-word:

If a VM (providing a given function) needs to be migrated to another region
of the data center (e.g. for maintenance, resilience, end-user mobility, etc.),
the VM's networking context needs to migrate with the VM. This includes the VM's
MAC address(es).
---

Non-migratable functions.  If a VM will not be migrated to another
      region of the data center, there are no requirements associated to
      its MAC address, and then it is more efficient to allocate it from
      the AAI SLAP quadrant, which does not need to be same for all the
      data centers (i.e., each region can manage its own, without
      checking for duplicates globally).

Suggested re-word for readability:

Non-migratable functions.  If a VM will not be migrated to another
      region of the data center, there are no requirements associated with
      its MAC address. In this case, it is more efficient to allocate it from
      the AAI SLAP quadrant, that does not need to be unique across
     multiple data centers (i.e., each region can manage its own MAC address
     assignment, without checking for duplicates globally).
——————

2. Terminology

This has the following sentence:
"The DHCPv6 terminology relevant to this specification from the DHCPv6
   Protocol [RFC8415] applies here.”

…then goes on to redefine client and server. Suggest that the above sentence
is replaced with:

“Where relevant, the DHCPv6 terminology from the DHCPv6
Protocol [RFC8415] also applies here. Additionally, the following definitions are updated
for this document."
----

There also needs to be a definition for the relay function, as it needs to be updated for
the Quad option as well.
—————


3. Quadrant selection mechanisms

s/Quadrant selection mechanisms/Quadrant Selection Mechanisms/
----

"We next describe some exemplary ways to perform SLAP quadrant
   selection.  These are provided just as informational text to
   exemplify how the quadrant preference mechanisms could be used.”

Suggested re-word:

The following section describes some examples of how the quadrant preference mechanisms could be used.
——

Putting the IoT, Wifi and Data Center examples into their own sub-sections would improve the structure and 
readability.
———

The way that the IoT’s SLAP quadrant decision making is written implies a level of autonomy and free will
that devices don’t possess and many of considerations are unknowable to the device itself. The bullet points are
considerations that the device vendor/administrator may wish to use when defining the IoT device’s MAC 
address request policy. Please reword to reflect this.
——

"IoT devices are typically very
   resource constrained, so it might be as well that simple decisions
   are just taken, for example based on pre-configured preferences.”

Suggested reword for clarity:

"IoT devices are typically very
   resource constrained, so there may only be simple decision making
process based on pre-configured preferences.”
——

s/Most modern OS/Most modern OSs/
——

s/and this might mean the OS to force the use or change of a local MAC address./
and this might require that the OS forces the use of a local MAC address, or that
the local MAC address is changed./
———

4.1 Address assignment from the preferred SLAP quadrant indicated by
      the client

s/Address assignment from the preferred SLAP quadrant indicated by
      the client/Address Assignment from the Preferred SLAP Quadrant Indicated by
      the Client/
——

s/We describe next/Next, we describe/
----

Much of the content of this section duplicates what is described in [I-D.ietf-dhc-mac-assign].
It would be better just to have a pointer to the relevant sections of that document and describe
the changes that the Quad option makes to this process.
————


4.2 Address assignment from the SLAP quadrant indicated by the relay

s/Address assignment from the SLAP quadrant indicated by the relay/Address Assignment from the SLAP Quadrant Indicated by the Relay/
——

s/We describe next/Next, we describe/
——

Figure 4 seem to show that the relay adds the Quad option into the client's SOLICIT - i.e. alters the contents of the client’s
message.

This is not described by the body text, but the diagram needs to be fixed to avoid confusion here.
———


5.1. DHCPv6 options definitions

s/DHCPv6 options definitions/DHCPv6 Option Definition/
——


> On 30. Oct 2019, at 02:51, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
> 
> Hi,
> This mail initiates a Working Group Last Call on two related IDs:
> 
> Link-Layer Addresses Assignment Mechanism for DHCPv6
> draft-ietf-dhc-mac-assign-01
> https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01
> 
> and
> 
> SLAP quadrant selection options for DHCPv6
> draft-ietf-dhc-slap-quadrant-01
> https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01
> 
> Authors believe those drafts are ready for WGLC. Please post your
> substantial comments and your opinion whether those are ready for
> publication or not. If you have minor editorial comments, you may send
> them to the authors directly.
> 
> Please post your comments by Nov. 17th.
> 
> Cheers,
> Tomek
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg