Re: [netconf] Configured receiver capability exchange

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 28 January 2020 17: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 25AD0120815 for <netconf@ietfa.amsl.com>; Tue, 28 Jan 2020 09:05:53 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=GtjhitMC; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=E25Ha0bW
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 O5Ryd62E5YzG for <netconf@ietfa.amsl.com>; Tue, 28 Jan 2020 09:05:50 -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 E16B01202A0 for <netconf@ietf.org>; Tue, 28 Jan 2020 09:05:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14160; q=dns/txt; s=iport; t=1580231149; x=1581440749; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WMWOXpY6SKcu8A49IEGeMzttiFyLm5yPOVGAm+rmPvM=; b=GtjhitMC0FW2GRBNTjFqdYUTNESAiJOPfcdjLIPRtBLcLwSSldvfZBUZ ejb/sRKXd1NqWuOssds2Bbc3gFhRs6+pXlE8KhxT8gRjWKGDH3uXWbV2O 6m3pcQJayAVhVsbHZnVQqUjVcrYzkoRkJt/tE4Quml8GT+mBJslb1hFKO w=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AAUF48x9XUY8bMf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcObDkznBPXrdCc9Ws9FUQwt8g=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBQCNaDBe/5FdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFbCstIAQLKgqECoNGA4sVgl+JYY4uglIDVAIHAQEBCQM?= =?us-ascii?q?BASMKAgEBhEACgiYkOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQIBEhEdAQE?= =?us-ascii?q?3AQQLAgEIDgcDDR0CAgIfESUBAQQOBQgGDQeDBYF9TQMOEQ8BAgyiVwKBOYh?= =?us-ascii?q?idYEygn8BAQWBMwIOQYMODQuCBQcDBoE4gVOKSxqBQT+BWIIXNT6CG0kBAQI?= =?us-ascii?q?BAYFJGBWCeTKCLI1coTxECoI5g2iCOIEiikyERJp8l0SCJJAFAgQCBAUCDgE?= =?us-ascii?q?BBYFpIoFYcBWDJ1AYDY4dg3OFFIU+AXSBKYt3AYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.70,374,1574121600"; d="p7s'?scan'208";a="696695086"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 17:05:48 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 00SH5mHx012706 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jan 2020 17:05:48 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 Jan 2020 11:05:47 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 Jan 2020 11:05:45 -0600
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 28 Jan 2020 11:05:45 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=amUIZtMEGNcbkKgWbmOag9noiAost6vRXthsSEgemEA79U5T4U1ybMsCXCsFDN2TR3xmQWCEtw6lz6qmsY6ExZCd5xU/IN8PxZsA+MSnWmjb+2AKKHUrBwvRn4uscu415db1q8pgMDFqtWJ138HEcv/KRThJwS1nxf4FEwEW1Qp4AbuJHEU/As+kV+E67o7qgalp63W3GMF/kRlGSiblGdXxRKjf/5KczBOKXU7uJYjIfMeevCcFg3Ak7e4f57eAbXYqm+yVOaFqs8vCzJasOgGcLXz19zrRbB/PxKKIxuLMfRHfwxqb4Vyj6OoDJzkKghyTwQuerAquApUmCUVLfQ==
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=aFwiuInD64c9hgOYG5Mz7QQ3WXWAqoBELZdlG0Z9Z8k=; b=M7Hc795PEQiNDLy4AU2Le69DC1wxx2ts9BvB5410vOguzsTHbflc8+l1OaU0Tp9uNG9DMjkesdG6ZefvNSKVkTI0D32i7VOjWcf8BDhInZ9umMAAUcyYas+I7nvdDpXAU9odASIPJlpC3zmUMkYQbisgvIrMD9UA2YpnXeclIXwlrnq7ugVcBgxvdvotyZKLhWdcs+HCrEpO9koZnWGI6EA+zzRrBnjrQbmD8mD6wRuQkp535xYQVA4ATgnXWW5eVVuoj/H22/RVhjCis9jy+e7IZKcVqaKvRWn3JDGIsy/EMlu9orveiHwwP/9/5XA2b3R7FvztNJa2KWFvv8VAjg==
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=aFwiuInD64c9hgOYG5Mz7QQ3WXWAqoBELZdlG0Z9Z8k=; b=E25Ha0bW6plHXYOe9vx28h4L9COTYu7VOKPKLHdoGVBYTK/ik+sTbZA/A1PpzMyuvN+SRXmYJ/V7NW1lTmxDFiq8iXObP1ZyDI8Qx8RrsrP9PxwDmaXP7QqsX1lL7Uhq/UmscShNKEa6yr4abO8dOY0uRN8R9A4EUo3R+DwI2M8=
Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.19; Tue, 28 Jan 2020 17:05:44 +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 17:05:44 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "mjethanandani@gmail.com" <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Configured receiver capability exchange
Thread-Index: AdXL4TILBTPP/wetTxqO44ff1VxXqQJkujEAAAy/zYAAEOPWUAADSVoAAAAey9A=
Date: Tue, 28 Jan 2020 17:05:44 +0000
Message-ID: <BYAPR11MB2536327BCBF0A2DF91E78724A10A0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <9E429FFB-23F2-4005-9153-A35B4231E965@gmail.com> <20200128.074935.2293026921027473843.mbj@tail-f.com> <BYAPR11MB2536E16646834EBB9BFF8E3DA10A0@BYAPR11MB2536.namprd11.prod.outlook.com> <20200128.172718.208580931536379456.mbj@tail-f.com>
In-Reply-To: <20200128.172718.208580931536379456.mbj@tail-f.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.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5d05d184-3022-4a96-cd0b-08d7a414502f
x-ms-traffictypediagnostic: BYAPR11MB2536:
x-microsoft-antispam-prvs: <BYAPR11MB25363E0BF3577AA85A6AEB80A10A0@BYAPR11MB2536.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 029651C7A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(346002)(366004)(396003)(199004)(189003)(66446008)(64756008)(316002)(71200400001)(76116006)(6506007)(53546011)(2906002)(66556008)(66946007)(66476007)(66616009)(33656002)(6916009)(478600001)(54906003)(7696005)(26005)(4326008)(81156014)(8676002)(86362001)(81166006)(186003)(5660300002)(52536014)(8936002)(9686003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2536; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: ycQg9p5D+izl0BPMkoUe22UEYRjoanaQf8UoH5H/ox/Ov4JM/2n/ocbxPLemw0p7EwfZ7Lcc3UN1cIfY+HTvbSUPg5iCc+HIXZMHqcF84m6v0VHXmJdBLFk2sSDSrzZ/F8OLn2unoNskMozJfP6kN/ZJCck3YYazhior6gvLg6dx86UAW7lEtj1QIIlwxltNFAHNJKDymTNz71lHUjSHXVieiPpL5z06ylix10A3MvSUKCVYniwQZLkrm95iHQHq3xa3qSIUxl6LQ5lzuYYUH92aaVngSF091hGfbg1G5XbafV9sDkUbgOsAI/CB4oRge1o/jzRtLcQYQr9UcxXqRJ2cx4g+IAVwZdcviIv5fGjkHB8c3WSV43j6Od1Qr3Ag0M8LVoC1I/AGxCwZb4h0ORHBFfQ4tnfbrusA9MYzsam/QOmqwQNjBIDbMT8kBF1pVeM98TsyC0+1vXpS5LIQcTUpw7bU2iiTBCU0Y7ZsVCbI5JRUb93zDKSC/AJpO5s4l+8yf+eoRKg0xroSusP6mA==
x-ms-exchange-antispam-messagedata: wDqTM/dgIKy0T7+PLWDIvUDbEAQcwztAWeTlUVtcBLKSEgLpXZeGQFKtSFulBAdrgh69KyW91TyEulR0I6T1ABUG8/d27LvDyhONIrpir0ANbAglTFucCtQ5DanFveknfhFvfWMlrr+qekuewmN+qA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_058A_01D5D5D0.ECFF0EF0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d05d184-3022-4a96-cd0b-08d7a414502f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 17:05:44.6316 (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: 6VDiSXPGWRjN+CKC8j5ch2B6n04dXBY+uy6sxUMJb/c89h0czJYhQitO1pUVHjNi
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2536
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRcA>
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 17:05:55 -0000

> From: Martin Bjorklund, January 28, 2020 11:27 AM
> 
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > > Hi,
> > >
> > > Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> > > > 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.
> > >
> > > I prefer this over the proposal to (mis?)use <subscription-started>.
> > >
> > > First of all, one thing you want to discover is the encoding for
> > > notifications.
> > > <subscription-started> is a notification.  So which encoding should
> > > be used to send it?
> >
> > <subscription-started> is just for configured subscriptions.  The
> > encoding is set as part of the publisher configuration.
> 
> My bad (but perhaps unfortunate that this needs to be manually configured,
> rather than dynamically agreed upon).
> 
> Anyway, the <subscription-started> notification must be sent in some
> message format.  Should it be 5277-style or draft-ietf-netconf-notification-
> messages-style?

To me it seems that 5277-style makes sense if the publisher is unsure of draft-ietf-netconf-notification-messages support.  That way the Publisher then has an option to move further YANG notifications to draft-ietf-netconf-notification-messages should the receiver indicate capability support. 

> > > Second, there is no "reply" defined for <subscription-started> since
> > > it is a one-way notification, so adding that seems a bit out of
> > > place.
> >
> > With configured subscriptions, there is a need the receiver to confirm
> > acceptance of the subscription.  Otherwise, configured subscriptions
> > becomes a denial-of-service risk.  As a result of this need, there is
> > the following text in the Security Considerations of RFC-8639:
> >
> >   With configured subscriptions, one or more publishers could be used
> >    to overwhelm a receiver.  To counter this, notification messages
> >    SHOULD NOT be sent to any receiver that does not support this
> >    specification.  Receivers that do not want notification messages need
> >    only terminate or refuse any transport sessions from the publisher.
> >
> > This is one reason we already need to do an "ok" is in reply to the
> > HTTP, even without capability exchange.  I am just thinking we can use
> > the already needed "OK" message for additional information on receiver
> > capabilities.
> 
> Not sure I follow how this is a need to do an "ok" and what that would be.
> In my understanding, when the publisher needs to send a notification to a
> configured receiver that is doing https-notif, it will open an HTTPS session
> (unless there already is one active) and POST the notification in some
> format, with some encoding.  The HTTPS server will reply 200 OK or an error,
> or perhaps close the session.

In the beginning of this thread, I suggest some thoughts on this for Section 1.4.1.  Hopefully a future draft version can clarify these specifics.

Eric

> /martin
> 
> 
> 
> >
> > Eric
> >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > Your suggestion is of using <subscription-started>. Does that not
> > > > involve having a RESTCONF/NETCONF server support on the receiver?
> > > > If <subscription-started> is supported, does it mean
> > > > <subscription-modified> or <subscription-terminated> also needs to
> > > > be supported? 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?
> > > >
> > > > Thanks.
> > > >
> > > > > On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit)
> > > > > <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
> > > > > draft-ietf-netconf-notification-messages
> > > > > <https://datatracker.ietf.org/doc/draft-ietf-netconf-notificatio
> > > > > n-
> > > messages/?include_text=1>.
> > > > > 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 draft-ietf-netconf-notification-messages
> > > > > <https://datatracker.ietf.org/doc/draft-ietf-netconf-notificatio
> > > > > n-me
> > > > > ssages/?include_text=1>
> > > > > *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
> > > > > draft-ietf-netconf-https-notif
> > > > > <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01>
> > > > > 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
> > > >
> > > >
> > > >