Re: [i2rs] YANG validation and opstate
Andy Bierman <andy@yumaworks.com> Tue, 07 June 2016 01:38 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A0D12D0A4 for <i2rs@ietfa.amsl.com>; Mon, 6 Jun 2016 18:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 B40Bl83oemK2 for <i2rs@ietfa.amsl.com>; Mon, 6 Jun 2016 18:38:03 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74461200A0 for <i2rs@ietf.org>; Mon, 6 Jun 2016 18:38:02 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id x189so156969571ywe.3 for <i2rs@ietf.org>; Mon, 06 Jun 2016 18:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=H4oYM9gPm6aHwUrLvfLmYmlVIJENuMfee5dLsTxjbhA=; b=PixbIOHv0lgkEp3vrqrx3q6ADdbwYwbmYQDKaIJ3NZjVnAHSiwZ3mSiIIVHV64E8wV Ok/RtsjJ/lePIJ1JyrmEaXJR1k9UFuQQ/w6aSQEBuDezuHZGU86vcV3sAql1W7iEzF6z UQnzkVYKMhptjwq34mxvhYlYQhjA35sSgMqJvq6CEfnx9oexCqABinA0y3NkG+qdV2gC oyQo6bfTFVQ64mUK+6GzgGkkZL9SZmleCb1/nCZp1AJD+VavctFiVxNNgMWoc748489P l+73HFuyo4FFYubE6h07yTmwMbEaTXaZeq0A2OxZql+V1gtWBVabc4+cGmMeBraYMgSY L9mQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=H4oYM9gPm6aHwUrLvfLmYmlVIJENuMfee5dLsTxjbhA=; b=lPgRng7JoKvFLMoJ6EeNgJhAQrTp0Kqju6UzxaPjwQjQtDL1fEWyAj/I/n8JsefNPO kkchrBBRzgamb9+tN3qHq/X42iYLDBMKVv8O7qTxGpSFjyp1HhQp0W8+N/oQ3UUTPLcX YH1F+r5EBUiRTaDFEmCVm4lROHCWnBzKEWOPMBmS5FpIuxZxbmWxBpBdi2tk6O4wwha8 qZ/qSHJ5OjHYTMukLaWhqlXTFgQ0zZBG1yajGKFgoSd2BeidG52p8oR5S83Ae+ybnrPf t90FDb86JvaYtcB8VTqRQo/prQ+KGAx6UtSXPfJcsgdmg5UxCxzaORZo801TwvnhTotA 11yQ==
X-Gm-Message-State: ALyK8tJ2VB56RBfaZ2QDIdNDcuax7DQjVJox6BgdK5xvW5XBhwBYVA0g0ZFmITcot51TqVAepZEvmCiimIPViA==
MIME-Version: 1.0
X-Received: by 10.129.74.86 with SMTP id x83mr14022942ywa.38.1465263481793; Mon, 06 Jun 2016 18:38:01 -0700 (PDT)
Received: by 10.37.115.68 with HTTP; Mon, 6 Jun 2016 18:38:01 -0700 (PDT)
In-Reply-To: <166da791-a4e5-479c-a74a-793ee2b433b6@joelhalpern.com>
References: <CABCOCHQAuhsngAKXE=-o=wWsv1u6BXDWCJ--0JJ4p5D0f2WY3Q@mail.gmail.com> <029d01d1c04a$a7d1c330$f7754990$@ndzh.com> <CABCOCHSihuGOpMy3fqvTcnmRbYYszOpxYcwNsRc9RRkX6gk+fQ@mail.gmail.com> <ae6c929d-bfd4-02ca-d7b3-fbc32a7fae84@joelhalpern.com> <CABCOCHSsn-7YW1dDPJqLe-es592UaYEoeTfBKVidV8u7QbDXQg@mail.gmail.com> <166da791-a4e5-479c-a74a-793ee2b433b6@joelhalpern.com>
Date: Mon, 06 Jun 2016 18:38:01 -0700
Message-ID: <CABCOCHRTdLJMZHLs=-Np9mvqzUrCO2mDLA8EpDBw0vStcR5q2A@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary="001a114c8c3a55e5160534a63d0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/yE3j00qgs5xF_FnmChR7DvLrjuk>
Cc: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [i2rs] YANG validation and opstate
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jun 2016 01:38:06 -0000
On Mon, Jun 6, 2016 at 6:04 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote: > I think that works for me. > > What I read you as saying is that we could simply define that any and all > validation of I2RS operations is a local matter and up to the server. > > This would remove any need for flags or marking, and also remove any need > for indicating a mode of operation. > > If that is what you meant, it works for me. > I think clue-full client developers will understand how this will assist their foot-shooting efforts. YANG already has the deviation-stmt so the server can say "I ignore this leafref and that must-stmt". Yours, > Joel > > Andy > On 6/6/16 9:01 PM, Andy Bierman wrote: > >> >> >> On Mon, Jun 6, 2016 at 5:46 PM, Joel M. Halpern <jmh@joelhalpern.com >> <mailto:jmh@joelhalpern.com>> wrote: >> >> When we started on the I2RS work, the explicit request from the >> operators was to make this as simple as practical and as efficient >> as practical. >> >> In regard to constraints on what they could do, the specific request >> was "let us shoot ourselves in the foot." That is, if some change >> will break the network, so be it. it is the operators problem. If >> the change only causes the box to reboot, that is less dangerous. >> So it seems to fall within "let me shoot my foot." >> >> I expect that there are some forms of validation that need to take >> place just to attempt to apply the RPC. But everything beyond that >> was requested to be not performed. Whether we can actually achieve >> that is a different question. >> It does strike me that we can also go back and ask the operators >> again what they meant, if you think it is likely we misunderstood. >> >> >> In my example "when IPv4" is ignored so IPv6 parameters are >> accepted as valid. >> >> Does this mean the server faithfully applies the wrong parameters that >> make no sense whatsoever? Probably not. It means the client developer >> and operator have no idea what a server implementation is SUPPOSED to >> accept as a valid edit. (Which diminishes the standards value of I2RS) >> >> My original point was that extra flags for I2RS like "I ignore all >> leafrefs" >> are worthless. It is better to declare that validation is not part of >> the ephemeral datastore. It is an implementation detail whether accepted >> data in that datastore ever gets used. >> >> >> Yours, >> Joel >> >> >> Andy >> >> >> >> On 6/6/16 8:26 PM, Andy Bierman wrote: >> >> Hi, >> >> I am still a little confused on the intent of the partial YANG >> validation. >> It seems trivial to adapt the NETCONF or RESTCONF validation >> points to I2RS. >> The only difference is that I2RS data can have constraints >> pointing at >> config=false >> nodes, so this is more complicated and expensive to implement >> than NETCONF >> or RESTCONF. >> >> The argument for partial validation I have heard is "We only >> support 1 >> client and >> we know the client already checks the data, so we know the data >> is valid." >> This is not arguing that there will be invalid data in the >> datastore. >> It is arguing >> that the client can be trusted to be correct and bug-free so why >> bother >> spending >> server resources duplicating the validation. >> >> Typically in NM standards we assume more than 1 client is >> allowed in the >> design >> and a client cannot be trusted. A client could be malicious or >> buggy. >> Either way, if the server crashes or allows a security breach >> it's still the server vendor's fault. >> >> I2RS seems like an implementation detail (not a standard) if >> vendors plan on >> writing both client and server code and not intending to support >> any 3rd party implementations. >> >> >> Andy >> >> >> >> On Mon, Jun 6, 2016 at 4:25 PM, Susan Hares <shares@ndzh.com >> <mailto:shares@ndzh.com> >> <mailto:shares@ndzh.com <mailto:shares@ndzh.com>>> wrote: >> >> Andy: ____ >> >> __ __ >> >> I’m not sure the context you are referring to as “I2RS agent >> pick >> which Yang statements they will implement”. ____ >> >> __ __ >> >> From the context, I guess you are investigating Ephemeral >> Configuration State. If “the server MAY do YANG >> validation____ >> >> on the ephemeral datastore”, and then check it in >> operational state >> – this clearly works. However, I’m struggling to fit the >> normal >> Ephemeral Configuration State validation into section 8.3 of >> RFC6020bis. There are three steps in constraint enforcement >> (section 8.3 of RFC6020bis). ____ >> >> o during parsing of RPC payloads - ____ >> >> o during processing of the <edit-config> operation____ >> >> o during validation____ >> >> __ __ >> >> Currently section 8.3.3 says: ____ >> >> __ __ >> >> “8.3.3. Validation____ >> >> __ __ >> >> When datastore processing is complete, the final contents >> MUST >> obey all validation constraints. This validation processing >> is >> performed at differing times according to the datastore. >> ____ >> >> __ __ >> >> If the datastore is "running" or "startup", these >> constraints MUST >> be enforced at the end of the <edit-config> or <copy-config> >> operation. If the datastore is "candidate", the constraint >> enforcement is delayed until a <commit>____ >> >> or <validate> operation.”____ >> >> __ __ >> >> My understanding is we are discussing how constraint >> enforcement >> works in Ephemeral Configuration State. ____ >> >> You need to define where the ephemeral constraints MUST Be >> enforced. It would seem reasonable to enforces at the end of >> <edit-config> or <copy-config>, or by the end of an rpc >> operation >> defined in a data model. ____ >> >> __ __ >> >> Since RESTCONF uses PUTS/PATCH within a HTTP exchange, then >> the >> constraint enforcement must be at the end of that http >> operation. ____ >> >> __ __ >> >> Sue ____ >> >> __ __ >> >> ____ >> >> __ __ >> >> __ __ >> >> *From:*i2rs [mailto:i2rs-bounces@ietf.org >> <mailto:i2rs-bounces@ietf.org> >> <mailto:i2rs-bounces@ietf.org >> <mailto:i2rs-bounces@ietf.org>>] *On Behalf Of *Andy Bierman >> *Sent:* Sunday, June 05, 2016 5:43 PM >> *To:* i2rs@ietf.org <mailto:i2rs@ietf.org> >> <mailto:i2rs@ietf.org <mailto:i2rs@ietf.org>> >> *Subject:* [i2rs] YANG validation and opstate____ >> >> __ __ >> >> Hi,____ >> >> __ __ >> >> I don't really agree with idea that I2RS agents pick which____ >> >> YANG statements they will implement, but I think there is____ >> >> a way to handle this correctly in the datastore framework.____ >> >> __ __ >> >> The proposed enumeration for server validation____ >> >> capabilities (e.g., full, XPath, leafref) is not really >> needed.____ >> >> This enum is too course-grained to be useful.____ >> >> __ __ >> >> IMO it is better to say the server MAY do YANG validation____ >> >> on the ephemeral datastore. Whether or not the server >> uses____ >> >> data from the ephemeral datastore is left as an implementation >> detail.____ >> >> The server could use invalid input parameters or ignore >> them____ >> >> or reject them in the first place.____ >> >> ____ >> >> The client needs to check operational state to know if/when >> the____ >> >> ephemeral data was applied to the system.____ >> >> __ __ >> >> __ __ >> >> __ __ >> >> Andy____ >> >> __ __ >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org <mailto:i2rs@ietf.org> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >>
- [i2rs] YANG validation and opstate Andy Bierman
- Re: [i2rs] YANG validation and opstate Nadeau Thomas
- Re: [i2rs] YANG validation and opstate Andy Bierman
- Re: [i2rs] YANG validation and opstate Susan Hares
- Re: [i2rs] YANG validation and opstate Joel M. Halpern
- Re: [i2rs] YANG validation and opstate Andy Bierman
- Re: [i2rs] YANG validation and opstate Joel M. Halpern
- Re: [i2rs] YANG validation and opstate Andy Bierman