Re: [netmod] <running> vs <intended> [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]

Andy Bierman <andy@yumaworks.com> Mon, 18 September 2017 16:44 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C20133018 for <netmod@ietfa.amsl.com>; Mon, 18 Sep 2017 09:44:51 -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=unavailable 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 8CHMxsTbAZJl for <netmod@ietfa.amsl.com>; Mon, 18 Sep 2017 09:44:48 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 774D5133071 for <netmod@ietf.org>; Mon, 18 Sep 2017 09:44:48 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id a18so1139604lfl.13 for <netmod@ietf.org>; Mon, 18 Sep 2017 09:44:48 -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:from:date:message-id:subject:to; bh=GbCexilLVF7WThwVHpzyEBOzLbjypy9tsgR0C6AD31o=; b=ZXSWAklb/jU7GY9EMCqidjl2rtotpm4fyuQmli0kUtveTHZHv1BlEOaSYVF2pea7d6 aaP1HrnAEJmH6bLBcve4eU3wYGzivnRv2Hozrn87KzUlZtCRRpewJb2b1iCS66y0TqSn EtV7XNgm0kba5EBtHDFeIkFqUqroRZkzrPZGlDMVlpBF2wZCDIFY341sFY2rwTYPn3kY CXQTYB1Nwnl1eRrFnpCn+AVfOR4hqSI54XBi8X1I1HPOl6/UOrhmeKxwRJwsHKUZ+N9F eNpqfHkwN+VQlfgsJpp1OzlhsfdwwMRPsg9vDg3zUwwW1TdbkfLfRCGDifdEkStdEjTr CaXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GbCexilLVF7WThwVHpzyEBOzLbjypy9tsgR0C6AD31o=; b=ndDwTONxIy/HAP+9tamQJDEtFSYtKzSv3Xyj4MKbI0ndfX5SaVnJVn6oP+HClHIhHc ZHHEuXsVTceSxsFEGviHzDRn2B8nXFnKN8tEGlVz9dQNQcwVW/l6RqLlco6SWePi4gpx ghZVMIH3LObWoCiX2xEVYt2dgqHl4RdDpy7EZNO9ZCIoPf0W/cbUP17KGeJuE+yxDaf4 bU+4amzHrTa6IprGUo32cFuf9kLetrvkjTVUG35X7rYlGAy3SeGaK4RWSlPQ5zcnh+H3 05sMQRU+T+UO4z0LdIlU7/Ba2vWKmWd3R14uJkvUOL30vvPE2JMaEgQkioMVWrubEIq4 BXjw==
X-Gm-Message-State: AHPjjUiLVBA88x1whFPC4RT/aVjBTa8qfVHXAw+0epyhXJWZEhLu2yZV qPZXXQi4KAStcDdbVQW3jPtF8cqzMxf5oKZLHgFubQ==
X-Google-Smtp-Source: AOwi7QCNPucJ53bvW9+ncamp9RsspPKfxktGemvw0CqI4FK9Ja7JcZHADbeTILHxxmttsdzTSICjvHJ+iIKRjsuFIhw=
X-Received: by 10.46.83.17 with SMTP id h17mr6123591ljb.158.1505753086693; Mon, 18 Sep 2017 09:44:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Mon, 18 Sep 2017 09:44:45 -0700 (PDT)
In-Reply-To: <20170918162107.6qnmrl5hepqcxsrm@elstar.local>
References: <CABCOCHQcSUSUZMvzVGyaXObHadZqksKge89_6YcH9PCbxMCG=g@mail.gmail.com> <20170916072403.xp37556z6g7b42gr@elstar.local> <CABCOCHT8CMCAnqf6Oe1bKMzQ-B_0GjrQiQ8YXgQJvCo-NBOBBA@mail.gmail.com> <20170917.154115.791964858062115650.mbj@tail-f.com> <CABCOCHQeQYU+zBpFvVRqCc02nrtyS6Jix1=43it1fn9i9xrD6Q@mail.gmail.com> <c39dced6-9cd5-a7e6-db00-b121bc6de07c@cisco.com> <CABCOCHQYSpRrG93YCb6WxFkuRKNM2e8bjZrVpfDw2kDF1Q7uSQ@mail.gmail.com> <70a5b659-83a3-5952-b5e7-b8e991c84ef1@cisco.com> <CABCOCHQE3irqdL7Pv+DF=YFy_RVAZ95xmFt0v17FUiLcFbiV-g@mail.gmail.com> <f411c5e0-ae05-e8b2-c5c0-199a9b24f1d2@cisco.com> <20170918162107.6qnmrl5hepqcxsrm@elstar.local>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 18 Sep 2017 09:44:45 -0700
Message-ID: <CABCOCHR4MdXEJ7OiY+VxDEfmHYWVrx+=5opDwHn3PsFeGY5LDg@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "t.petch" <ietfc@btconnect.com>, Berger Lou <lberger@labn.net>, "netmod@ietf.org" <netmod@ietf.org>, NetMod WG Chairs <netmod-chairs@ietf.org>, draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1ced70da23900559797545"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GQUadQ3kWC2xxSSz0oQZVAGTBpU>
Subject: Re: [netmod] <running> vs <intended> [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Sep 2017 16:44:51 -0000

On Mon, Sep 18, 2017 at 9:21 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> >
> > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > I do not agree the architecture should update YANG at all.
> > OK.
>
> I am with Andy here. <running> has always had the requirement to be
> valid and we are not supposed to change that. Mechanisms for inactive
> configuration or templating must be designed to be backwards compatible
> I think.
>
>
I have been trying to think of a way that an enterprise-wide flag day
upgrade is not required,
but no luck so far. As Phil pointed out, if 1 client is using disabled
nodes,
unaware clients clients might end up deleting them if disabled nodes
are just omitted from <get-config> responses. (e.g., replace operation).

A client has no requirement to maintain attributes sent with server
responses
(unlike the server for <rpc> -> <rpc-reply>), so returning the disabled
nodes
to an unaware client is no solution either.

It looks to me that an operator has to make sure all apps that alter
configuration
are aware of the disabled nodes.

IMO a standard attribute should be defined using RFC 7952:

  md:annotation enabled {
    type boolean;
    description "...";
  }

Even if the server supports vendor-specific attributes, it has to report
this attribute as well.
The default is enabled, so only disabled nodes need this attribute.
Standard configuration can wait.  Standard reporting should not wait.

Since clients can ignore YANG extensions, a new version of YANG will be
needed eventually,
but at least this allows 3rd party clients to recognize disabled nodes from
any vendor.



/js
>
>

Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>