Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sat, 12 January 2019 00:54 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87279130E65; Fri, 11 Jan 2019 16:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 EnfncY-3v5NI; Fri, 11 Jan 2019 16:54:14 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760109.outbound.protection.outlook.com [40.107.76.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCC5129508; Fri, 11 Jan 2019 16:54:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cplQSBUb6C+KVo88AplI0Yx1FufcOHEXomkl+DDLWkM=; b=F2P/kjbiQwQgYzhML/wJCwffBuibZtd200wsK+omHTwPHrqGw/G5y4MeCFh1Z9T48OJnuF0PiqYCIUhbKw//EvjhWhQImCW1sNuZGATrOCxbt4BF0o7Zu0CFa4iDtFvICYc8YdmhW0Du+dM3p3V1LU2xSkerqCQIRP3Ua15nIV4=
Received: from SN6PR0102CA0023.prod.exchangelabs.com (2603:10b6:805:1::36) by SN6PR01MB4814.prod.exchangelabs.com (2603:10b6:805:d5::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.15; Sat, 12 Jan 2019 00:54:12 +0000
Received: from CO1NAM03FT031.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::205) by SN6PR0102CA0023.outlook.office365.com (2603:10b6:805:1::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.15 via Frontend Transport; Sat, 12 Jan 2019 00:54:12 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT031.mail.protection.outlook.com (10.152.80.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Sat, 12 Jan 2019 00:54:11 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0C0s6nm025943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Jan 2019 19:54:09 -0500
Date: Fri, 11 Jan 2019 18:54:06 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Kent Watsen <kwatsen@juniper.net>
CC: Adam Roach <adam@nostrum.com>, Dave Crocker <dcrocker@bbiw.net>, Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>, "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20190112005406.GU28515@kduck.mit.edu>
References: <35A436B3-5D57-4015-A51E-5F9A1E349D31@juniper.net> <DAC627AC-8453-41D2-B95C-BC25746E66C1@juniper.net> <cc5adc78-6751-fabf-03d2-e0c65f8a6c91@bbiw.net> <F844EDFB-3E15-47FB-A714-06363B996FC2@juniper.net> <42cddba1-9f59-f19f-176f-197f0c0c0c96@bbiw.net> <32cfe06c-8204-a63a-263d-cb5b30a7a2fc@nostrum.com> <20190110183444.GN28515@kduck.mit.edu> <0CDD631D-47A4-4478-A250-85603C653D23@juniper.net> <f9e64452-a2e1-fb18-80b1-b2c5fa9c54ac@nostrum.com> <3ABB2B04-DB2C-4E2C-86C7-40D83D440DFB@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3ABB2B04-DB2C-4E2C-86C7-40D83D440DFB@juniper.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(39860400002)(346002)(2980300002)(40224003)(51444003)(189003)(199004)(13464003)(53416004)(47776003)(75432002)(104016004)(53546011)(956004)(476003)(486006)(2906002)(2870700001)(88552002)(126002)(5660300001)(86362001)(6916009)(186003)(33656002)(26005)(106466001)(446003)(426003)(11346002)(336012)(8676002)(50466002)(6306002)(55016002)(23676004)(8936002)(1941001)(26826003)(229853002)(305945005)(478600001)(1076003)(66574012)(93886005)(6246003)(6666004)(4326008)(106002)(246002)(36906005)(54906003)(7696005)(58126008)(76176011)(966005)(14444005)(2486003)(356004)(786003)(316002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB4814; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT031; 1:OhLvm7Ipa6w+bXUDb+nc4zhEfzIGZ6vKyC6Ku0AzSG14af3cRjILoDTmx7nQgYEp1ZhEm47ho6xUWfiFtkSc6QIMsF9cmAqWcBIHv2j6tnyZBJXCtGNEhDvpxhCdjA3P
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 18a987a6-1c39-4145-99f6-08d67828779b
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB4814;
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4814; 3:vw2wgL0Z8oAQRaQuJrOfL3sluDnXFHL8HM9cNP449qm6gHYn3sS6b8SFWcfmm4RkJ+7Nc/Q6farjQz8ERNeygRfpxTZDdvpt+Ui2qryJNJZajbfLnEHDIHDXc6E7PEYDQ9OsU87DJiuxK23jfIspiZfqSO4j7KnD/C53yoAW9AXf5nmFyoQQbx6c9qFLtiGVxumzn29eK6/vAQNwHBibw4LTYjww8orwnoeMf5J97gyelV650Y3yqhq5c9jlHJ19H1j/sYR75XeLu1TZfpwH9w+R7dWBQVDWWMdeoyKRqXl4NM76NhrcrsQzq8a8NcxU+6WQbGkM0aXRohYbqIge5O+nEN1GC/y1xckVqH8WIs64s3N+Z9mz9XQgJt6dYDWO; 25:XCqsrMT8vz06d48tbW4ffV5YwJUGOHEF+4KeSg8wkCOob1870utsbhQs54tNv0ugggrHgnmAy3IrxtDUcaMWP1XTBW+Yig7uhmPQcDC0Uf/WodsSdtWcwxMIE3ZQ3CjJRg3F3y1XlEzJyCKx6/lxGLdkzuBgMro29COJgTMUyzmH8wu6LbvXRj5/aU98zmzzY3fC3YFBs3I9OVgaXs2D9xtVftjruIi7TP3aIm8Z1/m3V0/JRnYUAt7MmXujk6+bOBc12F2ZWsmoh3HhdWfUmSAud4t1dHPBtWVN22XRXFvvtkzej6a/Dc3XPaqv//jlA6ux++oPgHFKSMJe33UYTQ==
X-MS-TrafficTypeDiagnostic: SN6PR01MB4814:
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4814; 31:iKu6xT9GGsEIc5cWqOYDuNcJWwkR1FGBWMcW5MrwhSnCHUENCPtnbeG4mJEfto39rs6OmRtbbk5Ks8s9f5aDWBy01nsF6q2EjxgjZtO2x0Tvx5AFjcHCAKStZ/7vp+lpV3PalsnzrhcgHB0Pp1cF6bB2aA6KxLFAEN3oMwYQTQEr5DSIti2Soh1C26BOWcRVQLYcBmjufsh8pU6WNsvp4Y28jGC8gBSNTzG299R3uRg=; 20:MzSxP0Fi27G5FC0ZVNHL729KDF+nZHUFfU03/zI3TPsSzrSfBBpxOvo4UOQrnnaILkVJjJL+VetLbOwZRNX7DUQzz+oRh9ZbSR/7wu+ONnLGbsLoULuZLk/r7WGVyKZQstwMQJk0Ip4o+dMOI+JB9/dKOkXjNpTPUlRGdO3YZVoA96/R619FXRU1daawujM31neIWpvqcvz+0EgVrM+sTZkLzZpyoAthxFhss1629GNRJiWlTFsV1pAFubxyl5ACh2aIVDBOlW23IAoY81x5VLJQ5BA0fdr+YjrRAW2B4o3Qr/V8axrhsDxpoUvsKIQajP20WU4o6b7ZZfY6/9sVdn4men3G5HQb3yAnBulnWzL/G6mr5RurYinHc1D050KOcGkZ6v8kO8jI+kw1xktxGaB4u3mS8wFw7D1efK6armMPvT1BDG5B8NzTPsYKR+Baz1km29Ee2zcABN4RtnZZkQUifyf9vLsLBrsPqkzG0CCfvCGbNBIEbLSFBXT9kLS+d6CmVUzBaprPBawLfhqk6btWRYsTxgZc5aeCAZeMf8uhKUP9Ly8cGqcN4Vv8hPYyAdT65gTNQDwlA/XqXTRHWiuDe7JWMas8pmox5XOrkj0=
X-Microsoft-Antispam-PRVS: <SN6PR01MB48144ABB597792F33E551251A0860@SN6PR01MB4814.prod.exchangelabs.com>
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4814; 4:UmFB5mqzgzV5Ij+zZwEVn0P9y1oSFHu2KhcuZmAxYIV9HnDH/myRJUkT25tzCnTlp6UAgDXjXpoVNjjjIkB+S60hM8UH5iE937SATDAo1Q+gHq9eJK9dr6SFhDdAjd0yRxisQqGrnxS3jjWU3cXlFOfeFqWY6O5Hq1ZxxmTkIuRiyvWul3KM/Zkw3z4sdI6VSRFoUUQSH6bRVsBy/f9kpA55eoHZcHu/Kzf/ICXtQmotiFryO99nxytD1VPlClh5oe1KWKiIArMB8QD7D/ppONM317xxZPczYlGJRpzaswQ=
X-Forefront-PRVS: 0915875B28
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjZQUjAxTUI0ODE0OzIzOmh6NlFHek5yZFV2MDlmbGZmU0NMTG1kTmh6?= =?utf-8?B?b3c1akp4b3lJMnVUMmFKUkVzMXBna2hrUVIzOFBPVXRTNE1hUVJGMHllVGRj?= =?utf-8?B?SVpDaHo4dE9rc0drWVFnaFd1REhoeWxMaVBUSHprQUdocU5ONHdNNFBQY2Fl?= =?utf-8?B?ck1nWEhtVmwwRG0vWUlPOGR4US9obXRHdzhYYk1LQy95dUhORkRCQ2szTGRK?= =?utf-8?B?RjJYbU5YKzU4c1V4a0hjSU1IU3V2am10OUMrRFBmL0kyUm02Wi9qem5RZUdw?= =?utf-8?B?SVV0U3JkdTk4YzBhOFgrSDhLTGdQU3ZUbHhuRHJ2M2Z0dDBQSDlvV3dSc0JT?= =?utf-8?B?aXFPTldmRUVVT3l5M3I4aDV0YTVvdUJuaXU1OE8zek9Mb3diUzRtSksrcHZH?= =?utf-8?B?RmJ3YytvdUQwNDNvWFp6SThYM2loU0ZSdE1NSTBnd0lvUitjWm93NXJNUHFN?= =?utf-8?B?YzZhdVBTRTEya2lmS3UyZFFyQTd2MlIya1Q5WXQxOU9hZWhkL096MlR6M2Uy?= =?utf-8?B?OVEwWnVNS1pnSkd2SkVOZDM5OU5BM2dwVUtFZHpBSVRCTDZ3Q2UvaFJvZklE?= =?utf-8?B?bUZ6bXZFckFtMklSQ3h5dlNyYXBaQzkxU1RLQXVHZDlmN1ZQZEFCTTZrSDlh?= =?utf-8?B?RUIzNjE5b0ljOUc0VVdrc3N2aDUwWUZaMjUxZjNYNHkxeGNpUDB6RS9MeUY0?= =?utf-8?B?MTBDUWpOOG1EdEw5dDZmYW1xTmg0dnNWejRtb2lMOEtxamNuMHlBSzBBZXg4?= =?utf-8?B?VVI4M3d3Q3c4RG5ieUVPM1psa2JpWmNwV1h6SEZiZWQzcTgvaEx3WFdKUVNk?= =?utf-8?B?Rm1zQUE0Vk9CRHRMdkxRVWdMNlpFUjZmSmwxWjZzb2lJT0FhblpJK2ZHaUFx?= =?utf-8?B?K2Z0SGxHMmNJQkQ3T1htRVA0QnhQRWdWb3o4akVtaHhCR2RDYXJON2prM2s3?= =?utf-8?B?N1lYajhIenl0T0JjTlAzcmpnVWJlUDVOS2U3cm5FKzJiRU5qZ0t5VzFBZ0Zl?= =?utf-8?B?Ri9jY09odWE4TkZkeVhnZVUxM2QybGl3S25EbXdFZGs1OXdxc2JlZnprNzh3?= =?utf-8?B?WmYxclQ4ak8rNS9OMC9pWXdPek9oY0FvZVkvSHE5M2VLYlZKT3BDWUhuQmhq?= =?utf-8?B?R1ZxQWtjWUYrek5uTWt3VEZ6dHhldTlLMkJzSk85cHFQK0N5S1NMZ1I2V3k2?= =?utf-8?B?OVg5cG1yYnllcjVGNGZSM2pLWW94SWJNblNkc0kyY052WDIwYmdkQWlqUHE2?= =?utf-8?B?VjFkMHJYUHJ1MHFYdGVkWjNzakhmeEY3Vm44T0Z3VWFwMGVheUk2Qm1BenB3?= =?utf-8?B?Nmkra25LMWFiTWVTZEVsdVlKdmNtcExHQUlYT0NHNTM5bisyZk90aFNZV0pD?= =?utf-8?B?STB1TFhOK05mZ3lsVzNEMHBPNytSUWJnVE9ubFpHSzRnSUJUOFVsdkJHNDdq?= =?utf-8?B?d1diK1ZURGRCOWZIN3ovMWFmdFJzYW8yQWdWN3NocldxcXpnVnZ1Y1NvUkxI?= =?utf-8?B?RUZaK2lZbmFwUFNad1IvYmhPeWpTaXVDdEhrM21OR2lhR25XZmllbnp6dGha?= =?utf-8?B?MUM5MnVONWxEN2VVQVAxZi9YL0VoZlJZdjFaVWJSWHVXR0paSHVxYlR3ZEwx?= =?utf-8?B?YkpOamo0R3dtb3VBOXlSYVlUZDVUZzVwODRvUjhwS2pERFlvbmN0K0FxY2dW?= =?utf-8?B?cEFWWk1zN0YrL3crSDc2dDZTalRzM0FsU2tPMkNIWXFhZmxab3A3WFFpZ0JR?= =?utf-8?B?azBXZ1dRbnZkSFZhOU4remIzNGEvKzBhaUc0L1hlL3lLQStMV1dXdG90V2N6?= =?utf-8?B?WTRUUXBjTWFwRDBhZ2Roa0FYbWRyUVAzVzBwY3Z0ZDQ3Y00yUGlMZEgzbjQ1?= =?utf-8?Q?kqsC7aCVoPr2l0JaINeTj2oCjWLNx+3W?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: giD+D/MdJFJTyYLkF1oOA+skAzRXk4nW5UxqtNWwUk1yTtkAVNr9wTvm9bnV84TqIlj7NOLhJTe4q7iScPfUNO32P5wGgW561WF5IcqB6i5gzoKlAr7jNOu+pxM7tETLOqrlUH+ZFZcQnBLY0qgOR+OJ7Yn/5vdie0PnFaK1HicAuRI4qh9cfW4BeH5NjclRHy8P1dGJMAl2lrsePsmZBZcIZ//xUsGLdNXM+0UcuxpbWt0HktQVdG1dvFsfMdHDgLT45g1qlTa+GbZoR0aiLEnYhf9ctbOy16QMxLIkKzvgGpNQA//nGYzpnss5XU11xQqqiVA92+qHERbg4I8B2ZZ/bNTk3IadVE6/+9/TG9q4nBkKgwQO5tjEQLdQ374Swm8L/ItoF6g9oHsL/hYJ1iVa/A++X2isLpUa1Bgjjq8=
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4814; 6:EmWy3S8MxawnzGekmyJEm1dGwL2JGJ74DGL1AwVgdXw7HqwHMDUcjbGHiTRXPM5PUN48TymM0kOCPerW1YJ//770Z+VDa9lYLN6WHBXM+Ly7Fp7GlJVapR5KhI59cUdjo7fR9wvIr3wNvWiP3Njq2mzJm0PefmpwTHGL4Ve5ogCiiIUyGpQoFv/OHxwO6jx1e1U3tRzd/fuzH+ffW5N/+dYBSaUq4YzDRq7qSHyECzpUPpCjcuZZJBWyyb3Av/4mCMB/y+dvOJjtdVM+tGB99TGwUQVKQrY3gLC1e/7JIihsn2+o9pBFIeok7kkM54/Uxoa6SHOFKMHow2UiP52+zVKGBFVIWYgPd83RJbN/RHWnqX9FgqVj8EYVGzFIym2lciZj+PbqZyledj5ivFFZJ2/TiMLJG4+XIZwhiorzOD2QlebA4kVyUg7mKCnbMzTsG/ZblTYJcgrgQAu3zYPVlg==; 5:jtfZW9nxXFjBeMTZBvOgzIH9fAylXcfg1lvm8rqsabB8Sg5AA8aZuBBniPNGQRovHwGOxWoU+/R7NtF5c5pU5aD3a8tH8ymYBx2BA3dxsgz7elEmPcasDMqUQ3FJyQ3ESZ+RrYiimAJDb+mObyAsNPncq1ro2XVfcFmwMeXemWZYr0SWCN8jOtASAXvKqSv+aMOguGmeFfb+t3g7LsleqQ==; 7:BUv+qXPyPVsfMXEZPgp1NvTSMvo+g6PM+qgdJ3FxFlsFwr0M1MsJthW2npDOI3mrmBZGEFt5j/6auQHg6kSUpMk0aW4o5rmrSI7Ht3Rycy7aDmCN4jymcf7PITzzDaeOTveFiaq5ty/PDdZNm8eklg==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2019 00:54:11.5214 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 18a987a6-1c39-4145-99f6-08d67828779b
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB4814
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/K5beIaX6WI0h2RakpMC_viAgNSM>
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Jan 2019 00:54:18 -0000

On Fri, Jan 11, 2019 at 11:10:48PM +0000, Kent Watsen wrote:
> Hi Adam, Benjamin, and Dave,
> 
>   I just posted -28 to address this last COMMENT.
>   Please review to see how it can be improved.
> 
>   The draft no longer says it uses DNS-SD and it
>   now registers "_sztp" in DNS Underscore Global
>   Scoped Entry Registry.
>   
>   Here's a direct link to updated/new sections:
>    - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-4.2
>    - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-10.7

Thanks, this seems to be a fine resolution of the issues.
While looking at the diff, I managed to confuse myself as to where it is
specified how the device serial number is encoded in the identity
certificate (so that we are confident that that encoding is usable as a
DNS label).  Am I correct in assuming that that's in 802.1AR?  (Also, the
URL in the -28 gave me a 404, and I ended up at
https://standards.ieee.org/standard/802_1AR-2018.html by searching.)

-Benjamin

> 
> Adam,
> 
>   I added text about this draft not using DNS-SD.
> 
>   Also, after reviewing RFC6763, copied over the 
>   recommendation that mDNS SRV responses also 
>   include address (A and AAAA) records.  This was
>   the only thing I can find of merit after searching
>   for both the strings "multicast" and "mdns".  Was
>   there something else you had in mind?
> 
> 
> Thanks,
> Kent
> 
> 
> -----Original Message-----
> From: Adam Roach <adam@nostrum.com>;
> Date: Thursday, January 10, 2019 at 5:00 PM
> To: Kent Watsen <kwatsen@juniper.net>;, Benjamin Kaduk <kaduk@mit.edu>;
> Cc: Dave Crocker <dcrocker@bbiw.net>;, Alexey Melnikov <aamelnikov@fastmail.fm>;, The IESG <iesg@ietf.org>;, "draft-ietf-netconf-zerotouch@ietf.org"; <draft-ietf-netconf-zerotouch@ietf.org>;, "netconf-chairs@ietf.org"; <netconf-chairs@ietf.org>;, NETCONF Working Group <netconf@ietf.org>;
> Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
> 
> On 1/10/19 2:09 PM, Kent Watsen wrote:
> >>> I don't think this is right. Draft-ietf-netconf-zerotouch is explicitly
> >>> using DNS-SD procedures [1]. In turn, DNS-SD absolutely mandates the
> >>> presence of both SRV and TXT records with the same name [2]. So the
> >>> names need to match.
> >> Whoops, that's totally an error on my part.  If we're explicitly doing
> >> DNS-SD, then there's "nothing to see here".
> >>
> >> Sorry for missing that.
> > No, wait, I think that the draft's stating that it uses DNS-SD procedures
> > may be in error.  It might be more correct to say that it uses DNS in the
> > following two separate/distinct ways (in order of device-processing):
> >
> >     1) A lookup for device-specific data (for the TXT RRs)
> >
> >        Currently is this:<serial-number>._sztp._tcp.example.com
> >        But maybe should be: <serial-number>._sztp.example.com ???
> >
> >        Returns TXT records (no SRV records) supplying bootstrapping
> >        data.
> 
> 
> Aha! Okay, I had missed this in my read of the zeroconf document. I 
> think I just saw "DNS-SD" and made certain assumptions. If this is the 
> procedure you've specced out, then you can't use a TXT record with the 
> _tcp global underscored name (since its use has to be consistent with 
> the procedures spelled out in RFC 6763). The use of 
> <serial-number>._zrtp.example.com would be fine, and would call for a 
> registration in the attrleaf registry.
> 
> 
> >        Only if this lookup fails (not in addition to), then the
> >        device moves to (2), in conflict with RFC 6763 §6.3 says:
> >
> >          "DNS-SD uses DNS TXT records to store arbitrary key/value pairs
> >           conveying *additional* information about the named service."
> >          (emphasis mine)
> >
> >
> >     2) A traditional SRV lookup (per RFC 2782, not DNS-SD, right?)
> >
> >        Example: _szpt._tcp.example.com
> >
> >        Returns SRV records (no TXT or PTR records) supplying
> >        traditional service info (address, port, priority, weight).
> 
> 
> Kind of? The issue here is that 2782 uses normal DNS lookup procedures, 
> while zerotouch uses mDNS lookup procedures (if I've read things 
> correctly). Doing mDNS with SRV records using _tcp but *not* using 
> DNS-SD ends up stepping on DNS-SD's toes, at least a little bit. I 
> suppose as long as "szpt" is registered in the service table (which is 
> required for 2782 use), there's no practical risk of collisions.
> 
> 
> >        FWIW, technically, SZTP defines an application-level protocol
> >        on top of RESTCONF, which is on top of HTTPS, but I don't
> >        think anyone is suggesting this:
> >
> >            _sztp._restconf._http._tls._tcp.example.com   ;)
> 
> 
> I hate to admit that there's (kind of) precedent there, but it's *bad* 
> precedent resulting from a misreading of 2782, and not something I'd 
> encourage. :)
> 
> <snip>
> 
> 
> > Note that the WG didn't know about draft-ietf-dnsop-attrleaf until just
> > now in the IESG review.  We were shoe-horning in DNS-SD as it the closest
> > fit.  But now that draft-ietf-dnsop-attrleaf is brought to our attention,
> > perhaps it makes more sense to define a top-level "_sztp" attribute for
> > the device-specific bootstrapping data?
> 
> 
> FWIW, before attrleaf, the accepted approach was to land-grab a label 
> and naïvely hope that no one ever tried to grab the same label twice. In 
> any case, even with attrleaf (and based on your clarifications above), I 
> think the <serial-number>._sztp.example.com formulation for TXT is 
> correct. With attrleaf, it's even more clearly so.
> 
> All of that said, you'll need to put additional language in here about 
> using SRV with mDNS, but *NOT* using DNS-SD procedures. I'd advise 
> copying and modifying appropriate passages from DNS-SD as the basis for 
> such language. Also, please be certain to be very clear about the 
> relationship between this mechanism and DNS-SD.
> 
> /a
> 
>