Re: [netconf] Augmenting rpc-reply

"Jan Lindblad (jlindbla)" <jlindbla@cisco.com> Fri, 11 September 2020 12:30 UTC

Return-Path: <jlindbla@cisco.com>
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 8D7C33A0FA9 for <netconf@ietfa.amsl.com>; Fri, 11 Sep 2020 05:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 header.b=Lru6b82U; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tsYbYyik
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 Pf93wZpXAtDc for <netconf@ietfa.amsl.com>; Fri, 11 Sep 2020 05:30:00 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0493A0F44 for <netconf@ietf.org>; Fri, 11 Sep 2020 05:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17313; q=dns/txt; s=iport; t=1599827398; x=1601036998; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cd2BN0RWG5bvPMwTitXrrLmwYQE3M7woJxYtJ6nHsdU=; b=Lru6b82UOpAgsDq128Mokxo5+Ko4TTpe2x4x1yScvO1AN6Mr5+SfvdnQ bLFajA4Uj68gPrBNui4H600I9heGQtxyT5sonah9NLRgEATm4PM8z0GIU zUgBeLOf9gYUgUfC3A0AzquLmvf5i50PmuMQ16BtOFjKqUkggbw4uz8qf w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AoRfMvxXj/09FnGDyLGN4hAPNuw3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVBgD7bFtf/5FdJa1fgliBIy9RB3B?= =?us-ascii?q?ZLywKhC6DRgONQZQphG6BLhSBEQNVCwEBAQ0BASMKAgQBAYRLAheCDAIkNAk?= =?us-ascii?q?OAgMBAQsBAQUBAQECAQYEbYVcDIVzAgEDEhEdAQE3AQ8CAQhCAgICMCUCBA4?= =?us-ascii?q?gB4MEAYF+TQMuAQMLqGoCgTmIYXaBMoMBAQEFhRIYghADBoE4gnGDaYZDDxu?= =?us-ascii?q?BQT+BOAwQgk0+glwCgSUiRYJqM4ItkyeGbyaLS5B+CoJliGyGUIp8Ax6DCYl?= =?us-ascii?q?zk2edMJBjhCkCBAIEBQIOAQEFgVQ6gVdwFTsqAYI+UBcCDZIQilZ0NwIGAQk?= =?us-ascii?q?BAQMJfIwmLYEGAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.76,415,1592870400"; d="scan'208,217";a="559230836"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Sep 2020 12:29:56 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 08BCTu2l009032 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2020 12:29:56 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 11 Sep 2020 07:29:55 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 11 Sep 2020 07:29:55 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 11 Sep 2020 07:29:55 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+GjQ3pVLBUj4RJGX9x6zTxozx3o0u1G1ZkhVnSLdDd3iHnIsYCfa/Re/aIfcy8x5yFuTBR31IT4zP4EI/coCV3UyxOx/urtJbGgY0B6F2kBP6ckTdxD6qaS5LgdPYZ3+gLdMo/JgbEvkshsar44WIsxf7LjyM0mDq+8Zy4+b2jRu/nT2CiS3Fl97wuNIb+9eVk1C/npWb/cVdarTtS71JSdizmecbm1vYkwDheGHayEt46wedGDpeF1RRpTLCH1IdasnaCErCc7jZYVXQmNE5TvCihIZA3BD4fVxb93qRFA2JeO7EAabNNbD1hxs6ow8WNC0vXg7Cjkk5Tl7uz8qg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cd2BN0RWG5bvPMwTitXrrLmwYQE3M7woJxYtJ6nHsdU=; b=ZT4YMqZkU06DdP08wcqeDpa2iMyjA+WGRoF3XjjUS/DZ2nmKO9w2tYU5wkoNqpH8VoIuPhkNjgd7osPc+08E0sby1hlUaXgwch0oxqWSmIsC1jMvI0r4SkkzYAecuAwe+62IUvo1S8dp37H+qNo07lZDTAfNLtxMB3s236Qz8bghwCRiOaoy79rZvAtVDLkJxC02GdlzSOP/5Tcg91MAJNbvU/828l6gfylV8ouL08B7VRNDrxf2tosEBVBuEBRArDsTMePOE4KILoLN+HAELY6kRpVKiIyxb7eqJJ+7TdXvhZiPUO8mO5GWJ8BcdeMGHO2fNgz7sV8x1Es1H0PQEA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cd2BN0RWG5bvPMwTitXrrLmwYQE3M7woJxYtJ6nHsdU=; b=tsYbYyiku/Aokt1vjEayVnXJDWUrvQgO+sliJWIUDZ+IMiYYM86anyMM7SdPJGneXxx5BZu/dQfbbqFWe5N1GPInGLHXZDEPLN8/XVJ9Zub5ILKe9qhUY4nYWsZ6rm5GRx0Ew0xEPHpHLL8H/gEJmaRFMw306RYRaitDAuh9M6M=
Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM6PR11MB2873.namprd11.prod.outlook.com (2603:10b6:5:bd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Fri, 11 Sep 2020 12:29:54 +0000
Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::fd62:3aa7:c332:92b2]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::fd62:3aa7:c332:92b2%7]) with mapi id 15.20.3370.017; Fri, 11 Sep 2020 12:29:54 +0000
From: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
To: Netconf <netconf@ietf.org>
CC: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= <mbj+ietf@4668.se>, Andy Bierman <andy@yumaworks.com>, "bl@ndt-inc.com" <bl@ndt-inc.com>, "kent@watsen.net" <kent@watsen.net>
Thread-Topic: [netconf] Augmenting rpc-reply
Thread-Index: AQHWh0xEdb16zB4JDk6ZAIx+dcpuoKliFxMAgAAsPICAARyVgA==
Date: Fri, 11 Sep 2020 12:29:54 +0000
Message-ID: <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com>
References: <FC898DB0-8306-4E23-BD34-88657D36C98B@cisco.com> <20200910.185258.804843941725520730.id@4668.se> <CABCOCHQnw_H=W0Sgian7LyLgTABMu_Xg+YPfxe5Yx+wJ13074Q@mail.gmail.com>
In-Reply-To: <CABCOCHQnw_H=W0Sgian7LyLgTABMu_Xg+YPfxe5Yx+wJ13074Q@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [213.67.237.150]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9f2d3968-30bf-41a4-6aba-08d8564e6321
x-ms-traffictypediagnostic: DM6PR11MB2873:
x-microsoft-antispam-prvs: <DM6PR11MB28736133DF07EE3EDCF9240CCA240@DM6PR11MB2873.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: IC/WPqtJW7sm3RknDj83AtFjCqTPTxhler+bceUGQQswPu+fofRZDyzjoWERrLpTtCnCrWM1PGNrwFw63nYGVrCh/n47/NWdt8C1pvEvJ25G0dEpdyNJzrD05rnEz7XneYv/ajRsoirTWoGH1ceYvgcukpIly+OiCbapdzY2JiPTxAR1PUkKv4DdZhNaRz8BD5SZqpcy9Sgi9X6rPZpI+Nq2DT88jneznrIr10mqU9HrdtG0ZoNzqdwh9pKJtrt1ggYUQX58gYyWA7ZIUCL1dIJu9DIZbVUW8G2vmmoriXXoJJLOu5XhbG0YegohYk228ikdxbC+YEg0ta076vgU5WvWvpjLTxtoJpn1pGQZ9QZ/x5LKPvOuYsUZX9/StPQEkbTgjxGwPAj5IN/NKD14HQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB2841.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(136003)(376002)(346002)(8936002)(66476007)(6916009)(64756008)(66946007)(8676002)(91956017)(5660300002)(6486002)(76116006)(66556008)(86362001)(186003)(26005)(36756003)(478600001)(6506007)(4326008)(71200400001)(54906003)(316002)(2906002)(66446008)(83380400001)(166002)(966005)(6512007)(2616005)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: miOzobMNiMX9FVVTfW76YZUDBp05OvZGUl/zHl/A2+6lDal5eA3ahPfih0XOKiHhkvHkNuh9X1JiuOeT9Bx3qQeoMk4ElVHUbaBsQ4klUT/EDiq/rydVM6e8aXVyFb42cGBa1g03y69WmpD+bKO/+7RiiOVrUeU1CWQJxulePjxdepBPdyIvI7mBnn284X3/RN14dASrh5sgZCndto5sViTcTMWnh6YdetycMvv4BFJ4n/+Ss/UGNcDRFxUC/V4oww8y9w5tEPyj5cROc8cvC1pyen6HItwmG764aJbIgSo162FeQpRuT53Z5KNlCqcRHToHp0saNJDXE0Txe+pacTA3kxvAxqzxfb/0c6Jby8376iow0Gi9W1OYAjh+PpA78UjJ2WH+seOwBZJUsje9QAtkp5xjh+m9k2hWopTCSt4IVo+eX7wHgVhZ6Gr8aM0feBkyH06m4hr2AGNndE/bTTWAprMQhMdAtMuLB57AsBghVvD2/45MXK8A3miN6ysiAWycIKL60JlWZc+fD1nZSVVHdtdsmPZ6Sqi2ASupTCXAVi3DBooZqzWef4UDs77G37fgjHpnFae1jg/tsIEgskrLjakNcNi2aobfkW1iFz5VYiZZudP0VEE4+FbQeq75Jj3VEZ2VR3pEskmLDczAWg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_0CCA567F56914A85812C0B95470E5C6Cciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2841.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f2d3968-30bf-41a4-6aba-08d8564e6321
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2020 12:29:54.2318 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oeWLIE/oaMCORAGApM4n678RUbKXo/m8+HYWrLm5H0U2sI1Rl1Ul2jamQ0G3A4qUkz8EmJiutI8GnBKUNkhAIg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2873
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/1uVqAa0QrsnCUdpGoyurBG-ObRY>
Subject: Re: [netconf] Augmenting rpc-reply
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: Fri, 11 Sep 2020 12:30:03 -0000

