Return-Path: 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 0EF4D12018D for ; Mon, 24 Jun 2019 03:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, SPF_PASS=-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=RKGKGJp+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YotMeY/n 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 7UdK1-uZnlXn for ; Mon, 24 Jun 2019 03:06:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE4D12013F for ; Mon, 24 Jun 2019 03:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13951; q=dns/txt; s=iport; t=1561370813; x=1562580413; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=t3xKScnNAFrXyi18nrwazA1kEdpgKGB2LTA69ri+Z7E=; b=RKGKGJp+nx3fXk0QVKwIsOGhOTj+jKCweIkE78ccKUU7NgnzSOCdKT2U No3MnXbUjL9s9X67jZDXL/gGVx1L0jPjAQPJRIOndjd/3b5kBqepLCthA 8sXSMzn28SMtZKGWI8sqUvJfroMK0ovOcPKi+sYrEV8NFv4bA1en78dFl I=; IronPort-PHdr: =?us-ascii?q?9a23=3Ai3ihiRPHh8+8Sso66IIl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAACcnxBd/4sNJK1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgRQvUANqVSAECygKh1MDhFKKD4JbkmSEVIEugSQDVAkBAQE?= =?us-ascii?q?MAQEYAQoKAgEBg3pGAoJnIzQJDgEDAQEEAQECAQVtijcMhUoBAQEEAQEQGxM?= =?us-ascii?q?BASwMDwIBCBEEAQEoBycLFAkIAgQBEggagwGBHU0DHQECDJgIAoE4iF+CIoJ?= =?us-ascii?q?5AQEFhHoYghEDBoE0AYtdF4FAP4ERRoJMPoJhAQGBSxgrCYMGgiaLfYdKlkY?= =?us-ascii?q?JAoIUhk2NMJdHjSaHL4xjgnECBAIEBQIOAQEFgVA4gVhwFTuCbIJBg3CFFIU?= =?us-ascii?q?/coEpjWYBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,411,1557187200"; d="scan'208,217";a="493902299" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2019 10:06:50 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x5OA6oRZ006841 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jun 2019 10:06:50 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 05:06:50 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 06:06:48 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 24 Jun 2019 06:06:48 -0400 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=mj7R9e6ys7erXIR9E+a6oA2T3qNrGsB3X5NnRa1uh8U=; b=YotMeY/ngCL1wBszanhmdwyVFBXvhCV4ZjhLN2LJadI4Aee2iU9Aha2SRPc4c4H0O8n2+rsVtVBf4nv7IHN78cDg9zkL5hBjBlbu2bkMQvaUJCwBj4jx0qyWZ5ftvQLiF9lv8qY8JvshpQ75faT/C84lFCiNMp/2XDZLSKPQuGs= Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB3397.namprd11.prod.outlook.com (20.177.186.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.13; Mon, 24 Jun 2019 10:06:47 +0000 Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::ed99:b6a8:d6fb:5045]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::ed99:b6a8:d6fb:5045%4]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 10:06:47 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] restconf 'get' on non-presence container Thread-Index: AQHVKD/Ydf84Kv77AkGLw/T0xCsJ+aamnvgAgAPzUmA= Date: Mon, 24 Jun 2019 10:06:47 +0000 Message-ID: References: <0100016b7a7ca57b-bedf88a1-e867-4d0d-a44a-94964a93ccbb-000000@email.amazonses.com> <0100016b7bed5571-8bf0b1c4-db4e-499a-8728-610ea56c54d9-000000@email.amazonses.com> In-Reply-To: <0100016b7bed5571-8bf0b1c4-db4e-499a-8728-610ea56c54d9-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.41] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef6fa553-5c71-4589-4ca1-08d6f88bab37 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3397; x-ms-traffictypediagnostic: BYAPR11MB3397: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(39860400002)(376002)(136003)(189003)(199004)(6246003)(8936002)(2501003)(25786009)(81156014)(81166006)(8676002)(74316002)(110136005)(7736002)(316002)(9326002)(71190400001)(71200400001)(76116006)(66476007)(66556008)(53936002)(66946007)(26005)(478600001)(73956011)(53546011)(6506007)(2906002)(256004)(102836004)(6436002)(14454004)(229853002)(33656002)(236005)(9686003)(186003)(6306002)(54896002)(66066001)(55016002)(64756008)(66446008)(966005)(68736007)(486006)(606006)(5660300002)(99286004)(14444005)(86362001)(11346002)(3846002)(76176011)(446003)(790700001)(6116002)(476003)(52536014)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3397; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rpRy8XZcTSuKGF1DCtyJyoDA+Mviiz5+aT99eCQc5puBsxAC4Vd661lp4JKASRfsj2QU95KJEh7jpZq1o9XMYIJYY+i9WXDLmZnUwvJEf1d40iRVGfAzNKzhJJZz7O5RryXD7X0QrXA15eUX5ufC6CZJ6ZVi9QnPt1KpKMpRTYk2gtP4VsY6APHC+2Ts07WxaCPS84h90fP+23k9kzuc96HP0RgHsCk6iWOvA44tnFEfNmcsArymJrTlH4ZCG8lrOk7GOchq11fs0HmADLkOmEQJCql4OmKC3fJiJnaKB122IHjIi0xReBY3D31RfXr0RzUPpv8PqlJLlA0lFOxIXdYn4VK7F8gkUu6bAuzaLl2QAPfFlJxnmMzIpQEGaD1tGHBKkwYaF+LKZo7ZZRLXCIAFyw/LbPRW/L1XLXc8uwQ= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB26314A5D2628766F97B4A1ADB5E00BYAPR11MB2631namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ef6fa553-5c71-4589-4ca1-08d6f88bab37 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 10:06:47.5205 (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: rwilton@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3397 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [netconf] restconf 'get' on non-presence container X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 10:06:56 -0000 --_000_BYAPR11MB26314A5D2628766F97B4A1ADB5E00BYAPR11MB2631namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, I don't think that is the same conclusion that I reached with that thread -= I'm not convinced that there was an agreed conclusion, different folks see= m to different opinions on this. I support you opening an issue on the YAN= G issue tracker to see if we more tightly specify this behaviour for client= s. My interpretation is that the current answer is (3), i.e. it up to the impl= ementation. I suspect that the answer may depend on how defaults are handled, and it ma= y also depend on which datastore the query is being made against. Thanks, Rob From: netconf On Behalf Of Kent Watsen Sent: 21 June 2019 22:25 To: netconf@ietf.org Subject: Re: [netconf] restconf 'get' on non-presence container Reviewing the very long "What should a server response be?" thread from 201= 6-07-11, it seems that the answer might be: 4) depends on client-usage history (i.e., sometimes 404 and sometimes 200 with an empty response). Specifically, it seems that servers proactively creating or removing NP-con= tainers is not desirable. PS: I created https://github.com/netmod-wg/yang-next/issues/88. Kent // contributor On Jun 21, 2019, at 10:41 AM, Kent Watsen > wrote: Given: module foo { ... container widgets { <--- NOT a presence container list widget { ... } } } Assuming no widgets have been configured, would a GET on "/foo:widgets" return: 1) 200 with an empty response (i.e., 2) 404 (Not Found) 3) It's up to the implementation With NETCONF, or RESTCONF when retrieving an ancestor of an NP-container, it's clear that RFC 7950, Section 7.5.7 (XML Encoding Rules) comes into play: If a non-presence container does not have any child nodes, the container may or may not be present in the XML encoding. However, this question regards the GET being on the NP-container itself. That is, it's not an encoding question so much as a protocol question. RFC 8040 doesn't discuss this directly, but Section 4.3 (GET) says: If a retrieval request for a data resource represents an instance that does not exist, then an error response containing a "404 Not Found" status-line MUST be returned by the server. Okay, so it does the NP-container "exist" or not? RFC 7950, Section 7.5.1 (Containers with Presence) says: ...the [non-presence] container has no meaning of its own, existing only to contain child nodes. In particular, the presence of the container node with no child nodes is semantically equivalent to the absence of the container node. Kent _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_BYAPR11MB26314A5D2628766F97B4A1ADB5E00BYAPR11MB2631namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,<= o:p>

