Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 25 February 2020 22:07 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 0EA333A16C5 for <netconf@ietfa.amsl.com>; Tue, 25 Feb 2020 14:07:08 -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=MF6xwxtj; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=SAMJsWG8
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 Tyi0Q-EIAF80 for <netconf@ietfa.amsl.com>; Tue, 25 Feb 2020 14:07:05 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0863A16BF for <netconf@ietf.org>; Tue, 25 Feb 2020 14:07:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45024; q=dns/txt; s=iport; t=1582668425; x=1583878025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pUZ7hf+6ZlY49UVbIChd18KEREYj+z9EPtSryCX6W1g=; b=MF6xwxtjpFzg6vdGJHzhaBFkgYlaVB+ZxrPYtCRvAB5W95fblKPjjUjS hZg7sYI/W5G5R5nv65vVJxS1O5Aw48lTYcFeKigRUtQsQn0aZz0ftZbxC LGo4ffBzDMMwB93j1JGfUinh2k9BV9YUA2a8AQO3l+PzfcOylL12fXDIr M=;
X-Files: smime.p7s : 3975
IronPort-PHdr: 9a23:Cp6qBxKOBSiqNEIrPdmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeCtad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXEDlK//2Ryc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CuAgCjmVVe/4sNJK1lGwEBAQEBAQEFAQEBEQEBAwMBAQGBe4ElL1AFbCstIAQLKgqECoNGA4pzgl+JY44xglIDVAIHAQEBCQMBASUIAgQBAYRAAoF+JDgTAgMNAQEFAQEBAgEFBG2FNwyFYwEBAQEDEhEKEwEBNQIBDwIBBgIOAwQBAQ4TAQIEAwICAh8RFAkIAQEEAQ0FCAYNB4MFgX1NAx8PAQ6TAZBnAoE5iGJ1gTKCfwEBBYEzAg5BgwoNC4IFBwMGgTiBU4pRGoFBP4ERR4JMPoIbSQEBAgEBGIFLKwmCWzKCLI1sgnmPeI55RAqCPINwgjuBJopehFKCSZhljnCBTYcvgi6QHQIEAgQFAg4BAQWBaSKBWHAVO4JsUBgNjh0MFxWDO4UUhUF0gSmPJgGBDwEB
X-IronPort-AV: E=Sophos;i="5.70,485,1574121600"; d="p7s'?scan'208,217";a="436865882"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Feb 2020 22:07:03 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 01PM730E002790 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2020 22:07:03 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; Tue, 25 Feb 2020 16:07:02 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Feb 2020 16:07:01 -0600
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Feb 2020 17:07:01 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ar21z3sYCS+s9Oj5Atb2N6QsfL6QsZsO4eACMfkCN8dJLyRdhSvNJlsmn00vd5iCN8XW5NXtK44y6/EQOca2EWmF9RLQSEjj+h66vYvt3f6vH4F4ORKCtX5nSVMZDxLnacwUn+IUsTOvYCfGGFLcTMkPRb9WhCzGLiVN0/bqhjQ4w8mT7pCUOvPHg3h3YX6zZ3HBB3WRxNxzHn6tFVfSrGZrM8fAF37HWlp0WemaWPpMpC19rXDWS+d0POL+Xee/VfdThUj84nBxeLV2LdO9pUQzcSnWephCE06xFL61ofbei9Ytft0P74oQ6r+HX05j8nnKF08wZf6haF1s1kgWog==
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=GGMTQoxENiEezL/KDJ0WHtzYIC1RPj3ij+0Wm51JwLM=; b=UHWGKXtlsplOMVvSxiaJ4o6f8AGDtwZ1JlqEBz28OSQprBwo2GiOjpUHhNgVGwGF+cGYoGeuciFKyJybE8mtgxQVb71N0hb03aDPjuT3RB1MThxPCww/yRQOqNSgcaahQky2frq7Psl+hkYQuOsl3/Cd+erEUOSEAy9Ov00H0aCTJMIwHJ5dsbdBbHKUm2DjVzCHUv5FiisXrkM9G5o8woIwoMrYXCzyI/mBESApR5s8/gWX3MFd93GXHXKc1CkzT3HeX4T+OElaI7TVRbOZrM3ZmEmocbqq1Mz28+PpV5qXZPzSeo5rpQSAAWZg49CdQoPExsJIiSK6QUID7rOs3g==
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=GGMTQoxENiEezL/KDJ0WHtzYIC1RPj3ij+0Wm51JwLM=; b=SAMJsWG8M2p7naH6p9AOFdx/L27klHfshQJzFXsPWTDh+xvlrgBuzXgTHyJvKoKOfTC0B6J9LAO2r3wy3LCYWnb5+ZH7zrAo/LojBRD38eMA7Ri3xJkyvyjLUiITbwniNCOAM3MtDkXxzkoycpV0GRFJPTcHMU0ire+/0IDDwGg=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3044.namprd11.prod.outlook.com (2603:10b6:208:7a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.22; Tue, 25 Feb 2020 22:07:00 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::ec9a:6707:d1ba:ce30]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::ec9a:6707:d1ba:ce30%7]) with mapi id 15.20.2750.021; Tue, 25 Feb 2020 22:07:00 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Qin Wu <bill.wu@huawei.com>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)
Thread-Index: AdXrBac3eal5GwGBScmdBP+kDouhpwBIUAJQ
Date: Tue, 25 Feb 2020 22:07:00 +0000
Message-ID: <BL0PR11MB3122691A8C5AE888FC950B04A1ED0@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <B8F9A780D330094D99AF023C5877DABAAD4D630C@dggeml511-mbx.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAAD4D630C@dggeml511-mbx.china.huawei.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.73]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 980f7425-52c3-4c68-1018-08d7ba3f09d9
x-ms-traffictypediagnostic: BL0PR11MB3044:
x-microsoft-antispam-prvs: <BL0PR11MB3044D6F87BD940714C41D18EA1ED0@BL0PR11MB3044.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2657;
x-forefront-prvs: 0324C2C0E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(189003)(199004)(8936002)(66476007)(110136005)(86362001)(66556008)(26005)(55016002)(66616009)(52536014)(15650500001)(316002)(66446008)(64756008)(66946007)(2906002)(186003)(76116006)(9326002)(71200400001)(9686003)(33656002)(7696005)(81166006)(53546011)(478600001)(4326008)(5660300002)(6506007)(8676002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3044; H:BL0PR11MB3122.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: 8D0vOBjwLEE+Gt2sXKm/9Df9wVivbxVo0bahV7dQWWlEiVapTcgk9qXe9h97TMc43C59ojbBLmcHma7RTRTjj5fHfjQlkR7bcfAYvgcdzKQoJKJWJggs3e5oAScFfELHyE5y1+gCm14BF3A5Y6uaJWIkI3pjokSYFTmdaxTe7gQ6aiz5miVINML6Kl8F8BHyL+7gjBMQyR4IrNl1jhHh9VP36nnoJU40qKwMBBP46frm/I9tNtpVTwT/g52HA0yl7jqxRHsfiWtwz6PnDDt5xYefeMpr372uQoJst656ipdB2odjNHg2VLazJ7zHdMbd8C+7gtfC8YkuEF8fBRXK/z66XrWisnrY10HS83FuX+bjNELbWNpSWBkYxns0HbkA3SO3qcJOBDDFxYxNFGK/qroH7oyp7Lzp6BQ/JHlm1z8rX5vDwibvuVk9MxFXZbpOW6u63Ih9bcdWu48p0l+fGiu/aHhmwp3rLPLhOGejCrbItlU9NzzviRKnRcf0Aqj9BE3g9N0s4NR8gcGh/B8w9A==
x-ms-exchange-antispam-messagedata: YqCK+4SfwscWlJUpQk3Yd49zlZA+6IBGOVMFTN+Mo0aWr/J85FPskqmzKWHJ2raELT/jZC4RpmC/nj7GhQDuTyQ9SQjNldFeXqBYg7BPk71hxOrtW13UJ8l6XolVn1F5alCfXflJiQmDHmJUp7ChJw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary="----=_NextPart_000_0220_01D5EBFD.FCF251D0"; protocol="application/x-pkcs7-signature"; micalg="SHA1"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 980f7425-52c3-4c68-1018-08d7ba3f09d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 22:07:00.5531 (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: xl+tOiy4WBkfUa6C4qHzylCijvwAX3GFOY7eqgMQZOh6yUu3VM7dvtx27eYXqhyr
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3044
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/XHGlv_xD88wQmuhya9LFadwMHfE>
Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: 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, 25 Feb 2020 22:07:08 -0000

Hi Qin,

 

From: Qin Wu, February 24, 2020 6:33 AM



Eric:

I am wondering if a set of notification per message can be compressed before being bundled, if the answer is yes, I think data compression algorithm should be specified.

<eric> I hadn't planned that we would need to support per-YANG-Notification compression prior to bundling.  Can you articulate any requirements here?  

 

In addition, subscription mode or type (periodical, on change) can be included as well.

<eric> As period or on-change is known by the notification type enclosed,  i.e. <push-update> or <push-change-update>, this is already supported.

 

Eric

 

-Qin

发件人: Eric Voit (evoit) [mailto:evoit@cisco.com] 
发送时间: 2020年2月21日 21:51
收件人: Qin Wu <bill.wu@huawei.com <mailto:bill.wu@huawei.com> >; Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com> >
抄送: netconf@ietf.org <mailto:netconf@ietf.org> 
主题: RE: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)

 

Hi Qin,

 

If the WG wants it, I have no problem adding this leaf-list.  Good catch.

 

Beyond that, do you have examples of such transport specific objects?   Transported objects would be named within the notification itself.  And the prefix associated with the object should be mappable.  

 

I believe it should be up to the receiver to correlate the prefix to the right model. And putting more into each notification would make for overhead.

 

Eric

 

From: Qin Wu, February 20, 2020 8:30 PM

Yes, what I like to see is to have a leaf-list of augmenting models.

If a set of specific transport objects within the model can be targeted, that will also be nice to have.

 

-Qin 

发件人: Eric Voit (evoit) [mailto:evoit@cisco.com] 
发送时间: 2020年2月20日 0:07
收件人: Qin Wu <bill.wu@huawei.com <mailto:bill.wu@huawei.com> >; Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com> >
抄送: netconf@ietf.org <mailto:netconf@ietf.org> 
主题: RE: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)

 

