Re: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06
"Eric Vyncke (evyncke)" <evyncke@cisco.com> Thu, 04 June 2020 14:30 UTC
Return-Path: <evyncke@cisco.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF503A0A8C; Thu, 4 Jun 2020 07:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=e/J0+Kai; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sxN6jo2W
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 O3oMYWCiKt7p; Thu, 4 Jun 2020 07:30:09 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099F43A003B; Thu, 4 Jun 2020 07:29:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7628; q=dns/txt; s=iport; t=1591280983; x=1592490583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tocsyOHanWkcxvUsUkxegB1ye3LCUwNT0Ny4GyEFZUg=; b=e/J0+KaiS4iuAI1ksorWlkZGooKIs3LWyt9Ap2cPJp9w6yP+MM3jssMr JJh/20Ak2Hu1DuF7HJfyr0YPHhyJGDRWY/n7Wo0dx8kJH7wWmjRiBqOLD 2Zc60FDamfpPlZi6Szqffe4QN9C6Act8VdxBp2YF4G6F+nNbA9neGhvvB U=;
IronPort-PHdr: 9a23:zuJqUBMpoFV8n3hidnIl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEvKwz3kDIUYid4v4CifKF+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGB8fyahvbrjuw9W1aFhD2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DgAQAfBNle/40NJK1mGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBSoFSUgdvWC8shCWDRgONP5hQgUKBEANVCwEBAQwBARgLCgIEAQGERAIXghQCJDgTAgMBAQsBAQUBAQECAQYEbYVbDIVyAQEBAQMBARAREQwBASwLAQsEAgEIEQMBAgMCJgICAiULFAEICAIEAQ0FIoMEAYJLAy4BDqQZAoE5iGF2gTKDAQEBBYVDGIIOAwaBDiqCZIloGoFBP4ERJxyCHy4+gmcBAQOBSAIYgxQzgi2OY4MfoHKBAAqCWYg1hhWFVIRcAx2CZ44ejTWQdIl+lAoCBAIEBQIOAQEFgWoigVZwFTsqAYIKATNQFwINkECDcoUUhUJ0NwIGAQcBAQMJfI4tXwEB
X-IronPort-AV: E=Sophos;i="5.73,472,1583193600"; d="scan'208";a="490644979"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jun 2020 14:29:42 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 054ETfgK015188 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jun 2020 14:29:42 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 09:29:41 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 09:29:41 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 4 Jun 2020 10:29:41 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EHG1tnOi/9Qcx9PFN5t23zY9iqK2zGVvnPFXyQAOchFzeXDgop+DAIXTl0WxTUflS8Obt35rSy/X/I3VGAIYrTXsJPVm5349yqsiqtmb0f1YWEJSOEGy+fY1/YV9M7YnN0j/a2LO8aJ8HodjGzuA6OxDF6hiUvTIp/b8IxLBbfz8eYcWtT/u/d+r2BzZm9JutmdWHwGa2MPQjw6LEZywVc/EH4NbDINu0CRFRbb/TSHPU3EU8GDV23+V4RD1nhwn/Rrjg8aaoS9zAYqWy/7TgxV/BWzHMXtMXuyAI/RWYzxGnhbh2U2CrOXcCx0PyFS46PMFZTaj5I5PUZrBjBvpkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tocsyOHanWkcxvUsUkxegB1ye3LCUwNT0Ny4GyEFZUg=; b=TsAYzYP0TxkMb057MZYVtAW9kFMmbRbzlpFrUjK8MEjtg9iGKljHZpK26l8+CTCs7J5vALs6++Xu0rmVQItcZGaHiEuj6QYQ79GX309ibOLaaAfsgrBshh8Ixo5qrEz9VQRVlcp7rXrW2kgi5tWHOQT5AcG9Ob5WjIfY9Cpo57QalCoeYu1j6OGWN/mhYaua69sUPmSfOiD+6A+/E64/8OjDNG8KOpqipe8wSi3uVI1krJu5U5eu9k8oKVgOuyPag9owqyvtNokZC1sGPOxHWmqKI+XjpNAxdNPWGF5YGgDcQSPS1iT+cHHm5a0Qj9ywhAlR/O+/DSloPm8nuYVR9g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tocsyOHanWkcxvUsUkxegB1ye3LCUwNT0Ny4GyEFZUg=; b=sxN6jo2WGmItwThwPLf/Y7Nm1G5gtRYtyfr8y34qzUwwnvDrBL3hsD/HvlUU/n1M760i0Gw4vkVSoaKzedRgDn8CA6hEawNvn4LEfv/vhpLSXxk9X//r+IUTMzuCfP6RzCk5IzNJGZG24QyCy/kPBf5Y9LcN/SfOsolPjGDSV5I=
Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1609.namprd11.prod.outlook.com (2603:10b6:4:8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 14:29:39 +0000
Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630%7]) with mapi id 15.20.3066.018; Thu, 4 Jun 2020 14:29:39 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Tatuya Jinmei <jinmei@wide.ad.jp>, "int-dir@ietf.org" <int-dir@ietf.org>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-mac-assign.all@ietf.org" <draft-ietf-dhc-mac-assign.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06
Thread-Index: AQHWOdUYGM/CnuEwnE673cqY5ZrAJajIpwWA
Date: Thu, 04 Jun 2020 14:29:39 +0000
Message-ID: <2C3E6375-51E1-49B5-B044-396946A2BA92@cisco.com>
References: <159120898987.8437.4415340061530507051@ietfa.amsl.com>
In-Reply-To: <159120898987.8437.4415340061530507051@ietfa.amsl.com>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: wide.ad.jp; dkim=none (message not signed) header.d=none;wide.ad.jp; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c1:36:a0f1:58e8:99ef:8a8f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 97ac8fd4-18da-49e6-8dab-08d80893b6f2
x-ms-traffictypediagnostic: DM5PR11MB1609:
x-microsoft-antispam-prvs: <DM5PR11MB16091CA185375103150A3F3CA9890@DM5PR11MB1609.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04244E0DC5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: f7skSa3G8OzYzqOkuxYQXon10smHXeJoS8CD+PzaJkj1jf7Hbnv27GRrTO4VQvXqrhn9ZbGO0k9aYPIowQINVUpvpWhMSBIkd6UyHAjOT7NQHiqd7YDHoNo8EfwvCb5PEtaXsRrG9A8nwjJg/vWkJeDeRAgiRqhJPnH8Zt3QwruALRkjJFwNvi2IxTS31RaPclo6xRRW1M3W49PTCFZkPDegdCAnaUp6s4A4De1yX798GGhgF/zv4X/hHNkKi86hkmsp9bG+Fje2IWFxDA1QPYN3jbobgTVrnzpRt+/SuMnT4WLu/JDi5IUitFiIkZvb1LG9coZIsbFwsmT9/5RseCAmKh5F7uVw9gUnvtDI2VZ/WolDW2FiVuQKmamY9Xu5mGzOtYMqbjepqeJe36JayA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(39860400002)(136003)(346002)(376002)(966005)(4326008)(186003)(6506007)(316002)(478600001)(33656002)(66556008)(53546011)(66446008)(8936002)(66476007)(8676002)(2616005)(2906002)(71200400001)(66574014)(66946007)(76116006)(64756008)(91956017)(83380400001)(86362001)(6486002)(6512007)(54906003)(110136005)(36756003)(5660300002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: UOMVOVNMLupSrOjCHUMaWlo8vW/ApCykoe2hXd5ysM/cX4JeDnXr88zYI7JjykU/Gk7fVcdEqNaGpR/6uWvpmEmuwAfZWe1vmWTGvLplrQgj1idg5MCMnFW17M7ajFSmaFlZaMKJTZqkMzFz5G8l6sxEBVD2j030mBRA5xp9qSNXWFh39ih02uVjPJXVc5QT46YQiHWry3WfBiKHBUtjTgHQW3MBsIwhexzOJfVcMVBb8ucezUVkLr2fIis3RQUoiuIwZ616/7GyxabM3jcwLm5xtDxafouXmBYRaI18ZFQPZfI48ifoae1TEgjCdBR1mj0MAFzx8N2oLPcEMvz77TTr3LaMDRgiyX2ekLQ49Uk0uyqV/zet1QWebNI5np3xafksYLi4TvVtY0s9PfrzBBAAwdTjbasvaWmAqyok2Apci4+I7eOBK2Otva/HljjyPDpJmAfIFCSt0UClYBtHS6oXzHiQatO/2Ho4//1IzOA8t8Fek0VWqbsH8001tHBfsniFEDbZZ7QsIeo+A+BTN5rJD9E0FvRW+uC5KBdO+Ck=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <AE32F688960E2E4CBEC52F48F924CD07@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 97ac8fd4-18da-49e6-8dab-08d80893b6f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 14:29:39.4279 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YFiSZ2coHYKicrBuzIu2HjKcNi8skxW9lczL0rDbVe4lgOLvEP8MSxDMYmUTn5CW52jwI4g4PznhP3U0QE2wPw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1609
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/bmjskjfXJECYtn_iCccW_7RYS30>
Subject: Re: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2020 14:30:11 -0000
Thank you Jinmei for the review. I will make sure that your comments are reflected in the telechat -éric -----Original Message----- From: Int-dir <int-dir-bounces@ietf.org> on behalf of Tatuya Jinmei via Datatracker <noreply@ietf.org> Reply-To: Tatuya Jinmei <jinmei@wide.ad.jp> Date: Wednesday, 3 June 2020 at 20:30 To: "int-dir@ietf.org" <int-dir@ietf.org> Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-mac-assign.all@ietf.org" <draft-ietf-dhc-mac-assign.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org> Subject: [Int-dir] Intdir last call review of draft-ietf-dhc-mac-assign-06 Reviewer: Tatuya Jinmei Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-dhc-mac-assign. 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 https://datatracker.ietf.org/group/intdir/about/ . I've reviewed draft-ietf-dhc-mac-assign-06 (07 was submitted while I was reviewing 06, and I also checked 07 on some specific points to see if it's changed, but the check is not comprehensive so some comments may be already moot or addressed.) I think this draft is basically ready. Its purpose and protocol details are well written, and the protocol is generally a straightforward application of the basic DHCPv6 (IP) address assignment protocol as described in RFC8415. I didn't find any obvious problem. My comments are largely editorial. The first one for Section 8 may need some discussion, but I'd basically leave the authors whether/how to address the comments including this one. Specific comments: - Section 1: The IEEE originally set aside half of the 48-bit MAC Address space for local use (where the U/L bit is set to 1). In 2017, the IEEE specified an optional specification (IEEE 802c) that divides this space into quadrants (Standards Assigned Identifier, Extended Local Identifier, Administratively Assigned Identifier, and a Reserved quadrant) - more details are in Appendix A. I wonder whether this paragraph could refer to draft-ietf-dhc-slap-quadrant. - Section 4 Clients implementing this mechanism SHOULD use the Rapid Commit option as specified in Section 5.1 and 18.2.1 of [RFC8415]. Just out of curiosity, what's the rationale of this SHOULD? (It's not obvious to me and) it doesn't seem to be explained anywhere in the draft. - Section 8 [...] The server MUST NOT shrink or expand the address block - once a block is assigned and has a non-zero valid lifetime, its size, starting address, and ending address MUST NOT change. We may need some clarification on the implication of this requirement on the following description of draft-ietf-dhc-slap-quadrant-09: [...] 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" (i.e., different) addresses. (Section 4.1-5) since on the surface of it, this could read as if it's against the MUST NOT. - Section 8 same text as the previous bullet While commenting on the previous point I've noticed one minor possible glitch: while "its size, starting address, and ending address MUST NOT change" prohibits any kind of change to the block, "MUST NOT shrink or expand the address block" sounds like only limiting a particular type of change (shrink or expand). So ,it's not 100% cleear, for example, if changing "start=02:04:06:08:0a, size=1 (extra-addresses=0)" to "start=02:04:06:08:0b, size=1" is allowed or not because this change does not "shrink or expand" the previos block. I believe the actual intent is the latter MUST NOT, i.e., prohibiting any kind of change, so we might rather say: [...] The server MUST NOT change the address block (including shrinking or expanding it) - once a block is assigned and has a non-zero valid lifetime, its size and starting address MUST NOT change. (btw I've removed "ending address" for another editorial cleanup because it seemed redundant - given it's a "block", the "ending address" is determined from the starting address and its size, and the "ending address" doesn't appear in the protocol explicitly). - Section 10 It may be too obvious, but you might want to clarify that the option field values are in network byte order (similar to Section 8 of RFC8415, for example). - Section 10.2 option-len 12 + link-layer-len field (typically 6) + length of "link-layer-len field value" may be better? Nit - Section 7: s/chose/choose/ [...] However, the server MAY chose to ignore some or all parameters of the requested address block. [...] _______________________________________________ Int-dir mailing list Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir
- [Int-dir] Intdir last call review of draft-ietf-d… Tatuya Jinmei via Datatracker
- Re: [Int-dir] Intdir last call review of draft-ie… Bernie Volz (volz)
- Re: [Int-dir] Intdir last call review of draft-ie… Eric Vyncke (evyncke)
- Re: [Int-dir] Intdir last call review of draft-ie… CARLOS JESUS BERNARDOS CANO