&nbs= p;

I donR= 17;t think that is the same conclusion that I reached with that thread R= 11; I’m not convinced that there was an agreed conclusion, different = folks seem to different opinions on this.  I support you opening an issue on the YANG issue tracker to see if we more tightly speci= fy this behaviour for clients.

&nbs= p;

My interp= retation is that the current answer is (3), i.e. it up to the implementatio= n.

&nbs= p;

I suspect= that the answer may depend on how defaults are handled, and it may also de= pend on which datastore the query is being made against.<= /p>

&nbs= p;

Thanks, Rob

&nbs= p;

&nbs= p;

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 21 June 2019 22:25
To: netconf@ietf.org
Subject: Re: [netconf] restconf 'get' on non-presence container=

 

Reviewing the very long "What should a server r= esponse be?" thread from 2016-07-11, it seems that the answer mig= ht be:

 

    4) depends on client-usage history (i.= e., sometimes

        404 and sometimes 200 wi= th an empty response).

 

Specifically, it seems that servers proactively=  creating or removing NP-containers is not desirable.

 

 

Kent // contributor

 

 

 



On Jun 21, 2019, at 10:41 AM, Kent Watsen <kent+ietf@watsen.net> wrot= e:

 

Given:

 module foo {
   ...
   container widgets {   <--- NOT a presence co= ntainer
     list widget {
       ...
     }
   }
 }

Assuming no widgets have been configured, would a GET on "/foo:widgets= "
return:

   1) 200 with an empty response (i.e., <widgets xmlns=3D= "..."/>
   2) 404 (Not Found)
   3) It's up to the implementation


With NETCONF, or RESTCONF when retrieving an ancestor of an
NP-container, it's clear that RFC 7950, Section 7.5.7 (XML
Encoding Rules) comes into play:

  If a non-presence container does not have any child nodes, the<= br>   container may or may not be present in the XML encoding.

However, this question regards the GET being on the NP-container itself. That is, it's not an encoding question so much as a protocol question.
RFC 8040 doesn't discuss this directly, but Section 4.3 (GET) says:

  If a retrieval request for a data resource represents an instan= ce
  that does not exist, then an error response containing a "= 404 Not
  Found" status-line MUST be returned by the server.

Okay, so it does the NP-container "exist" or not?  RFC 7950,= Section
7.5.1 (Containers with Presence) says:

  ...the [non-presence] container has no meaning of its own, exis= ting
  only to contain child nodes.  In particular, the presence = of the
  container node with no child nodes is semantically equivalent t= o the
  absence of the container node.


Kent

_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.= org/mailman/listinfo/netconf

 

--_000_BYAPR11MB26314A5D2628766F97B4A1ADB5E00BYAPR11MB2631namp_--