Re: [dhcwg] Yangdoctors early review of draft-ietf-dhc-dhcpv6-yang-19

"Bernie Volz (volz)" <volz@cisco.com> Thu, 03 June 2021 14:07 UTC

Return-Path: <volz@cisco.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 EC8F73A1368; Thu, 3 Jun 2021 07:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.896
X-Spam-Level:
X-Spam-Status: No, score=-11.896 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=edNJlvd1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qIWxeQeK
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 G1nBdNrc0Utx; Thu, 3 Jun 2021 07:07:47 -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 B45073A12F9; Thu, 3 Jun 2021 07:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9203; q=dns/txt; s=iport; t=1622729266; x=1623938866; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NrGTuD2Fv27iKeg9YRMxKswddEkYOPY1atWBYWkcFjs=; b=edNJlvd1QNBQOzgz41FuhPETce190665LScm8uck12pKbZeNKipsLrgD LHOA0BMJpRWkMGXxHOfmJ1T4jLMlYDe9eDZ1aNsIsJ7Deo7mUeTp3KqmW lZiFGa7Wtp0h4kh+lbDs3ucWUw9u1Dq3UY4DHH1gPTd9Z23+FepjBiqEJ Y=;
X-IPAS-Result: A0DQAgD54Lhgl4QNJK1RCR4BAQsSDECBTAuBU1F+WjcxC4gFA4U5iHADj1GKPoEuFIERA1QLAQEBDQEBKgsKAgQBAYEYgzgCgX8CJTYHDgIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFaA2GRAEBAQMBAQEQKAYBASwLAQQHBAIBCBEDAQEBAR4QJwsdCAIEAQ0FCBqCTwGCVQMOIQEOngMBgToCih94gTSBAYIHAQEGBASFNxiCMQMGgTqCe4pvJxyCDYEUAUOBX4EAPoIgQgEBgTQSAhokgyeCDCKBWXEBPRwKAQNDEBcJAi4LHgYZLBoeBgEDDAMgFimQXCYpDI5tmiUJgQwKgxuYHYVpEoNeixuQOYYolUuCGJ0dhHECBAIEBQIOAQEGgVsKKIFbcBUaIYJpUBcCDopwgy8JAw0Jg06FFIVKczgCBgoBAQMJfIkoAYEQAQE
IronPort-PHdr: A9a23:6gn8WBIydjwSJzmuztmcuYMyDhhOgF28FgQJ4Z0hjb9FbuKo+JGxd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoJuLhaCo8E c9eElRi+iLzPU1cAs2rYVrUrzW75iITHROqMw1zK6z1F4fegt7x2fq1/sjYYh5Dg3y2ZrYhR Cg=
IronPort-HdrOrdr: A9a23:Lp3T1aGHyx1ZtwAbpLqFPZHXdLJyesId70hD6qkvc31om52j+f xGws516fatskdvZJkh8erwX5VoMkmsi6KdhrNhfItKPTOW9ldASbsD0WKM+UyaJ8STzJ856U 4kSdkDNDSSNyk7sS+Z2njDLz9I+rDum8rE6Za8vhVQpENRGtxdBmxCe2Cm+zhNNXF77O0CZe OhD6R81l6dUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonSs2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaAkEyzzYIbiJaYfy+wzdk9vfrmrCV+ O8+ivICv4Dr085uFvF+ScFlTOQiwrGoEWSuGNwyUGT0fARAghKUfaoQeliA0fkA41KhqAg7E sD5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4dkWUzxjIfLH47JlOx1GnnKp gZMCjW3ocbTbpbVQGQgoBL+q3iYp0eJGbzfqEygL3d79ENpgEN86Ix/r1pop4vzuNOd6V5
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,246,1616457600"; d="scan'208";a="703846825"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jun 2021 14:07:45 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 153E7j0K027686 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Jun 2021 14:07:45 GMT
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 3 Jun 2021 09:07:44 -0500
Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 3 Jun 2021 09:07:44 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 3 Jun 2021 09:07:44 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z5G20MP7OFUPEv/ND+ArwiJ4J25b8M3x3RgVpOgTDy6vvqfuJb2NBZj9DiWPOx2YU5eSqrmxzrzaNpNjIwBdOQ3kZBjB7lahExHUAkjXkaMEuWomZEu2It+4heL8Q2y1GZCrJWUH7v5PWVsqdXVCnylXT0jjgLSMZT5Yl6VuqlzyYocR7DRKYZaXFACzloySVZwkNE5POxGvQnnQSdkCeqZVjZsMnEL12rYM0wPZanmI9VbI8QlG2KCTUeIwQguUHuhEbv1yVqF/FO/SQIZxn8H4qaZqiG4jmiVdYaqNdhUfsknDYr0VQGuKOV6l545TCJwFP4xj5nXsv4XgmF4zUA==
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=7nNZenxxlDoBDS0+wmmQEo9wdu00peXu/8rCiyalzBM=; b=XRklaM4Sbn5BmLK2z2cj6fTOOgc2uKCyPTsVfkUSGFRc8/PcpmBcPLa8xRLs21uEZsnqe+PaME0hTgx+pB2uUkCeX9WbOrOkzh6SUk92bw/Ilnvbc0a4XZ9uRYfxCS1dZ9Fwjk5vLQtZ0ExtcTHKbQ5/LRl/BKaF9DI7irRj36MF0hfCPseYDZlezA3j/fVl8QoTbx+kpMod32h31Yle+B1XOoZ74ZVyFXbNYjuqlLQ6oIFnJ0EUfd85UO6KE8lElI4H8zPpqvu80gfdur0zIMBKNoHnUA3Pvee4bvyEPVodTgfQGxGKu9s4coShId8hnKY3n7HTNWv9jAQhyloFcQ==
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=7nNZenxxlDoBDS0+wmmQEo9wdu00peXu/8rCiyalzBM=; b=qIWxeQeKo8ofSionJuDiEt/x4gr5tkj/hkOmv4eq0kCB2FgVOcQMWw0q/aD64WHrKY/rwxo7Tcs7N8KI391/rss7OLmna6ZDKwZNVLYmpf1nINSjvLIhekZ76nskvpfbyTnkNrwErm5sadYTvFhR5dlzIQ3JqMOx6LnZyhf47aE=
Received: from BL1PR11MB5494.namprd11.prod.outlook.com (2603:10b6:208:31d::19) by MN2PR11MB4614.namprd11.prod.outlook.com (2603:10b6:208:268::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.23; Thu, 3 Jun 2021 14:07:41 +0000
Received: from BL1PR11MB5494.namprd11.prod.outlook.com ([fe80::58f9:f5f7:a657:9f31]) by BL1PR11MB5494.namprd11.prod.outlook.com ([fe80::58f9:f5f7:a657:9f31%3]) with mapi id 15.20.4195.022; Thu, 3 Jun 2021 14:07:41 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: t petch <ietfa@btconnect.com>, "ianfarrer@gmx.com" <ianfarrer@gmx.com>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "draft-ietf-dhc-dhcpv6-yang.all@ietf.org" <draft-ietf-dhc-dhcpv6-yang.all@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] Yangdoctors early review of draft-ietf-dhc-dhcpv6-yang-19
Thread-Index: AQHXWG2tB1fKrq63lk2YH1341zHS1KsCUHBg
Date: Thu, 03 Jun 2021 14:07:41 +0000
Message-ID: <BL1PR11MB549448755772D0B61D99181DCF3C9@BL1PR11MB5494.namprd11.prod.outlook.com>
References: <60B8C04B.1060703@btconnect.com>
In-Reply-To: <60B8C04B.1060703@btconnect.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.65]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2a2d57f1-d91f-4cae-91cc-08d92698f3e7
x-ms-traffictypediagnostic: MN2PR11MB4614:
x-microsoft-antispam-prvs: <MN2PR11MB4614DD81CFF8BC166ECBE10FCF3C9@MN2PR11MB4614.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8wXAa6D6cD4AaOSWUrrcqzh+x6cWPUTAhWu/UGxp/vymyOLOBkByVvyULNdJv984xIU9iI7g+QwZ2VuiYrAymVSAsyqY2cpDvGZyoj0IRc55KzyTVJqjEeS84pTslVj9J28hxmCt5YmYZbAk/bwz7uDVvBatEpY+wNCGPDQFTArGTOk4XtPbhn/IeT58n7adHsqnDFZiSJg0ngt8LS8YDb/H5VhxceqAwcR14WGnbqE85/AGijk88UyhhpphP4cvSqudc5DoW8S9rO0Zii8NuiZQcJnzdtGIJ0B+E78ypS5+KcrmW0bX6WmSDGU9+wRLVlgUlz75AUeGtN93XQmjTD2+LHgL7fTMTbjiNYeNM335n1dHncsKvk6X+JHtZVkorw+YLUinooc+dp/fnlf5rDGxFTwmrkPrpXhGjgjJL5o95AoB1JLyIM5OKX19x4eVTxFQzKEoS0P5kaQ6rIfYHc/C6tOcMGdIYEXotrV0a88N8W4AHODodirD/GwGvF/4EccEoucTlJHs7iMnHeSj0hZot+qcKVPURYe2bPIf0UbP20jNHxSsmGMaop1Zu169ESjzgW/iNFZoesYMTuvUxbGObwaOo9PujHfylbKItd7EBQGrVMVnyFrOkC2vmPxjDY4akMAaxPS5nFNJaiWQLLofKVZPUvgx/IS8y8Y3iAMZhrNfTKujzWMnusZKP5B8w1vufKo6beVz6/q6KZGKXTRtQRxh/FVwHcmJE/yF7/hsgDl9OUWmuMLjgPZN5BPFd0mWRWlejRW+9NdgeLshog==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL1PR11MB5494.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(376002)(396003)(39860400002)(346002)(83380400001)(6506007)(76116006)(7696005)(966005)(478600001)(4326008)(2906002)(71200400001)(122000001)(38100700002)(5660300002)(52536014)(33656002)(64756008)(9686003)(186003)(26005)(316002)(296002)(54906003)(110136005)(66556008)(66476007)(66946007)(55016002)(66446008)(86362001)(8676002)(53546011)(8936002)(518174003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Zh+6WmUgQBljBd8SCmHTLjCZBamT8bvIfbrjMfh3ov0NxLUl5nXgHljYEisxMgkQLubCPkUcjk3/31HAHp4613uqkRb5Zb+0IuQh7epI2zfL9+adm6lhtReZ+P1RqIJZeG5Tx+u7i7ue7hkDddSWyMBSrraSU8MjywSAEd/2QthHobzp3Kt//AkQibVXTQAOtA6O44GkRw7SOpRV6n/gAUaGLlxRCRqPKJf4jMw8VFj+HG/LSH4GvjZQcF/L+eML2fKmPyd48G96giiMAZz7KqXIflTE8X+wFftYUMCXHNwKD3Vc74x3pEQjJBqox3tYsdfM5VuZMo5wCx431WgWuYRRc1A7mSeVQxKs5dFcPE9VPXYi/tpQLRUtxl15bOl2fmrGX4tTB58gRjctby6gGTHn2J5sMhx1mZZnZd+NMDeVA9GcR9nDYL50YCaQkPOhshERU3r1qanU/HKtom9ixZ8yj8WXCfjud9TFTqkQOPxxZUEZHJQrn78lUtf1J5jsO6ddHPjn2GKr7sPiEs5uNh+7VmTIfWJXULDi4R7QU+gigD1cb+21b7vgpkDZXONVoS5PvGV6qBow9LBaUXggTRHFiOebCFi1HLu1aGkHWjlCw3NX0yUVyHuVRzuc6dorpMiIAm9UlF4BkNLXrxUTyUHwbAeAB8jgVsXcH5EQFBvP0DAyOx0E/lFe+T1ZC+QocxDm6qO+UAdB99Fxn6+6gxsDJxy5OxPDMtvWv6lZPOncoD4VhrcEIX+ZFPsWjmJBzmMnUg1ClkdneS4tgWQAaBPaQ+56p7Gjez2R/Rg7qAi7bbC7PRr2soiAy0NeaGpWvpH4y96OIk1LXydhsOPREaNFfqfAGsS82cpHOgi43PKMrYQh8ESHcNJ78cusadaZH36OI6zlWpBx2D0WOEeqYUcuAUZ4waUVJ6o+sM47kGD39sM0+tFqFenPD4Cq8v9eh36kyp0x89qXCYx31bKDM/jw30nbgIXDqoQhfu2rCXPmERlg2VtFsQla6Bsv6zJcUcxJ2kx6R3vmjFiBZRWi0ShlYIzmSilHWHcX9GjI7gEz58dOoMUUN/nJ4Cudm2OWipL0cb+Iyrhm8CJ3XS3LnqHab6oymnG3bcHTrqVlIq2UJLpUr6F1SM83O1jzPfMCpHjnikfX1yLfeV5fPKU9hyFfpRHkwx6Xf6JGJRrop95nXf+yhcRjOFvCMP1oaajDw7eeNCi3EIDDrAet7t8+9foKVbtk5TYoy+yXwVhTIMHIs2L+D9O5BGwKxXvgTWkBlL7fRiucyTJXij3YlcO1ejDHT3AOEOH/atU1V+VltCjam5RojRjaUeEFto5zLUIy
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR11MB5494.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a2d57f1-d91f-4cae-91cc-08d92698f3e7
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2021 14:07:41.7195 (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: KwNavLQd6Q1vjPzx3ZaVrD3CL23qE3anpM8CH0EveCNlyFzfwwHIHj7F9Of/nQgK
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4614
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/0WzZ-3gmopUDJfb9Yc7vIJBNdPA>
Subject: Re: [dhcwg] Yangdoctors early review of draft-ietf-dhc-dhcpv6-yang-19
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: Thu, 03 Jun 2021 14:07:57 -0000

Also, in the -20 there are some issues:

     typedef duid-llt {
       type duid-base {
         pattern '^0001' '0001'
           + '[0-9a-fA-F]{12,}';
       }
       description
         "DUID type 1, based on Link-Layer Address Plus Time
         (DUID-LLT). Constructed with a 2-byte hardware type assigned
         by IANA,  4-bytes containing the time the DUID is generated
         (represented in seconds since midnight (UTC), January 1, 2000,
         modulo 2^32), and a link-layer address. The address is encoded
         without separator characters. For example:

         +------+----+----------+--------------+
         | 0001 | 06 | 28490058 | 00005E005300 |
         +------+----+----------+--------------+

         This example includes the 2-octet DUID type of 1 (0001), the
         hardware type is 06 (IEEE Hardware Types) the creation
         time is 0x284900580 (constructed as described above). Finally,
         the link-layer address is 00005E005300 (EUI-48 address
         00-00-5E-00-53-00)";

Probably best if the hardware type (which is a 2-byte field) be written as 0006, not 06 (as 0001 is used for type).

Note also that bytes and octet seem to be mixed.  There are 5 uses of "byte" in the document and 16 uses of "octet"; I'd suggest replacing all "byte" with "octet".

Similarly, for duid-en, 0009 is used as vendor id when it should be 00000009 to indicate that it is a 4-octet field. (I think if you want to avoid leading 0's to not indicate the size of the field, you should do so consistently; otherwise use the leading 0s for hex values to indicate their size?)

And duid-ll has same issue with hardware type as duid-llt.

- Bernie

-----Original Message-----
From: t petch <ietfa@btconnect.com> 
Sent: Thursday, June 3, 2021 7:43 AM
To: ianfarrer@gmx.com
Cc: yang-doctors@ietf.org; draft-ietf-dhc-dhcpv6-yang.all@ietf.org; dhcwg@ietf.org
Subject: Re: [dhcwg] Yangdoctors early review of draft-ietf-dhc-dhcpv6-yang-19

----- Original Message -----
From: <ianfarrer@gmx.com>
Sent: Tuesday, June 01, 2021 5:48 PM

> Hi Acee,
>
> Thanks again for your review. My apologies for how long to work
through them all and prepare the update. I've just posted -20 which aims to address your comments.
>
> Please see inline below.
>
> Additionally in this version, there are some small errors corrected
(typos, incorrect regexs) and the example YANG modules have been renamed and have namespaces according to RFC847.

Ian

Piggybacking on your note to Acee...

When I saw the revised prefixes I thought 'I wonder if the IANA Considerations have been updated'!

The revision statement for the RFC-to-be needs the publication date, a change which the RFC Editor is now well used to, and needs to say "Initial Revision" in all the modules and  reference of "RFC XXXX: YANG Data Model for
DHCPv6 Configuration" i.e. the I-D current title; again, the RFC Editor knows what to do with XXXX.

The description of 'typedef duid-base' looks corrupt.

Tom Petch

> BR,
> Ian
>
> >> On 5. May 2021, at 23:32, Acee Lindem via Datatracker
<noreply@ietf.org> wrote:
> >>
> >> Reviewer: Acee Lindem
> >> Review result: On the Right Track
> >>
> >> Document: draft-ietf-dhc-dhcpv6-yang-19
> >> Reviewer: Acee Lindem
> >> Review Date: May 5, 2021
> >> Review Type: Early Review
> >> Intended Status: Standards Track
> >> Summary: On the right track - Issues and questions need to be
resolved.
> >>
> >> Modules: ietf-dhcpv6-server@2021-03-17.yang
> >>         ietf-dhcpv6-relay@2021-03-17.yang
> >>         ietf-dhcpv6-client@2021-03-17.yang
> >>         ietf-dhcpv6-common@2021-03-17.yang
> >>
> >> Tech Summary: The document contains the base configuration and
operational
> >>              YANG model for the DHCPv6 protocol. The basic
structure is
> >>              very good but the major issues need to be addressed
prior to WG
> >>              last call.
> >>
> >> Major Comments:
> >>
> >>    1. Should the DHCP server, relay, and client functions be
enabled by
> >>       default? It seems they are require specific configuration to
be
> >>       viable.
>
>
> [if - I've removed 'default enabled' from server and relay and left it 
> present for client, as discussed]
>
> >>
> >>    2. The threshold type in the ietf-dhcpv6-common is strange. It
is a
> >>       union with an enumeration to disable the threshold. Normally,
if
> >>       there is no threshold, you would simply not specify it.
However,
> >>       the data nodes of this type are mandatory. I'd make it a
simple
> >>       type and remove the mandatory designations for the data
nodes. Also,
> >>       the range should not start at 0% since this % makes no sense.
>
> [if - Removed enum and changed type to uint8 Removed 'mandatory true' 
> from the data nodes in the server module Changed range to 1..100]
>
> >>
> >>    3. There are examples of augmenting the ietf-dhcpv6-server
module but
> >>       no "Module Usage Examples" as specified in section 3.12 of
RFC 8407.
>
> [if - Added Appendix A with XML examples for all of the element 
> modules]
>
> >>
> >> Minor Comments:
> >>
> >>    1. While not required by RFC 8407, many YANG RFCs explcitly call
out
> >>       the interaction with imported YANG modules in a separate
section.
>
> [if - I've extended the description in the introduction to describe 
> interactions]
>
> >>
> >>    2. No sense in maintaining all the intermediate revisions in the
> >>       modules. Just update the one that is the initial version and
update
> >>       the date.
>
> [if - Removed]
>
> >>
> >>    3. The module prefixes are very descriptive but a bit long.
Given
> >>       the examples of augmentations, this will be especially true
for
> >>       DHCPv6 server augmentations. Perhaps, dhc6-serv, dhc6-rly,
and
> >>       dhc6-clnt would be better.
>
> [if - Changed. 'dhcpv6-common' has also been shortened to 'dhc6']
>
> >>
> >>    4. Can host-reservation prefixes overlap with holes? If so,
> >>       reserved-prefix may not be unique. If not, no problem.
>
> [if - For the DHCP server implementations that I am familiar with, the 
> prefixes will be checked when config is applied and any prefix 
> overlaps will be rejected as invalid.]
>
> >>
> >>    5. For nodes with patterns, describe what the pattern allows in
> >>       the description with an example or two. This applies to
> >>       link-address, duid-base, duid-llt, duid-en, duid-ll,
> >>       duid-unstructured, and sub-option-data.
>
> [if - added examples in the description fields]
> >>
> >>    6. With respect to link-address, what type of address is this?
If it is
> >>       an IPv6 link-local address, there is an ipv6-adddress type in
RFC 6021.
>
> [if - link-address should be a GUA. I've changed the type to
ipv6-address.]
>
> >>
> >> Nits:
> >>
> >>    1. IETF documents should use US English - not UK English. I've
> >>       changed in suggested edits.
>
> [if - Incoporated the proposed changes, see below]
> >>
> >>    2. Description format - Sometimes starting right have
"description"
> >>       and sometimes starting on the next line.
>
> [if - Moved description text to start on the next line throughout.]
>
> >>
> >>    3. sol-max-rt-option-group and inf-max-rt-option-group should
spell out
> >>       the words in the description rather than just repeating the
short
> >>       abreviations.
>
> [if - Changed]
>
> >>
> >>    4. In ietf-dhcpv6-client,  for ia_ta and ia_pd, spell our
> >>       acronyms in the descriptions rather than just repeating them
(which
> >>       is useless).Is "ia" "interface address"? Don't make the
reader
> >>       go to the DHCPv6 RFC to know what you mean. What is "ia_ta"?
>
> [if - Added expanded version in the description for each IA (e.g.
IA_PD (Identity
> Association for Prefix Delegation)).]
>
> [if - for the remaining diffs, I've incorporated them exactly as
suggested, with the
> Exception of one comment below:
>
> >> ***************
> >> *** 1216,1222 ****
> >>             path
"/dhcpv6-server/option-sets/option-set/option-set-id";
> >>           }
> >>           description "The ID field of relevant set of DHCPv6
options
> >> !            (option-set) to be provisioned to clients of this
> >>             network-range.";
> >>         }
> >>         leaf valid-lifetime {
> >> --- 1218,1224 ----
> >>             path
"/dhcpv6-server/option-sets/option-set/option-set-id";
> >>           }
> >>           description "The ID field of relevant set of DHCPv6
options
> >> !            (option-set) to be provisioned to clients of the using
> >>             network-range.";
> >>         }
> >>         leaf valid-lifetime {
>
> [if - I'm not sure if the intended change here is correct. I've 
> changed the wording to 'clients using the network-range.']
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> .
>
>