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
>