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