Re: [netconf] Configured receiver capability exchange

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 28 January 2020 01:05 UTC

Return-Path: <evoit@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 879603A07A9 for <netconf@ietfa.amsl.com>; Mon, 27 Jan 2020 17:05:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=LkWudMIR; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=kzRfoonL
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 pZ2dMxyRdVXA for <netconf@ietfa.amsl.com>; Mon, 27 Jan 2020 17:05:30 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8E33A07A6 for <netconf@ietf.org>; Mon, 27 Jan 2020 17:05:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22783; q=dns/txt; s=iport; t=1580173530; x=1581383130; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=orTyQMbXwwpeEyv807iQwfR5T/gK8Z4FtAXix0mXA2k=; b=LkWudMIR5ZemtcdzS8xSujTv4PCD8g23qEkaUqza7pNSVb23XS48FFkw vykIohsO4mHw70losP30LmyTNsZ4blXfBtcAT5Arj2+lmS6zOlLicGs8f 3AxEP8rUze/lopMbjZfi44jAQ5nee7VSPbI46/OirFM/zXWOvjjpGYZDM o=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3A9WSc9BF7ShDG6JugqMR+s51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efP0aC0mNM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AAATiC9e/4wNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYEkLyQsBWwrLSAECyoKhAqDRgOLFYJfgQGIYIlMhGK?= =?us-ascii?q?BLoEkA1QCBwEBAQkDAQElCAIBAYRAAoIkJDYHDgIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhV4BAQEBAxIRChMBATcBDwIBCA4HEBoDAgICHxEUEQEBBA4FCAYNB4MFgX1?= =?us-ascii?q?NAx8PAQIMoVACgTmIYXWBMoJ/AQEFgTMCDkGDDg0LggUHAwaBOAGBUopLGoF?= =?us-ascii?q?BP4ERR4IXNT6CG0kBAQIBARiBMRgFBx8JBIJWMoIsjVySTI5wRAqCOYNogji?= =?us-ascii?q?BIopMhESafJdEgiSQBQIEAgQFAg4BAQWBWQ4kgVhwFYMnUBgNk2yDc4UUhT9?= =?us-ascii?q?0gSmLUwGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.70,371,1574121600"; d="p7s'?scan'208,217";a="415482776"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 01:05:28 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 00S15Rhb007315 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jan 2020 01:05:28 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 Jan 2020 19:05:27 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 Jan 2020 19:05:26 -0600
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 27 Jan 2020 19:05:26 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LiJgOHMfjWeVFDkzPh1AooqhriMzv2JxVM6iRB5LkyXHYeILlfglo8ihkyAxseIPycCPYEBSXMHV/Rg5Riie8fCz6Gr3Z9ngsYrv+M0Wt6owOa9xUtuf0fBWhlCtjuY8cMLRADCOM8UTioq1iBzntmqIZJAdjX1YDSJtfq8Vc2/a5IJOpx1AbSOPJQE5DohD5f6sZDfLxTn0hIWR+scC9PeKFwDpPXWtJWdfuN8plIR69iplcCDVAqpecQWXLCJU5yGciLzFEfXVKyiVS8RofQDn2xkLmwVOdSbVP5BDTM6EwEQlcMiPp5DkAttjd56oW8BHNlQXlRj7qYtnlgcogg==
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=4yrguNA2YbsyANDV36ITdhVeqizAuDOqMsG8BYHhsaI=; b=FSD8cq+yUpnzg4IZFaHhaLNGD0onTqdzdXxdfMePzqM4eLrKYCKkQ06wg/ghqHBVKviuDrGQi4OmYuVSmoEfB9t30PN0pwvhnlpztCluS0IUa3Hvghrz85hEp4U/6yqh1VKBD01IHhSk/71OuwZlv6S2lifSCsVYtrEjt4OU5xcozcyGBeg7Pg/htesskNB1Kz384U4xFLdRcJwLGgZSbQaagpqH3j26+7VkORbJ+NFnEzqPbhQiY8zjYYHT5SqOZyTIUFCGfT0Ob7pxiUlS6V53UJEUMp/QXGAs7uNWeepfoQYZka7AKyPpiPsJWPUQTyZRGbqOLt+HnFgz9mAckA==
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=4yrguNA2YbsyANDV36ITdhVeqizAuDOqMsG8BYHhsaI=; b=kzRfoonLBE4Kh/bkIn8zF2pZsIBRoKew/orhcSb7WPeJ1UqCzRd7P4M7cpnnFu+3SuarlrKWzRzHkmytAu74+dG9UDZc7o8iYCUwOHbxNzl5MCIKoOlgJIAr+IYPtd8I8APZ11nxAfMqzuQ5vV6ktbDnMAaGSijoHRr8iOX6O0Q=
Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB3847.namprd11.prod.outlook.com (20.178.239.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Tue, 28 Jan 2020 01:05:25 +0000
Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2665.026; Tue, 28 Jan 2020 01:05:25 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Configured receiver capability exchange
Thread-Index: AdXL4TILBTPP/wetTxqO44ff1VxXqQJkujEAAAB2/NA=
Date: Tue, 28 Jan 2020 01:05:25 +0000
Message-ID: <BYAPR11MB2536674E256F0DF3728F3D2CA10A0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <BYAPR11MB25368EF3AFE9E2CBF396B8D0A1370@BYAPR11MB2536.namprd11.prod.outlook.com> <9E429FFB-23F2-4005-9153-A35B4231E965@gmail.com>
In-Reply-To: <9E429FFB-23F2-4005-9153-A35B4231E965@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.68]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f4c1c82f-20df-4ce7-a07b-08d7a38e2880
x-ms-traffictypediagnostic: BYAPR11MB3847:
x-microsoft-antispam-prvs: <BYAPR11MB38475D48B3C9459315C83F29A10A0@BYAPR11MB3847.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-forefront-prvs: 029651C7A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(376002)(396003)(39860400002)(189003)(199004)(186003)(66946007)(33656002)(6916009)(86362001)(66446008)(76116006)(64756008)(55016002)(3480700007)(66556008)(6506007)(53546011)(9686003)(2906002)(66476007)(478600001)(7696005)(4326008)(71200400001)(26005)(66616009)(81156014)(81166006)(8676002)(316002)(8936002)(52536014)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3847; H:BYAPR11MB2536.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: BCL:0;
x-microsoft-antispam-message-info: wWMAXXinnkUg5gXNDjB6OuufeuK2XdRzvEJvk37jHy01CpDlTGNidi8/WHqM9KLQX7eQwrl0UXwvR58D7Q5TlIawQKr/BRZPeuNpWGHx+owrdMa8vMxnkx5wI59xKeHuvfPIaOxdD3wLbIEEMvmbmMW9IZuXRXePtwHbqRzzATJbhqN1IuL2ab7OrhaCFUW83oB2Tkhoas30G8xd+8SaxXUGmYBQXdqx75KdAvus1K2TDrxWCj2R9jRqqnQ9W7TpgekjlH/dwUDuhzvwN6L/80N3KwoTVLXxbjUuljmAZyxqTcse60dcM/KakjHsQjT82uvwbO7+yLusXZaCFm458mrxlrn/T2Jmm4d7JVnyri3h/X9TYpluql6N40EmklCE9D8HPhFexaLGfwic1tJBwA4fjYJzVmcjySapsxu55hjslDPnhNpzoSKwmUbt/AOhU0SKS4eAaEKmpdNnxMbtvSFtQnw/3EUMuaWtDJZr2i4YN+4xBhDDJLIcnh9ZlYIzzGQrKURykcsMqMzWhjOM1g==
x-ms-exchange-antispam-messagedata: hxiKY21YJhTuKxEaCvW/ED7RwTZ1ZjO7rKPl8wEWf2hzO0ezpjwm7GoL5GYqZ6vQUnsZVswNtNx8i6lWZTagvSUPtVyghs1YN0SWfX+B5j3hCe5D02r+kLiluh6/Te7O45uZzaOWF08k9ssX0GFS9Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0528_01D5D54C.FB298250"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f4c1c82f-20df-4ce7-a07b-08d7a38e2880
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 01:05:25.5177 (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: IP3SahDIrie0G81H8QNmryX6s+QuisPW2LQ/FfIhuicmPqZpGy5XOP7SRA0rVs53
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3847
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/lhjb-YrHD6PibRcpGNjGUt-ze3Y>
Subject: Re: [netconf] Configured receiver capability exchange
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: Tue, 28 Jan 2020 01:05:33 -0000

From: Mahesh Jethanandani, January 27, 2020 7:45 PM



Hi Eric,

 

Specifically to your suggestion towards draft-ietf-netconf-https-notif, and its ability to learn the receiver capabilities …

 

As you might have seen, we had suggested a rather simple mechanism to learn the capabilities of the receiver that involved a GET with a specific Content-Type to invoke a response that returns the metadata we desire. All the method requires is a HTTP(S) server at the other end. If the Content-Type is not supported by the server, the server will return an error. We like it for its simplicity.

<eric> I can see this working.  Of course it does assume the HTTP(S) server at the other end, which simple receivers might not want to include.  I leave it to the WG to decide the best method for Client capabilities exchange might be.

 

Your suggestion is of using <subscription-started>. Does that not involve having a RESTCONF/NETCONF server support on the receiver? 

<Eric> No, all you need is an application which can reply to the notification.

 

If <subscription-started> is supported, does it mean <subscription-modified> or <subscription-terminated> also needs to be supported? 

<eric>  Not really.   The notifications can be silently discarded.  I.e., the notification MUST be sent by the Publisher, but may be ignored by the receiver.

 

If we do not/cannot support modification of subscription, and instead require establishment of a new subscription to learn of modifications, what would we be missing out with the GET method? Could subscription be terminated simply by terminating the session?

<eric>  Yes.

 

Eric

 

Thanks.





On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <evoit@cisco.com <mailto:evoit@cisco.com> > wrote:

 

Hi Mahesh,

 

During the IETF 106 session, there was discussion on how both a publisher might know if there is receiver support for  <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> draft-ietf-netconf-notification-messages.  Section 6 highlights several of the considerations.   Relevant are the following:

 

(a) Remote device capability discovery from the point of view of the Publisher needs to be enhanced to know if the far end can interpret notification messages type beyond RFC-5277, Section 4.

 

(b) This capability discovery question is relevant for both configured subscription receivers and dynamic subscribers.  

 

(c) The capability discovery question can be generalized beyond subscriptions, as there are many reasons to know the available capabilities of the far end.   

 

(d) Capability discovery advertisement has traditionally been discussed within transport documents (e.g. RFC-6241 Section 8.1).   

 

 

Based on (a)-(d), coming up with a transport independent point-solution within  <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems overkill/heavyweight.

 

I was fine with letting this remote capabilities discovery question sit for a while.   However  <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01> draft-ietf-netconf-https-notif shows that we now must address this question.  Specifically should the diagram section 1.4.1 show this capability exchange?  

 

It turns out that independent of draft-ietf-netconf-notification-messages, there several questions in draft-ietf-netconf-https-notif which need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined notification #1" anyway.  These questions are:

  (1) Does the targeted HTTPS receiver support configured subscriptions?

  (2) Can the targeted HTTP@ receiver accept a new subscription as described in a <subscription-started>?

Only if these questions are "yes", should the <subscription-started> be responded to with an "OK".

 

Add to this a third question driven from (a)-(d):

  (3) Does the receiver support the message type within "draft-ietf-netconf-notification-messages"?

 

A strawman way to handle the all three questions within draft-ietf-netconf-https-notif would be to respond to a <subscription-started> notification with an HTTP Status 202 (Accepted)" acknowledgement.  This 202 would include body elements listing supported receiver resources.  Maybe something YANG encoded via ietf-yang-structure-ext containing:

 

      <foo xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

        <capabilities>

          <capability>

            urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

          </capability>

        </capabilities>

      </foo>

 

What do you think of this approach?

 

Eric

 

Mahesh Jethanandani

mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>