Re: [netconf] YANG attributes in a datastore

Kent Watsen <kent@watsen.net> Wed, 11 December 2019 19:37 UTC

Return-Path: <0100016ef677a0d2-dcf9391f-7b4d-4f18-baa6-ae2fdff1dbb9-000000@amazonses.watsen.net>
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 D499D12008F for <netconf@ietfa.amsl.com>; Wed, 11 Dec 2019 11:37:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 p4VLcO90f2be for <netconf@ietfa.amsl.com>; Wed, 11 Dec 2019 11:37:47 -0800 (PST)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEC7120052 for <netconf@ietf.org>; Wed, 11 Dec 2019 11:37:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1576093065; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=S5B4kFoZW+EnBo4VKHEL0rbXs5DfwI6rGzyeA1wVrWk=; b=HBhAJH+F3q5Ot4J7hCOEtOOuZIvEaKjf8SPvR1wdb1aW5poriJWDHznpfUgP0nvz t8JPVLGCg60jpJYwEtO6+F5nJmLQSLshTgHIOYgDDhnR7jrpyo51ok9EzOB5092P0rs 81QcDervqQYopvCgtQ60hQKwD5I7q7sWnJ5eif0g=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100016ef677a0d2-dcf9391f-7b4d-4f18-baa6-ae2fdff1dbb9-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95268B92-9E62-45E1-B404-31B6A9A85186"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 11 Dec 2019 19:37:45 +0000
In-Reply-To: <20191211.093012.945147782345213985.mbj@tail-f.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <CABCOCHQfXSD8fr70Hcn9Epu+Dcs9_wA+-+7Y+kQqB9k5fKDsOQ@mail.gmail.com> <0100016ef0c6b0d8-cdbbe2ff-ac02-4692-b2c0-9f9b64ce4fc5-000000@email.amazonses.com> <7027e13e49a631ee06a8fe63ba3e2abf102963dc.camel@nic.cz> <20191211.093012.945147782345213985.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.12.11-54.240.48.110
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/z_bdgcWW7B0yRAZoJ0OeJCLjH70>
Subject: Re: [netconf] YANG attributes in a datastore
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Wed, 11 Dec 2019 19:37:49 -0000

> So far, noone is proposing to standardize anything.  

I must've replied to the wrong message.  I was reacting to this message:
https://mailarchive.ietf.org/arch/msg/netconf/bHLGqeK-Yo3cYDAXic83m7oMAGY <https://mailarchive.ietf.org/arch/msg/netconf/bHLGqeK-Yo3cYDAXic83m7oMAGY>.


> The question was if any implementation is doing this today, and if so, how.

Juniper supports metadata today.  Specifically, the "inactive" annotation.  Sadly JUNOS defines an asymmetric "active" annotation to unset it, which is what thing that we were trying to fix with the "enabled" annotation in the conditional-enablement draft. https://www.juniper.net/documentation/en_US/junos/topics/reference/tag-summary/junos-xml-protocol-inactive-attribute.html <https://www.juniper.net/documentation/en_US/junos/topics/reference/tag-summary/junos-xml-protocol-inactive-attribute.html>.

Note that the ''report-all-tagged' retrieval mode in RFC 6243 was defined so that JUNOS wouldn't promote a default value to configuration.  This illustrates round-tripping, in that "configured" annotations are indeed expected to be returned to the server in write-operations.

Kent