Re: [Gen-art] [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
t.petch <ietfc@btconnect.com> Sat, 30 July 2016 11:48 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E2F12B04B; Sat, 30 Jul 2016 04:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 8vPuaKsC5tNZ; Sat, 30 Jul 2016 04:48:21 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0103.outbound.protection.outlook.com [104.47.0.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D0212D1E3; Sat, 30 Jul 2016 04:48:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KWBH8riUgbtvCntEY+Fo33Om/5/f03GSI5KkFEIcZN8=; b=QxmY0E/2Sr1jkjMxfyYONxm4Y/VkR84irl34rQE/+SMpSAh+lNqWBgYEFG6hxinUbKj5F+mqRzrK9rL9RTmFoP48csiV6n7BQJsjHA7MuVt5E3cFiu/hkXhRhHEo2dcq+amr+yvvOfCZI338Kp9s8FTS9oY8CZBTN1ErRdnKSZo=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
Received: from pc6 (31.50.86.164) by VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sat, 30 Jul 2016 11:48:15 +0000
Message-ID: <00bc01d1ea57$e7889f80$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Andy Bierman <andy@yumaworks.com>, Robert Sparks <rjsparks@nostrum.com>
References: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com> <CABCOCHSEG0VyWvP=oSFDD8kkWR=+-5ACV=1Es=2WfbjYhaV1UQ@mail.gmail.com> <c24eced8-bc26-bb1e-2d4c-fb366cc12f8d@nostrum.com>
Date: Sat, 30 Jul 2016 12:45:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [31.50.86.164]
X-ClientProxiedBy: HE1PR05CA0011.eurprd05.prod.outlook.com (10.162.181.21) To VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149)
X-MS-Office365-Filtering-Correlation-Id: 5d26ed63-9202-43df-aed7-08d3b86f64c9
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 2:wo8RA6BRcJrxZpsqoKq6vKhRPB0flOuQptH5NaoE8IfDFL/d7RQj68XrDPaCDNZodsenQBN8+E+sCN2kSrFAYAVLuM//q5n7p+4XWXInRIkS8f4+jTk5OnnDXNT6pq2tXEPHRRoM1L7S/3drf+L57ueAgiVHWaqbFIzB+sTlO0A1gHJ+CWfsjZih70oygubt; 3:YuOTkUjp4H16NKm5OHLNe2xXCWf9lWRQSEWOMB7Ruv3R+2va7ve8y9b+87XpIUF22faWTKMXvw5WGrILQYz6SE9SweftGzdbXjYqiJR5GC7kbDopsZ+Q5evSMTif6QvM
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1631;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 25:Tb5D9ydxuMX/HHF+2lPhKR1VRN0SY1Oc64hSxJlwc1HzOe0oCTJcU0dlLZ0bVyqhcJY57R2n5aXP813DsrXjwj+l1fbVx9pPSlmrNp/g1bU/jklH+xRpQa2/7JjIbqYVkaPIGi61pf59NejrJJTYcA+EYgMtpQlKPNTNcgJy9ZP/7i+7DdGeyWVBD2bp2mzYn2yNQr6H3haK2YSt0tbtnQ33uO1CLcVSZAVa05biutZuqK/3N31azZ5HynI8KjI9jXjEKNazoL3pen0OCr+f40JRp5Y/cnDUr8gZYRb0HBBQ1BrIHPVYJTKZOCkkz4vNcpF+uObTpEjKX9RKYFtm9qAAKXjzpt7FQKxM65rD9lSI/JwsNaoVsLuPrpIAr+WAceMBuUHNEgHnQLeTYP8eFzzTGHRdzcyY+coFaz7+lzJ4+tjNnTnh+QMyLEtC53zCl5IttfT/+1xuB2aveYorPCN+9WIpqwoqgykZEzKjdCs/lHrk4ULNUt2vUZKbvro6uZDZV3Y5UslZvlwuTjqVGi2Y0wYcz6CyeL4M1g5s3r203B/4WYonE0HQgQoKrdp9Shhb34Z2XUmPrLir9hzDjOpG0L/WiwBEx4g10yc3KYbHTs0CADCgbFQQAfiUxgvj2ESgWh0asAHzWxtRnXFYRNNcA6Izt/jdXYejmgnZZobhKjk4fRjcrF9/4mkWD5gkzJrxto6B9F34rPmlGb+4uFmf5wWSyj6khqu1lxsR24nkc2JVT5HRvISWeZE+w1d8YmhJbGCUEBkYjmpjLs12V2UzGxA8o0kHwwd0UgMNxI8r3DiEE9BbVaeUxwf/qv/zuzWzCMomyVAMKLHDh7qdH0TqW9SPpHR9o7GvgLUJKSA=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 31:755j+NuUAaLzyMGLGyHYVfIlBA8wqPyG7IIpvGJMDWTRB6mubPZr7ZrebSoI+QlNj7x5IQwzlu3mdf+HbCv0hqUaT9u/2zJVanKW1nLffw2ChYO36hBtHXGT+EgwE5tXra3FDl8H3ndyVylvcc8TL0tvf2d9vayMxkg7jvI5ODWvvKXats65stdfTEMTxQrFx59pvpnRLg2wpDCbmvYbyA==; 4:XwRqrzo8a8/OQNGpVEUvjy0xY3v5b3BwnWmBnMYRzI/qHPTDCafqkhTMMFX7eK6dGZ24nTHrtwT7Ei3++7vrOJYwkWdKUyZ5blBPGf5DRSf9iqY8RS8/YImoaoPcezeU1JAHcfSaSgrmbuACPpFYhlL11A9OsUhQXhM8L4/34BTweW/QAT4Ful1gFJJttWvmFZ/DCYPrGEI8VzygyTNLsciAWox1U0IOuMcfCy0bDlvZdt0J3ZE/8R/kqztVJlF46AUT5cTf1JKxofbBLt1OIsNooPZosUrXTS0lPlI8woQtpJHD0vlY7LKP8mTJdPBSGfqncVBlvN8PEqUOlJClpudcvbzcpoe8Cd7wkv4Lzg1jUdLvIPElBxdKBeOlwTkV8iXJ1rXbTwj49ChJV329wXPlmlWm1trHZCiusoJkDtMfswSBr/WAe4O04b/tzq6E1ps4ipV1asWQXeoMzGlx03mpV+KDPZGR3bHv7fpjeiU=
X-Microsoft-Antispam-PRVS: <VI1PR07MB16319D68A83A933A536C99D6A0020@VI1PR07MB1631.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(788757137089);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR07MB1631; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1631;
X-Forefront-PRVS: 001968DD50
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(13464003)(199003)(377454003)(189002)(81156014)(9686002)(7736002)(8676002)(68736007)(7846002)(230783001)(44716002)(97736004)(189998001)(81166006)(116806002)(62236002)(5001770100001)(50226002)(50466002)(101416001)(19580395003)(106356001)(66066001)(15975445007)(61296003)(76176999)(42186005)(14496001)(33646002)(1556002)(3846002)(44736004)(92566002)(86362001)(47776003)(1456003)(50986999)(6116002)(77096005)(305945005)(4326007)(2906002)(19580405001)(23676002)(84392002)(81686999)(105586002)(586003)(81816999)(230700001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1631; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;VI1PR07MB1631;23:3r1+HYmaiFCFR9J+7XWcY4W/2mM1F1OX2rH3NJ3tUCx3XMY8s/C8AK457RMnDprIvE6lLMexPgOSEOCJko5vfX0gIjb3qQI+IzgftX60TJnvlyXuwUBT5mEyE8Cznp5xpSS4Wkr7bd/ptV8wluTkrMnTd3/ySz6QRDJZyzwWLGRDMbmnU+7rDOjVGdSd89DLArY2sPRNk0CxFLzSf7i8M4mAqQbfUtVrI2e6VgfdswHkuu5i2WtiKpT7omlz+k5vbMimv6KYvbiCv43GnceI5VlDxFPODQ0UGJy3cm6DrPbLPx3kilfgBPPHho7sRX8Xh5FCG2hmDBT2BjWPcy9CWY0U53KBj3+YUaDG6mnaStW9u3fiiGfct0KY0+ikxgWuDu4Zdly3H/7zgsM8kuTTQLYmbJz8VFjMLxsB0QhlnFxSnfVubC6aIn8i1gt+6jJV/oidlb+RuTc3+Kfte8Urh3nkse+tRuY9129/d+KuWT/1L4MfeYzfFaV2si1MAAvgDCbsuiP+dWMpqFsJeiTHkeC3o7SQH2z86JZBTO4WneBGkZwBdWZVmIfsdh/TTV0JKr7ASqdjzgImBqGohXyfKROKId6tnYGqgUpP1KKGRwDjqGRVvg3VzSrtTHJbL6+3EDp7nK/u2+ROT8lKVwTMS047NTdG5Ilv6rLSub5ErIZ/D5jFL1p2OuDlFpJC46q6DEUsp9z+xHS2ydnOu/sBh0a6ji/8NcdBKvIuBLL1s4GP1mb47gn3w2OwOUfEB7GkujkGbrQKpNPReaIVJuDJUwW4ZwPaFMQGoMjEwLC2xvoOhyDUfkbc/b9yDGGAau6Rvg+1NyUqQaMKAvFXAyGQ42bphF9Apvjt5PoIzs9gVBeXteoEdFbtJtERUZMqiInf2RAT53T1q19mDqjr1W+POuHHlw7kQDubUIHr2c24rs23v49ULdu3IUe4sMxRov8PqiNZhnurcGLNhg9rzjTQUdv0cuQgoNv2VqEluN8GWX41vzsxxNMR5x1We45/aAqUj9a6M0IC4H6Nk/whMaaUcY0B+qsl3cIFLtEMqNlvEqFksWHYrnCmxzIU87fNGRI3eaMgGcYgNV6TUVJmxNfONyixF2zoUv1bLGPPlSw30orhEZ9PJUMQrlq6AoU0FKXN9PpIabAfcmHUdxz/sBP1jT4gy+jZys+NxVVCgUWgxnnufeWP1JRslCuGsvanhLQSCWVYy+mK+5fK2GVWxw3r3pvz65ZuUdkJFPyKjcv+3Rvm7tSC7qGvkqQvpgPkHoxVqOVIn9JqY/TXGF0d0GNnGpRnB0BIhJ9pWjj+vWkOP6Qdnb9zu0byGgGhJQqtzbYRLRwsoPtTHwJCja8pxmRLTjC9P1s9mp5zl1RVGhj4e34qav1fSV7wW/vKaoEffo/U
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 6:QTQ3BCjjb5UYaaHJA2XdbZNraTHQI53s7q9wzXwzV3MmdnQegn4JaZUTPAoN4kIpcvw8pFSVIFo/663e+Bm1GpFKp716i8pveU2+TBgSadR2rwJYbdMcVxWT/sJTFQs92gBfXSm7SuyENWD8+J1uYFffnQCbwak2fPEpheMPfF6w5AZ2/1UOlICXq/782TL8XJinIte6pXnQq0/8MDlVsdEe77KsuDB53hx0NkS6sJgFKIHbOigz0/hRVzdoHTCKUdxPPFpb8TKDvHkEgN+2Ky4kPH4trgmDxH9XhHEZ1xg=; 5:gowqB507g0mLsiQBn5O/jFUkG4cJjprBTftaG9UwgYaj/2NFHL2figrOKRQComz9Liz248+ge0XtZN8mZgjIx43uZH5LrBfgKDotdzhIUU1u0vvciTveapVDACT5bb9KtP+ekQWIT4POxBYh5rsF8w==; 24:SEDzAFKaarAlZFHzHmtfoGn3bGPbR8hmwplRN21IrDrOM+q4mYiH0n58bcL1qYVAd1kqthpZpz1BYKRNMDTMuLf0R/8ud5sBrWNnUgWiGs8=; 7:90IYJYtxGqkobzrl9NR90wV5lx1GLEkYwCclRmKKfrizhQE9+dOTYxG8yHoLUxuRZFleSLozEgXwIP8POJxVdFmUOd1Tj4tGOXEdzF+X+G8qGM65oslOyBZuSqFYTZn6CZnGclc8pUKRc9dsR1ng0ppDJ9UbYVLILU5PhP8s4AfoS1zH3+uAB7q1XlQxS4kRFLTKcVKDmywLVnQpS8HgwklmAMBE3cX7a7XAKAP4P8cvRhltdH6Rha5K4m/kkEDn
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2016 11:48:15.1213 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1631
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/cLljrcIrkDG-ujNaHxLXT6l6Ti0>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-netconf-restconf.all@ietf.org, ietf@ietf.org, Netconf <netconf@ietf.org>
Subject: Re: [Gen-art] [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jul 2016 11:48:24 -0000
Robert Picking up on the point about terminating the connection when a certificate validation fails, this is a straight lift from 'Netconf over TLS', RFC7589, where the reference is also in Section 4 which makes it clear (to me:-) that the reference is to how the connection is terminated, as per RFC5246 s.7.2.1, and nothing to do with the certificate validation, which is as per RFC5280. Tom Petch ----- Original Message ----- From: "Robert Sparks" <rjsparks@nostrum.com> To: "Andy Bierman" <andy@yumaworks.com> Cc: "General Area Review Team" <gen-art@ietf.org>; <draft-ietf-netconf-restconf.all@ietf.org>; <ietf@ietf.org>; "Netconf" <netconf@ietf.org> Sent: Friday, July 29, 2016 9:47 PM Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15 > > > On 7/29/16 3:36 PM, Andy Bierman wrote: > > Hi, > > > > I will add this review to the list. > > A new version in in progress. > > Some comments inline > > > > > > On Fri, Jul 29, 2016 at 1:11 PM, Robert Sparks <rjsparks@nostrum.com > > <mailto:rjsparks@nostrum.com>> wrote: > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > > > Document: draft-ietf-netconf-restconf-15 > > Reviewer: Robert Sparks > > Review Date: 28Jul2016 > > IETF LC End Date: 3Aug2016 > > IESG Telechat date: not yet scheduled > > > > Summary: > > > > Major issues: > > > > * I am not finding any discussion in the Security Considerations > > or in the text around what a server's options are if a client is > > asking it to keep more state than it is willing or capable of > > holding. The possible values of the "depth" query parameter > > (particularly "unbounded") points out that a misconfigured or > > compromised client might start creating arbitrarily deep trees. > > Should a server have the ability to say no? > > > > > > > > I guess we need more text somewhere explaining the "depth" parameter is > > a retrieval filter. > I got that. It's existence, however, caused me to think about the fact > that what is stored at the server can be arbitrarily deep. Clients using > POST can build trees that are arbitrarily deep, with bits at the node > that are arbitrarily large (subject to the constraints the YANG models > put on the node). There should be some discussion acknowledging that > this can happen, and discussion of what the server can do if some client > starts asking it to store more than it is willing to store. > > It is not used to create anything in the server. > > The server does not maintain any state except during the processing of > > the retrieval request > > > > > > * The third paragraph of 3.7 paraphrases to "SHOULD NOT delete > > more than one instance unless a proprietary query parameter says > > it's ok". This isn't really helpful in a specification. > > Proprietary things are proprietary. The SHOULD NOT already allows > > proprietary things to do something different without trainwrecking > > the protocol. Please just delete the 2nd and 3rd sentence from the > > paragraph. > > > > > > OK > > > > > > * Section 2.3 says "If X.509 certificate path validation fails and > > the presented X.509 certificate does not match a locally > > configured certificate fingerprint, the connection MUST be > > terminated as defined in [RFC5246]." RFC5246 doesn't really talk > > about certificate validation, and it certainly doesn't say "the > > connection MUST be terminated" when certificates fail to validate. > > What are you trying to point to in RFC5246 here? Should you be > > pointing somewhere else? (It's perfectly reasonable for the > > document to reference RFC5246, and it does so elsewhere without > > problem). > > > > > > > > Please suggest replacement text if we are citing the wrong RFC. > > I will ask Kent to look into this issue > > > > > > Minor issues: > > > > * "A server MUST support XML or JSON encoding." is ambiguous. (2nd > > paragraph of 5.2). Did you mean the server MUST support at least > > one of XML or JSON but not necessarily both? I think you really > > intended that the server support BOTH types of encoding. > > > > > > No -- it will be clarified that the server must support at least 1 of > > the 2 > > > > > > * I _think_ I can infer that PUT can't be used with datastore > > resources. Section 3.4 only speaks of POST and PATCH. Section 4.5 > > speaks about "target data resource" and is silent about datastore > > resources. If I've understood the intent, please be explicit about > > datastore resources in 4.5. If I've misunderstood then more > > clarity is needed in both 3.4 and 4.5. > > > > > > The next draft will be clarified to allow PUT on a datastore resource > Hrmm - that makes me less comfortable that you are actually aligned with > 7231. It may just be that you need to be more precise with your > description, but per 7231, PUT never creates resources - it can create > or replace the state of a resource. > > > > * In 3.5.3.1 you restrict identifiers with "MUST NOT start with > > 'xml' (or any case variant of that string). Please call out why > > (or point to an existing document that explains why). > > > > > > OK > > > > > > * The text in 5.3 about access control interacting with caching > > (added based on my early review I think) doesn't mesh well with > > paragraph 3 of section 5.5. There you tell the client to use Etag > > and Last-Modified, but in 5.3 you say it won't work reliably when > > access permissions change. At the very least 5.5 should point back > > into the paragraph in 5.3. > > > > Nits/editorial comments: > > > > * Introduction, 4th paragraph - please change "MAY provide" to > > "provides". Section 3.6 explains the cases where there is choice > > in what to provide. > > > > > > * Section 2.3 paragraphs 1 and 2. There is edit-itis here left (I > > suspect) from working in matching fingerprints. Consider combining > > and simplifying these two paragraphs after improving the reference > > issue called out above. > > > > * Section 4 says "Access control mechanisms MUST be used to > > limit..." This is not a good use of a 2119 MUST. I suggest > > replacing "MUST be" with "are". The subsequent text already > > captures the actual normative requirements on the server. > > > > * Section 12 says "this protocol SHOULD be implemented carefully". > > That is not a good use of a 2119 SHOULD. It is not a protocol > > requirement. I suggest reformulating this into something like > > "There are many patterns of attack that have been observed through > > operational practice with existing management interfaces. It would > > be wise for implementers to research them, and take them into > > account when implementing this protocol." It would be far better > > to provide a pointer to where the implementer should start this > > research. > > > > * (micronit) Lots of examples are internally inconsistent wrt > > dates. For instance, look at the 200 OK in section 3.3.3 - it says > > that back in 2012, a server returned something talking about a > > library versioned in 2016. > > > > > > > > Andy > > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >
- Re: [Gen-art] Gen-art LC review: draft-ietf-netco… Robert Sparks
- Re: [Gen-art] [Netconf] Gen-art LC review: draft-… Robert Sparks
- Re: [Gen-art] [Netconf] Gen-art LC review: draft-… t.petch
- Re: [Gen-art] [Netconf] Gen-art LC review: draft-… Kent Watsen
- Re: [Gen-art] [Netconf] Gen-art LC review: draft-… t.petch
- Re: [Gen-art] Gen-art LC review: draft-ietf-netco… Andy Bierman
- Re: [Gen-art] Gen-art LC review: draft-ietf-netco… Andy Bierman
- [Gen-art] Gen-art LC review: draft-ietf-netconf-r… Robert Sparks