[netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243

"Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com> Wed, 17 January 2018 13:27 UTC

Return-Path: <einarnn@cisco.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 326F112706D for <netmod@ietfa.amsl.com>; Wed, 17 Jan 2018 05:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level:
X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 E7mObpI3yPUs for <netmod@ietfa.amsl.com>; Wed, 17 Jan 2018 05:26:58 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803DC120727 for <netmod@ietf.org>; Wed, 17 Jan 2018 05:26:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7916; q=dns/txt; s=iport; t=1516195618; x=1517405218; h=from:to:subject:date:message-id:mime-version; bh=EEWmHsx1ZsoK0tOKC2oXQPXwQKxIZeozXlQFoOf7Flw=; b=d5OdHHiVEOi78P2zYN2hHNKK3/u14OZXXHIx/6dR+BtjX0GrnZftJfqe cdoSMY7nIBn8OP1V2yKMYykHQ4Gkzny00DRLyxSzEuRYJjHqFUticOmpc J3NBAFeez8TaIMI2Zr274r2kxbE6zwH2238uwsnBWC8z1YsW6rZG63Rmu 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CxBwDNTV9a/4QNJK1bGQEBAQEBAQEBAQEBAQcBAQEBAYNBZnQoBoQMmQaBW5IEh2cKI4UYHIRHQhUBAQEBAQEBAQFrHQuFTWgBLR0CBDAnBIliZBClRoIniUwBAQEBAQEBAwEBAQEBAQEBAR+EPIIVg2kMhEKBWwsBAQIBgW2CWz0xgjQFo2oCiAuNRIIZZ5ERimmCWIYhgxoCERkBgTsBNSOBUG8VZwGCAAg2giEpgU6LTIEXAQEB
X-IronPort-AV: E=Sophos;i="5.46,372,1511827200"; d="scan'208,217";a="333930620"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 13:26:57 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w0HDQvuv023206 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <netmod@ietf.org>; Wed, 17 Jan 2018 13:26:57 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 17 Jan 2018 08:26:56 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Wed, 17 Jan 2018 08:26:56 -0500
From: "Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
Thread-Index: AQHTj5bYiGDflCZ3h0a24DFWm/LfUw==
Date: Wed, 17 Jan 2018 13:26:56 +0000
Message-ID: <616655B0-2494-4E63-906C-290E4AA6C1DE@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.5.20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.99.225]
Content-Type: multipart/alternative; boundary="_000_616655B024944E63906C290E4AA6C1DEciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/b2GXif2mxr2aXy-Vbb5_svN1o9s>
Subject: [netmod] yang-push issue: draft-ietf-netconf-yang-push-12 and default values and RFC 6243
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: Wed, 17 Jan 2018 13:27:00 -0000

All,

In discussions with some customers and on implementation, the issue of defaults has come up. For get/get-config we have the “with defaults capability” defined in RFC 6243 that allows us to control the behaviour with respect to defaults. To remind folk with an example, we could have:

    <rpc message-id="101"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          report-all
        </with-defaults>
      </get>
    </rpc>

The addition of the “with-defaults” tag and value determines the behavior of the get in this example (taken from A.3.1 in RFC 6243<https://tools.ietf.org/html/rfc6243#page-22>).

It strikes me that we need to have a similar mechanism for telemetry, allowing a user to specify, for example, that for a periodic subscription on a subtree, they also wish default values to be reported. I think at minimum we need clarification on this, as section 3.7 of draft-ietf-netconf-yang-push-12 currently says:

The content of the update record is equivalent to the contents that would be obtained had the same data been explicitly retrieved using e.g., a NETCONF "get" operation, with the same filters applied.

This text can currently only refer to a “get” as defined in RFC 6241 as there is no reference to RFC 6243 as yet. I think we need to address this issue now to define expectations, even if it is to explicitly not consider an RFC 6243-like mechanism or to say that we only consider explicitly set values in telemetry, or…

Cheers,

Einar