Dear NETCONF WG,

Thank you all for contributing viewpoints. Actually, these answers were a surprisingly faithful reflection of the internal discussion we had, which prompted us to to take the question to the list.

Since there was clearly no rough consensus on the matter, let me voice the counter arguments we had in our internal discussion for those arguments that were also mentioned here on the list, in order to see if we can distill at least some order in this.

Martin suggested that:

However, RFC 7950 says in section 7.14.4:

   If the RPC operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].

Is it reasonable to interpret this 7950 language to exclude any and all extensions? One could argue that this prescribes a single <ok/> as far as 7950 and 6241 are concerned, but not ruling out extensions.

Which seems to say that if a note is returned, you would get:

      <rpc-reply message-id="101"
                 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <note xmlns="my-namespace">abc...</note>
      </rpc-reply>

This is also consistent with the XSD in RFC 6241.

XSDs always speak about what they require in their targetNamespace, and have no "jurisdiction" over other namespaces. Thus XSDs have no way of precluding extensions. Is it reasonable therefore to conclude then that the NETCONF XSDs cannot be taken as evidence either for or against extensions?

The problem with this though is that clients probably check for the
presence of "ok" to verify that an edit-config succeeds, hence I think
it should be allowed to reply with both <ok/> and additional elements,
as examplified above.