Hi Qin,

 

The parameter "yang-module" is just identifying the YANG module which contains the definition of the encapsulated notification.  I.e., some reference to the transported objects is needed.

 

That said, the current solution doesn't provide a good solution when new objects are augmented into an existing notification.  So what you bring up is a valid concern.   Do you have suggestions on methods to handle more complex augmented notifications?  One possibility is to have a leaf-list of augmenting models.  Looking at the definitions of these models would allow extraction of the prefixes used.  There are more complex possibilities here, however each adds to the payload.   (It is not an accident that IPFIX has template records.)

 

Eric 

 

From: Qin Wu <bill.wu@huawei.com <mailto:bill.wu@huawei.com> > 
Sent: Thursday, February 13, 2020 5:09 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com> >; Eric Voit (evoit) <evoit@cisco.com <mailto:evoit@cisco.com> >
Cc: netconf@ietf.org <mailto:netconf@ietf.org> 
Subject: RE: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)

 

Eric: 

Why structure message should tie to a single YANG data module with “yang-module” parameter, is this too restrictive?

 

-Qin

发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Mahesh Jethanandani
发送时间: 2020年1月28日 8:19
收件人: Eric Voit (evoit) <evoit@cisco.com <mailto:evoit@cisco.com> >
抄送: netconf@ietf.org <mailto:netconf@ietf.org> 
主题: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)

 

Hi Eric,

 

This e-mail triggers two responses. Let us deal with draft-ietf-netconf-notification-messages here, and I will bring up comments/questions related to draft-ietf-netconf-https-notif in the other thread.

 

You have indicated a desire that receiver capabilities should be documented by the transport specific draft, e.g. draft-ietf-netconf-https-notif, and not this draft. As such you believe that the draft is ready.

 

To the WG, the authors have indicated a desire to wrap up this draft, and would like us, the chairs, to issue a WGLC on it. Before we do that, we wanted to ask if the WG believes that the document is ready, and that there are no more issues that need to discussed/addressed by draft-ietf-netconf-notification-messages document at this time.

 

Cheers.

 

Mahesh and Kent (as co-chairs).

 

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>