[dhcwg] Robert Wilton's No Objection on draft-ietf-dhc-mac-assign-08: (with COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Wed, 02 September 2020 14:02 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1683A3A0C50; Wed, 2 Sep 2020 07:02:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dhc-mac-assign@ietf.org, dhc-chairs@ietf.org, dhcwg@ietf.org, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Ian Farrer <ianfarrer@gmx.com>, ianfarrer@gmx.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <159905535006.24127.357884418092494669@ietfa.amsl.com>
Date: Wed, 02 Sep 2020 07:02:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/LOUJyvFkTg8DxngR2D5gqKlcqCg>
Subject: [dhcwg] Robert Wilton's No Objection on draft-ietf-dhc-mac-assign-08: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Sep 2020 14:02:30 -0000
Robert Wilton has entered the following ballot position for draft-ietf-dhc-mac-assign-08: No Objection 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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Previous discuss issues that have been cleared: Client SHOULD, server MUST ignore. In a couple of places in the document (sections 6, 10.1, 10.2), it states that the client SHOULD set 0. To allow the protocol to evolve in future, I believe that it would be better if the SHOULD is changed to a MUST. There doesn't appear to be any specification of how an OPTION_IA_LL should be handled if there are no IA_LL-options, or it contains an IA_LL-option that is not understood by the server. The text does also not specify if IA_LL-options can contain multiple options, and if so how those are encoded (presumably as an array/list of option values), perhaps this is already covered by the DHCPv6 spec? Similar comments also apply to the LLaddr-options field. 9. Releasing Addresses Once a block of addresses have been released, can they immediately be allocated to a different client? Or should they avoid being reused straight away if possible? Perhaps this consideration is already covered by DHCPv6, but it probably makes sense to say something about this, either in section 9, and/or maybe in the security considerations. Nob blocking comments: 1. Introduction Typically the new VM instances are assigned a random link-layer (MAC) address, but that does not scale well due to the birthday paradox. Perhaps either have a reference to birthday paradox, or briefly describe (in a sentence) what the paradox is. 4.3. Mechanism Overview Contains both: This mechanism can be administratively disabled by the server sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). And An administrator may make the address assignment permanent by specifying use of infinite lifetimes, as defined in Section 7.7 of [RFC8415]. Perhaps these sentences could be amalgamated? 7. Requesting Addresses The client MUST be able to handle a Reply message containing a smaller number of addresses, or an address or addresses different from those requested. Perhaps clarify whether the "smaller number of addresses" relates to the initial request from the client, or the value received by the client from the server in teh advertise message. E.g. could a server "advertise" a block of 100 addresses, but then only "reply" with a block of 50 addresses? 8. Renewing Addresses IAID is used before it defined. Perhaps either add it to the terminology, or reference where it is defined when it is first used? 10.1 I found the subtle distinction between "IA_LL option" vs "IA_LL-options" to probably be a bit more confusing than necessary. Possibly always refering to the "IA_LL_OPTION option" vs "IA_LL-options field" would add clarify, or perhaps rename "IA_LL-options" to "IA_LL-suboptions". The same comment obviously applies to the LLADDR option definition as well.
- [dhcwg] Robert Wilton's No Objection on draft-iet… Robert Wilton via Datatracker