It seems reasonable to assume most or all NETCONF servers would send, and most clients would look for <ok/> in the rpc-reply. If anyone has a counter example (i.e. can name an implementation that does not), please speak up.

Andy suggested that:

I think this change is not backward-compatible because a conformant implementation
might follow the XSD, which clearly shows "ok" as a choice, not mixed with the other
responses.

If XSDs have no way of expressing the absence of tags in foreign namespaces, and properly written XML parsing applications generally are made to skip over tags and attributes in unknown namespaces, would it be reasonable to say that extensions are backwards compatible? This is the theoretical part of the question.

The other part is more practical: Assuming the theory is true, would the NETCONF WG have the courage to call any implementation that does not follow these XML/XSD principles incorrect?

Kent suggested that:

I don’t think this would be enough, as client-validate of the response might fail unless they know about the “my-namespace” schema.  For interoperability, it would be best for the clients to send something in the request (or have something in their profile) indicating that they’re able to process the extended response.

The discussion about well behaved clients is already captured above, but the angle about the client side sending capability strings in hello is new. In what situations would such a client side capability declaration be required? What YANG augments would only be sent to clients that have declared knowledge of them, and which augments would always be sent?

For a longterm solution, please consider adding to the NETCONF-next tracker: https://github.com/netconf-wg/netconf-next/issues.  We might also want to consider the feasibility of doing the same for RESTCONF, as currently RFC 8040 states that 204 (No Content) “is returned” for PUT and DELETE requests.

Good point. Is it reasonable to believe many RESTCONF clients would fail if a server returned a different 2xx code and a body rather than 204? And if so, would such a RESTCONF client be considered well behaved?

Borislav also commented, but I believe the topics are already covered in the above.

Best Regards,
/jan