From nobody Mon Apr 3 09:37:13 2017 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 CD4D1129489 for ; Mon, 3 Apr 2017 09:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 bwQMuGzJ_V8y for ; Mon, 3 Apr 2017 09:37:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DC7129480 for ; Mon, 3 Apr 2017 09:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7560; q=dns/txt; s=iport; t=1491237427; x=1492447027; h=from:to:subject:date:message-id:mime-version; bh=OqQ7kOa8oy5fEd6qg/sabqH4NYIoEBd2bi0J/tavxCk=; b=WZG5/Z9BGrJ8UQkuD+BoV1mM6tA29Q2LC1ebY6Ijh0r5hWOjIlVezZYX jeRNOr/ZN8XYo+NCbmYVZ43G/js9Tt02yLPJ/DT/DUAMdXePD2DwIUbD4 9FEdVunYRXCtJZnZNWZJsFeIlD14z9yEm7NP0f1JHWhSqXHLiL29Z3BcX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQD/eOJY/5pdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgm5mYYESjW2hdoUxgg6Jaj8YAQIBAQEBAQEBax0LhUlBHQEtUyYBBBsTh34?= =?us-ascii?q?BgXOacZItilYBAQEBBgEBAQEBASKGTo8oBZxtAZJGkUWTdAEfOIEFWxVBhlmHf?= =?us-ascii?q?SmBB4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,271,1486425600"; d="scan'208,217";a="228279221" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2017 16:37:06 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v33Gb6Jb015532 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Apr 2017 16:37:06 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Apr 2017 12:37:05 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Mon, 3 Apr 2017 12:37:05 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: Configured Subscription: two receivers with different permissions Thread-Index: AdKsmHmBUI9WiXMWRBG8CFiYL5hZzA== Date: Mon, 3 Apr 2017 16:37:05 +0000 Message-ID: <4051edf591df436fb721a202dceb2e86@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_4051edf591df436fb721a202dceb2e86XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Configured Subscription: two receivers with different permissions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 16:37:12 -0000 --_000_4051edf591df436fb721a202dceb2e86XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During the IETF98 WG session, I mentioned a few issues to work through on t= he mailing list. The first is the proper behavior of a configured subscription when there ar= e 2+ receivers configured. Here for management simplification reasons, we = have been assuming the same subscription-id will be established for all rec= eivers of the same configured subscription. And that notifications will b= e sent tagged with the subscription-id. However there might be different access control permissions associated with= the different receivers (either intentionally or unintentionally). Therefo= re the security filtering process of information to each receiver might dif= fer, and as a result different push updates could potentially be sent to ea= ch receiver. Several approaches on this are: (1) Filter each receiver's updates individually. In this case the streams = notifications might vary. And if something downstream compares the differe= nt received information, they could see deltas. (2) If there are different access permissions for different receivers, susp= end the subscriptions until they are brought back into parity. This will g= uarantee that equivalent notifications are sent, or not sent. (3) Make a different subscription for each receiver so that there is no exp= ectation of comparability in the resulting streams of updates. I believe (1) is superior for the following reasons: a: Method (2) opens an attack vector where you could hijack one of the rece= ivers IP addresses and pull down the full solution. b: Also with (2) if someone changes the access permissions in the middle of= a subscription (via simple misconfiguration or rolling permissions upgrade= ) on one of the receivers, it could pull down the full solution. c: It should not be up to the Publisher to police the permissions of differ= ent receivers. If receivers choose to compare information, the publisher s= houldn't care d: For (3) forcing different subscription IDs doesn't solve anything techni= cally, and it make management and administration harder as there will be re= plicated managed objects. Any objections if we go with approach (1)? Eric --_000_4051edf591df436fb721a202dceb2e86XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During the IETF98 WG session, I mentioned a few issu= es to work through on the mailing list. 

 

The first is the proper behavior of a configured sub= scription when there are 2+ receivers configured.  Here for manage= ment simplification reasons, we have been assuming the same subscription-id= will be established for all receivers of the same configured subscription.   And that notifications will be s= ent tagged with the subscription-id.

 

However there might be different access control perm= issions associated with the different receivers (either intentionally or un= intentionally). Therefore the security filtering process of information to = each receiver might differ, and as a result different push updates could potentially be sent to each receiver= .

 

Several approaches on this are:

 

(1) Filter each receiver’s updates individuall= y.  In this case the streams notifications might vary.  And if so= mething downstream compares the different received information, they could = see deltas.

 

(2) If there are different access permissions for di= fferent receivers, suspend the subscriptions until they are brought back in= to parity.  This will guarantee that equivalent notifications are sent= , or not sent.

 

(3) Make a different subscription for each receiver = so that there is no expectation of comparability in the resulting streams o= f updates.

 

I believe (1) is superior for the following reasons:=

a: Method (2) opens an attack vector where you could= hijack one of the receivers IP addresses and pull down the full solution.&= nbsp;

b: Also with (2) if someone changes the access permi= ssions in the middle of a subscription (via simple misconfiguration or roll= ing permissions upgrade) on one of the receivers, it could pull down the fu= ll solution.

c: It should not be up to the Publisher to police th= e permissions of different receivers.  If receivers choose to compare = information, the publisher shouldn’t care

d: For (3) forcing different subscription IDs doesn&= #8217;t solve anything technically, and it make management and administrati= on harder as there will be replicated managed objects.

 

Any objections if we go with approach (1)?

 

Eric

 

 

--_000_4051edf591df436fb721a202dceb2e86XCHRTP013ciscocom_-- From nobody Thu Apr 6 12:58:13 2017 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 F32AB128BBB for ; Thu, 6 Apr 2017 12:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WVjswx-jPvQe for ; Thu, 6 Apr 2017 12:58:10 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC349129642 for ; Thu, 6 Apr 2017 12:58:09 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 21so45036733pgg.1 for ; Thu, 06 Apr 2017 12:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=uq/EzBnAOKHz0wbyfz6swjFfDmqZq7qsGw05bF+DGPg=; b=fq3E1TtCuA1m8bBFw24FTslgv41AAsXiv1cIwouaGfK1zgE67XZpU8u1Re+I+ot34s 3U4+n/Y32GhL0GOg3cI3+fH1UwM9/7pvOJevGIUGbVnFq1DT7lLK8TkD2Xdpm7BfTsT9 2knAe3p2coVvt7tBUNtJxifLJeSUXyZFPprbuUL1wtUw0b6s5kI1A6hhlkzH0KAvxK4M H7k8qkIMxj29cvki3coaRxECTZ0WLFtaIQn7bGP6z1OJtUOOrWb+1yRHYJgFCM4YMZoJ rpYb9aMbbCQDLGrnoThcWNU3yaDkhuVIBt98ySb1fNafJwLoB8cjL6/vU5D1SwTIFAJQ g0BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=uq/EzBnAOKHz0wbyfz6swjFfDmqZq7qsGw05bF+DGPg=; b=iG0YUHCOx+q+5XAhahA0Y0syCfg64Q8gGjjPaKyOwvy2DzLG8H7vJed98RBnORLZKZ VwoRZCrabLmWFX+tM58+nEpprdl0MGgkpWBPew1LiI+K+FCpdGt4XSOc0tZddMVVeOxN 8R7ghZS2t5ZKE+aJ7vRILrbBxwKkufq+akwAES/3QgE0MCW74GykBmg9i75FvyZ223WM g24qOVFBCrf3TVm5HJdxgtUiJlt7hgjYAAEGplULB2OgB2SbNMGFnZh/+fPERkKlB38N oiTywwoOQkvgF9z5KNXm1Eu7MFTxWNz4ex8G9xkaqlONiJOrDU5fnPDfiDZWqosBwzFt knUg== X-Gm-Message-State: AFeK/H2SPHN8cBktpnM52DR6KwyraitJ7nCDwhZarNneHVaQN8t9ks2an56UXV1WMonS6A== X-Received: by 10.99.173.77 with SMTP id y13mr11377145pgo.3.1491508689177; Thu, 06 Apr 2017 12:58:09 -0700 (PDT) Received: from [10.154.160.13] ([128.107.241.166]) by smtp.gmail.com with ESMTPSA id b128sm5241835pfg.54.2017.04.06.12.58.07 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Apr 2017 12:58:07 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_75643963-5064-49CC-BCC4-9C26AF9364CA" Message-Id: <780AED85-8E55-485C-A83B-FBBD0AE60460@gmail.com> Date: Thu, 6 Apr 2017 12:58:07 -0700 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] Summary of NETCONF meeting at IETF 98 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 19:58:13 -0000 --Apple-Mail=_75643963-5064-49CC-BCC4-9C26AF9364CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, Below is the NETCONF WG session summer and AIs that were taken from the = IETF 98 meeting. This e-mail verifies the discussion that took place in the room. Barring = any strong objection, the AIs identified in this summary will be acted = upon. The NETCONF session took place on Tuesday, March 28, 2016, from = 16:40-18:40 Central US Time. =20 - We had approx. 80+ participants in the 2 hour NETCONF session, - We reviewed the status of the WG, - We had a discussion on chartered and non-chartered documents. The minutes from the meeting are posted here = . The Zero Touch draft has three issues with ANIMA WG. They are documented = in GitHub, were discussed in the meeting, and will be taken to the = mailing list. The keystore model still had issue with private key. Martin and Kent to = take up the issue offline and bring the resolution to the mailing list = for verification. The SSH/TLS Client Server model has one issue which will be taken up on = the mailing list. There was discussion around implementation of both the = server and client models that should happen before these documents = become RFC. The subscription/notifications drafts are making progress. Clarification = on NACM rules changes needs to be added to the draft. Notification2 draft was introduced, and there were questions around = bundling. Eric will provide an update of the draft and socialize the = issues on the mailing list. RFC6536bis is ready for Last Call per Andy. There were no objections in = the room. The chairs will start the WGLC once the agreement is verified = on the maillist. There was discussion on the charter for NETCONF. Benoit provided an = updated charter on the mailing list which renamed the WG to = NETworkCONFiguration to separate it from NETCONF and RESTCONF protocols = and also to open the WG to any protocol that will enable data-model = driven management. References to XML have also been removed. If there = are no objections, Benoit will start the process to get the charter = approved by IESG.=20 As agreed before the meeting the datastore concept draft will be = developed in NETMOD WG as a standards track document. The impacts of the datastore concept on NETCONF and RESTCONF were = presented. Martin proposed to not change the semantics and to = introduce new NETCONF and RESTCONF capabilities, which don't break = existing functionality. People in the room supported the proposal to = develop two drafts as extensions to NETCONF (RFC6241) and = RESTCONF(RFC8040) providing the new capabilities. The two individual = drafts will be posted on the NETCONF mailing list, at which time the = chairs will start a poll for WG adoption.=20 The charter further contains a goal to develop capabilities for NETCONF = and RESTCONF to support I2RS protocol and ephemeral-state datastore = requirements. These capabilities will use the datastore concept as their = basis. The details will be sorted out in discussion with I2RS WG and the = co-chair Sue Harris. NETCONF Accounting draft will be updated to address comments and issues = raised in the room and on the mailing list. An updated draft will be = posted before asking for WG adoption. NETCONF proxy draft was presented. Questions were raised around = use-cases and what credentials will be used to establish the secure = connection. Authors to address the issues in the next version of the = draft. Regards Mahesh & Mehmet --Apple-Mail=_75643963-5064-49CC-BCC4-9C26AF9364CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii NETCONF WG,

Below is the NETCONF WG session summer and AIs that were = taken from the IETF 98 meeting.

This e-mail verifies the = discussion that took place in the room. Barring any strong objection, = the AIs identified in this summary will be acted upon.

The = NETCONF session took place on Tuesday, March 28, 2016, from 16:40-18:40 = Central US Time.
 
- We had = approx. 80+ participants in the 2 hour NETCONF session,
- We = reviewed the status of the WG,
- We had a = discussion on chartered and non-chartered documents.

The minutes from the meeting are = posted here.

  • The Zero Touch draft has three issues with = ANIMA WG. They are documented in GitHub, were discussed in the meeting, = and will be taken to the mailing list.
  • The keystore model still had issue with = private key. Martin and Kent to take up the issue offline and bring the = resolution to the mailing list for verification.
  • The = SSH/TLS Client Server model has one issue which will be taken up on the = mailing list. There was discussion around implementation of both the = server and client models that should happen before these documents = become RFC.
  • The subscription/notifications drafts are = making progress. Clarification on NACM rules changes needs to be added = to the draft.
  • Notification2 draft was introduced, and = there were questions around bundling. Eric will provide an update of the = draft and socialize the issues on the mailing list.
  • RFC6536bis is ready for Last Call per Andy. There were no = objections in the room. The chairs will start the WGLC once the = agreement is verified on the maillist.
  • There was = discussion on the charter for NETCONF. Benoit provided an updated = charter on the mailing list which renamed the WG to NETworkCONFiguration to separate it from NETCONF = and RESTCONF protocols and also to open the WG to any protocol that will = enable data-model driven management. References to XML have also been = removed. If there are no objections, Benoit will start the process to = get the charter approved by IESG. 
  • As agreed = before the meeting the datastore concept draft will be developed in = NETMOD WG as a standards track document.
  • The impacts = of the datastore concept on NETCONF and RESTCONF were presented. Martin = proposed to not change the <get> semantics and to introduce new = NETCONF and RESTCONF capabilities, which don't break existing = functionality. People in the room supported the proposal to develop two = drafts as extensions to NETCONF (RFC6241) and RESTCONF(RFC8040) = providing the new capabilities. The two individual drafts will be posted = on the NETCONF mailing list, at which time the chairs will start a poll = for WG adoption. 
  • The = charter further contains a goal to develop capabilities for NETCONF and = RESTCONF to support I2RS protocol and ephemeral-state datastore = requirements. These capabilities will use the datastore concept as their = basis. The details will be sorted out in discussion with I2RS WG and the = co-chair Sue Harris.
  • NETCONF Accounting = draft will be updated to address comments and issues raised in the room = and on the mailing list. An updated draft will be posted before asking = for WG adoption.
  • NETCONF proxy draft was presented. = Questions were raised around use-cases and what credentials will be used = to establish the secure connection. Authors to address the issues in the = next version of the draft.
Regards

Mahesh & = Mehmet




= --Apple-Mail=_75643963-5064-49CC-BCC4-9C26AF9364CA-- From nobody Fri Apr 7 07:48:36 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCC412773A; Fri, 7 Apr 2017 07:48:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149157650964.11195.1328839886873611011.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 07:48:29 -0700 Archived-At: Subject: [Netconf] Eric Rescorla's No Record on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:48:30 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-netconf-18-08: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Can you please reflow this sensibly? From nobody Fri Apr 7 08:18:26 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA81270A0; Fri, 7 Apr 2017 08:18:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149157829328.11248.4698360894116169360.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 08:18:13 -0700 Archived-At: Subject: [Netconf] Eric Rescorla's No Objection on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:18:13 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-netconf-18-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Can you please reflow this sensibly so that each paragraph is not one giant line? Editorial comments: "Working Groiup" -> "Working Group" 4. "the YANG 1.1 constructs" -> "YANG 1.1 constructs" 5. Remove "e.g." as it is redundant with "including" "Following specifications" -> "The following specifications" remove "i.e." These milestones seem crazy aggressive unless the documents are basically already done. From nobody Fri Apr 7 12:22:37 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A42FE127775; Fri, 7 Apr 2017 12:22:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149159295059.11115.10854674446373029711.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 12:22:30 -0700 Archived-At: Subject: [Netconf] Spencer Dawkins' No Objection on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:22:31 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-netconf-18-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Does "which can be used to hold onto asymmetric private keys and certificates" mean "which can be used to hold asymmetric private keys and certificates"? From nobody Fri Apr 7 12:40:47 2017 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 CA3B0126CD8; Fri, 7 Apr 2017 12:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 B8ojYEwDmXOu; Fri, 7 Apr 2017 12:40:37 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64BEB124BFA; Fri, 7 Apr 2017 12:40:37 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id g19so71597588wrb.0; Fri, 07 Apr 2017 12:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=dzGRROPFv1SnWA9EYD5PC1ELrcnoa159u+4rft8cEXc=; b=l66nYE8sQJZm9xiIDYwxot7Hqxas0DC0hneE4YouzhlpUpQYdWcOm0PyqkIpEp8MpN YSqIU/WLvV+ouodbKLL2k36b4gW5r+mHh6Op5J0jCGrWT6/J22VgYrXkTUBpqaWZdqS6 pq/PUvofOXi9tT1ljUL3/1Jqhyxl0ODAg5Z+D7BbN34XhPwwlD7qWQLNiI8ZivpID6xT sfbseIXLMWDlW2DgMIrhzobjydLoYfnKeZRcxAJos7l1KH9VukiDLAtf+OypoBCEFWjo IRXWArqnnJGEoWUjoBUdBwmPl0TJlQ4+OKdNq3NMHwl9m74a79WyvnjPfEKQVa8ele1I 0M/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=dzGRROPFv1SnWA9EYD5PC1ELrcnoa159u+4rft8cEXc=; b=NVJdknDPncjxU7kAZbrmdr9mZ2LVo5SE+jDCcrKvPEv9yLl3x41NrDeE1oRH5ML9ht ZaoLb8OsW2Znt/XykE+UvkGP8Bhy76EVoJAcDpp7pCX3PwA5XlJu55i/nEWi6uYhzlh5 6T2f/sK2WOicuDr49o8SkK/sAwCQA8KXStZUB+e+NYd46zL5i+Alufj3AxCUCBLhBpyL b+9qnLoX5uKK3s54O3niu4jhtb3aLu/LRc4g5GrkDuV9VK2F4teYzk76cSPWfep6YgAd yxcfrzqitA04FJU9VKmvZuk47gaTdLTwbyyDRtDL/TgoAfyH4hByo1wlytDF9vZ6ZKyQ LHzw== X-Gm-Message-State: AFeK/H2mBbkWUcHJNMfAhgmWbynT9hhcUZPsH/ZkURAvQWq+dX1XdWEy2dfjO8g+TcmM7w== X-Received: by 10.223.175.23 with SMTP id z23mr15889800wrc.84.1491594035911; Fri, 07 Apr 2017 12:40:35 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5B340DB3.dip0.t-ipconnect.de. [91.52.13.179]) by smtp.gmail.com with ESMTPSA id u63sm7373707wmu.22.2017.04.07.12.40.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 12:40:35 -0700 (PDT) From: "Mehmet Ersue" To: "'Eric Rescorla'" , "'The IESG'" Cc: , References: <149157829328.11248.4698360894116169360.idtracker@ietfa.amsl.com> In-Reply-To: <149157829328.11248.4698360894116169360.idtracker@ietfa.amsl.com> Date: Fri, 7 Apr 2017 21:40:34 +0200 Message-ID: <00e001d2afd6$d39bf040$7ad3d0c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJV94aC8jE4fOf9nSZTdNAAdhGhqHM/Vmg Content-Language: de Archived-At: Subject: Re: [Netconf] Eric Rescorla's No Objection on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:40:40 -0000 Thanks Eric. The documents 1-5 had indeed good progress. Mehmet > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Friday, April 7, 2017 5:18 PM > To: The IESG > Cc: netconf-chairs@ietf.org; netconf@ietf.org > Subject: Eric Rescorla's No Objection on charter-ietf-netconf-18-08: = (with > COMMENT) >=20 > Eric Rescorla has entered the following ballot position for > charter-ietf-netconf-18-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-netconf/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Can you please reflow this sensibly so that each paragraph is not one = giant > line? >=20 > Editorial comments: >=20 > "Working Groiup" -> "Working Group" >=20 > 4. "the YANG 1.1 constructs" -> "YANG 1.1 constructs" >=20 > 5. Remove "e.g." as it is redundant with "including" >=20 > "Following specifications" -> "The following specifications" >=20 > remove "i.e." >=20 > These milestones seem crazy aggressive unless the documents are = basically > already done. >=20 From nobody Fri Apr 7 12:50:02 2017 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 D0D961287A7; Fri, 7 Apr 2017 12:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 yT-MiaruapU3; Fri, 7 Apr 2017 12:49:52 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0103.outbound.protection.outlook.com [104.47.34.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785CB126BFD; Fri, 7 Apr 2017 12:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nvHLpJB7Zhlz1PvgnSEuV/g6UPuUhyZbBq1q82ljXDk=; b=ggsNdH4z/WOsRKAdjunUdW8CV7TG7pcBHo2hGEteKXLw4li+AlhMnBEI6jFaBCMq0Kn7NgId6uc9eg8qOn95W2Cgvo7t0VcpD0b0wO/TkDo+4xFcHqaAe0Iov6RXzP8+4ywAQsrUPYNDnc2Dg4L6cKA7oEiA3Yee21MG13pn7gQ= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Fri, 7 Apr 2017 19:49:51 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.1019.021; Fri, 7 Apr 2017 19:49:51 +0000 From: Kent Watsen To: Spencer Dawkins , The IESG CC: "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [Netconf] Spencer Dawkins' No Objection on charter-ietf-netconf-18-08: (with COMMENT) Thread-Index: AQHSr9RP1qf0yVMJUECGU12zo8mCtaG6DYUA Date: Fri, 7 Apr 2017 19:49:51 +0000 Message-ID: <1960EBB9-0159-43A5-AEEE-0FB49FDE0404@juniper.net> References: <149159295059.11115.10854674446373029711.idtracker@ietfa.amsl.com> In-Reply-To: <149159295059.11115.10854674446373029711.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 7:XabzGUj1Rxes+oAanU8MgjQWHrbkhk5zx4siFnZP2vr4Ik1A3346zs5jxvOZO9rGGXQDr/ctzXCwsce5i60cKeZzXSoQf+Zk14KwmIOT4WyIdSZrPzZb9LP3LjyOpA08dtkPtHWyjnE9cfjp4H7fkRUjbkqBiFDdTuXboq6bWDEv17d/cId9GNjA5wbEJNHu2Lndwo4x4ecs8OvfiLKOoDDypfYaMban/cS/N17bpqOCC+Oufx5orCCizqu5XvNjEnwYcphgGCWhIdnnuJMP6W6Y8EN54zgQIGHcbNCwBQt3w5VvILz4uwUXZx5D6jZZ1PEuf5xAGBHMTq8r2kFWcg== x-ms-office365-filtering-correlation-id: e52115a0-62a2-4fc5-cc17-08d47def4179 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(6072148); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(7736002)(25786009)(305945005)(8676002)(6436002)(229853002)(2950100002)(81166006)(50986999)(36756003)(189998001)(2900100001)(4001350100001)(53936002)(76176999)(54356999)(99286003)(6512007)(6306002)(4326008)(39060400002)(6506006)(54906002)(2906002)(122556002)(3280700002)(33656002)(6116002)(3846002)(66066001)(82746002)(102836003)(83506001)(230783001)(38730400002)(83716003)(77096006)(5660300001)(86362001)(6486002)(6246003)(3660700001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8FCE69469469CA4DA8A37AC37EF1BC60@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 19:49:51.4358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Subject: Re: [Netconf] Spencer Dawkins' No Objection on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:49:55 -0000 DQpIaSBTcGVuY2VyLA0KDQpSZWdhcmRpbmcgeW91ciBDT01NRU5UIGJlbG93LCB0aGUgd29yZCAi b250byIgY2FuIGJlIHJlbW92ZWQsDQpwZXIgeW91ciBzdWdnZXN0aW9uLCBpdCBoYXMgbm8gc3Bl Y2lhbCBtZWFuaW5nIGhlcmUuDQoNClRoYW5rcywNCktlbnQNCg0KDQoNCi0tLS0tT1JJR0lOQUwg TUVTU0FHRS0tLS0tDQoNClNwZW5jZXIgRGF3a2lucyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3INCmNoYXJ0ZXItaWV0Zi1uZXRjb25mLTE4LTA4OiBObyBPYmpl Y3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRv IGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pDQoNCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9jaGFydGVyLWlldGYtbmV0Y29uZi8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNP TU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkRvZXMgIndoaWNoIGNhbiBiZSB1c2VkIHRvIGhvbGQg b250byBhc3ltbWV0cmljIHByaXZhdGUga2V5cyBhbmQNCmNlcnRpZmljYXRlcyIgbWVhbiAid2hp Y2ggY2FuIGJlIHVzZWQgdG8gaG9sZCBhc3ltbWV0cmljIHByaXZhdGUga2V5cyBhbmQNCmNlcnRp ZmljYXRlcyI/DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQo= From nobody Mon Apr 10 08:39:18 2017 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 6C388129530; Mon, 10 Apr 2017 08:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 T4O9m1tbtsRX; Mon, 10 Apr 2017 08:39:14 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A7A12785F; Mon, 10 Apr 2017 08:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1491838754; x=1493048354; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NER20mvYNe+DXjwFpWtKTh9uSF994HI1NnQm1ZJ6+hk=; b=Q2vZfnJLxdndmFo4gvkBndIHRXIO6OwXPiiTgW4mwz9H02I1eWsBUPti TJjFdyAEGm2oPo7q0v7Y2TZSYvg9/39jHFWeAzC6ocCxtZxvxxJcNeLLD pAexLnuu2i8Clu+RLfYPPD9/wbRhGDmT6Vytsh4FwczAxwgQeUdCJFx1t w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAQCBputY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQuDZooTpx6CDyELhS5KAoNgPxgBAgEBAQEBAQFrKIUWAgE?= =?us-ascii?q?DAQEhFTYLEAsODAImAgInMAYBDAYCAQGKCw6oeYImimMBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYELhUWCBYJrhCgRAYMigl8FiSWHRowQhwCLWYF/hS6DN4Zdi2S?= =?us-ascii?q?IHB84fQglFggYFUGFEIFqIDWHMYIuAQEB?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="410211589" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 15:39:13 +0000 Received: from [10.24.49.39] ([10.24.49.39]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3AFdCl8007399; Mon, 10 Apr 2017 15:39:12 GMT To: Kent Watsen , Spencer Dawkins , The IESG References: <149159295059.11115.10854674446373029711.idtracker@ietfa.amsl.com> <1960EBB9-0159-43A5-AEEE-0FB49FDE0404@juniper.net> Cc: "netconf-chairs@ietf.org" , "netconf@ietf.org" From: Benoit Claise Message-ID: <50a12d10-b805-4fd5-1eaf-54f09065b6ac@cisco.com> Date: Mon, 10 Apr 2017 08:39:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1960EBB9-0159-43A5-AEEE-0FB49FDE0404@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Spencer Dawkins' No Objection on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:39:16 -0000 Done. Thanks Spencer. Regards, B. > Hi Spencer, > > Regarding your COMMENT below, the word "onto" can be removed, > per your suggestion, it has no special meaning here. > > Thanks, > Kent > > > > -----ORIGINAL MESSAGE----- > > Spencer Dawkins has entered the following ballot position for > charter-ietf-netconf-18-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-netconf/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Does "which can be used to hold onto asymmetric private keys and > certificates" mean "which can be used to hold asymmetric private keys and > certificates"? > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From nobody Mon Apr 10 08:41:05 2017 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 9FFA7129530; Mon, 10 Apr 2017 08:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 HgD85p68n1ni; Mon, 10 Apr 2017 08:41:02 -0700 (PDT) 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 C1C1712952C; Mon, 10 Apr 2017 08:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1452; q=dns/txt; s=iport; t=1491838861; x=1493048461; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=0rrAWlCqADZT3p4mSryP/odX+TMU5tHJPPrj1S+bdKc=; b=hDaxq04NPhbqEZZ3yS/WtiPWo9KH8dCBu6bcMsRRAi2Pv6OEg6SUemur LdgiDP9+YTMLrdyAowYiOkuMqYudOSOq50npGfmMZth2ngdP7IBHMDGDO Bz8kFHlB1MnOEufY0Ci71QGezlS89JmUF/v3zRCsovVocPNUALVekUlXD M=; X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="407223222" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 15:41:01 +0000 Received: from [10.24.49.39] ([10.24.49.39]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3AFexWa012898; Mon, 10 Apr 2017 15:41:00 GMT To: Eric Rescorla , The IESG References: <149157829328.11248.4698360894116169360.idtracker@ietfa.amsl.com> Cc: netconf-chairs@ietf.org, netconf@ietf.org, "Giles Heron (giheron)" From: Benoit Claise Message-ID: Date: Mon, 10 Apr 2017 08:40:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149157829328.11248.4698360894116169360.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Eric Rescorla's No Objection on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:41:04 -0000 Eric, > Eric Rescorla has entered the following ballot position for > charter-ietf-netconf-18-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-netconf/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Can you please reflow this sensibly so that each paragraph is not one > giant line? Not sure what you mean. Isn't the goal of a paragraph to combine related sentences? Please propose some new text, so that I see what you mean. All editorial proposals below inserted. Thanks. And more editorial changes proposed by Giles Heron have been inserted. Thanks Giles. See https://datatracker.ietf.org/doc/charter-ietf-netconf/ Regards, Benoit > > Editorial comments: > > "Working Groiup" -> "Working Group" > > 4. "the YANG 1.1 constructs" -> "YANG 1.1 constructs" > > 5. Remove "e.g." as it is redundant with "including" > > "Following specifications" -> "The following specifications" > > remove "i.e." > > These milestones seem crazy aggressive unless the documents are basically > already done. > > > . > From nobody Mon Apr 10 09:18:41 2017 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 1444312949E for ; Mon, 10 Apr 2017 09:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 giec8QLUTon6 for ; Mon, 10 Apr 2017 09:18:31 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D9A129564 for ; Mon, 10 Apr 2017 09:18:31 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id l201so34439549ybf.0 for ; Mon, 10 Apr 2017 09:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/x+LOBUSlbgFH3kCV9e1V3NckgAs2qoEadstbzs2J3I=; b=N6kWlJhDTTFPk8KnAeSMrXf7RiOkhs46XSALN5GZpKHIpX5La/HXxxxPJto3temtWC wGsu50tNSJhYtXSlFW2qR90iMWrERW3C/fJ3jONAZA52dOerfOxUMioe7kb4I1Ozn3hB RplVRuQrtcZ+wV2rKjqpu7N2T4Y4DbBxX7Al65CxQdM9i2zqPcy49oS3UyzD7qwWDeGV Uz1U9bo+RXaOhbF1rckEPuXL6lsiYGC+lCA1elOEErlIuipo/Tkw1KkZj+CD3O2uX/wb GrGhMK/OJiEfP4Sr0E+DQgeGVSQ6hK0FAMTa8+4B0qI+alCrCuFkdHrLEYaa9JzJphQ8 PbUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/x+LOBUSlbgFH3kCV9e1V3NckgAs2qoEadstbzs2J3I=; b=goInmm7k4Lksyl4vFzDQfjttGmajB/tdgddQdm4ASNSW9Z1/wN6ctsBqG7otEYRKbm NT4v7AUwwiT4Y/ggN+xF4qXcZuXfCGegYAVE/rIGW1ACUg4WPzGt7yAk8/n0yfd5Nm+e aP97R6i9o+11zYfl/xUi59DBZYcU/acHKOIu1ixVnREm3Ts1dnVEpygGfb3lFAJOEl/t 7zaqzP3uvq0o6eMoCbrSgRb1jod1YsJlqggmsPBQEjjxKCSe2TxKQf7QgaWB8+bHzkkU Dmmsi/YAboATj1WwaUIhctSrk/aKJQVMP4K3pZ5yCOhSE2mCCqEHygONT5gGZiW6FNU8 ltZA== X-Gm-Message-State: AN3rC/560fTgbbRuf/qfQfD12iWyKVHnFbDoEIO/b/N0B5BM/DlH0Mq7RRX5widNvhbc0pKP6QeboalByl1DLg== X-Received: by 10.129.76.85 with SMTP id z82mr1866564ywa.87.1491841110396; Mon, 10 Apr 2017 09:18:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Mon, 10 Apr 2017 09:17:49 -0700 (PDT) In-Reply-To: References: <149157829328.11248.4698360894116169360.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 10 Apr 2017 09:17:49 -0700 Message-ID: To: Benoit Claise Cc: The IESG , netconf-chairs@ietf.org, netconf@ietf.org, "Giles Heron (giheron)" Content-Type: multipart/alternative; boundary=001a113f238e725b87054cd2535d Archived-At: Subject: Re: [Netconf] Eric Rescorla's No Objection on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:18:34 -0000 --001a113f238e725b87054cd2535d Content-Type: text/plain; charset=UTF-8 On Mon, Apr 10, 2017 at 8:40 AM, Benoit Claise wrote: > Eric, > >> Eric Rescorla has entered the following ballot position for >> charter-ietf-netconf-18-08: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-netconf/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Can you please reflow this sensibly so that each paragraph is not one >> giant line? >> > Not sure what you mean. Isn't the goal of a paragraph to combine related > sentences? > Please propose some new text, so that I see what you mean. > I'm talking about putting line breaks every 70 characters or so, like the way RFCs are formatted. -Ekr > > All editorial proposals below inserted. Thanks. > > And more editorial changes proposed by Giles Heron have been inserted. > Thanks Giles. > See https://datatracker.ietf.org/doc/charter-ietf-netconf/ > > Regards, Benoit > >> >> Editorial comments: >> >> "Working Groiup" -> "Working Group" >> >> 4. "the YANG 1.1 constructs" -> "YANG 1.1 constructs" >> >> 5. Remove "e.g." as it is redundant with "including" >> >> "Following specifications" -> "The following specifications" >> >> remove "i.e." >> >> These milestones seem crazy aggressive unless the documents are basically >> already done. >> >> >> . >> >> > --001a113f238e725b87054cd2535d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 10, 2017 at 8:40 AM, Benoit Claise <bclaise@cisco.com&= gt; wrote:
Eric,<= br>
Eric Rescorla has entered the following ballot position for
charter-ietf-netconf-18-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-= ietf-netconf/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Can you please reflow this sensibly so that each paragraph is not one
giant line?
 Not sure what you mean. Isn't the goal of a paragraph to combine relate= d sentences?
Please propose some new text, so that I see what you mean.
=

I'm talking about putting line breaks every 70 char= acters or so, like
the way RFCs are formatted.

-Ekr

All editorial proposals below inserted. Thanks.

And more editorial changes proposed by Giles Heron have been inserted. Than= ks Giles.
See https://datatracker.ietf.org/doc/cha= rter-ietf-netconf/

Regards, Benoit

Editorial comments:

"Working Groiup" -> "Working Group"

4. "the YANG 1.1 constructs" -> "YANG 1.1 constructs"= ;

5. Remove "e.g." as it is redundant with "including"
"Following specifications" -> "The following specificatio= ns"

remove "i.e."

These milestones seem crazy aggressive unless the documents are basically already done.


 .



--001a113f238e725b87054cd2535d-- From nobody Mon Apr 10 10:33:04 2017 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 E6E64129AAD for ; Mon, 10 Apr 2017 10:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 8Dzdupooav_d for ; Mon, 10 Apr 2017 10:32:50 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB26129AA2 for ; Mon, 10 Apr 2017 10:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9461; q=dns/txt; s=iport; t=1491845570; x=1493055170; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sGp2h+I5yODV2rnqq7acU5aYRGLhqZW0hdyGIgRrwmg=; b=FB8FtLuzkCTuRXnKshZegyWtS8WgKjvVxbjPg7mFevkxFjBL/ajS7h02 QaXSQED/OUUcJOFOAswZFLydXTmW4a8ViMrNWJhEmR7fFfJudkDXhO+wO AtPzEmxSK3HjjnpqJ88lD+e8eJNGFkcU6NdTTtcYm+C6/G4QGx6HqP/0k 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAQAhwetY/4UNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5lYYELB41ykUiQI4U0gg+GJAKDaD8YAQIBAQEBAQEBax0LhRUBAQE?= =?us-ascii?q?BAy1BGwIBCBEEAQEOGgcyFAkIAQEEEwgTh34BgXWrLIp9AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYZQhHCFDIUvBZx7AZJPggiPQohjixwBHziBBVsVQYZadYciKYE?= =?us-ascii?q?HgQ0BAQE?= X-IronPort-AV: E=Sophos; i="5.37,182,1488844800"; d="scan'208,217"; a="13251719" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 17:32:48 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3AHWmDN029949 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Apr 2017 17:32:48 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 13:32:47 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 13:32:47 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: Configured Subscription: two receivers with different permissions Thread-Index: AdKsmHmBUI9WiXMWRBG8CFiYL5hZzAFhzQCw Date: Mon, 10 Apr 2017 17:32:47 +0000 Message-ID: References: <4051edf591df436fb721a202dceb2e86@XCH-RTP-013.cisco.com> In-Reply-To: <4051edf591df436fb721a202dceb2e86@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_d9a3d58867ea40fe8fdc86885c986376XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Configured Subscription: two receivers with different permissions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:32:55 -0000 --_000_d9a3d58867ea40fe8fdc86885c986376XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on silence, let's go with then (1).... If a configured yang-push s= ubscription has multiple receivers, each could get different update notific= ations if they have different access permissions. Eric From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Monday, April 3, 2017 12:37 PM To: netconf@ietf.org Subject: [Netconf] Configured Subscription: two receivers with different pe= rmissions During the IETF98 WG session, I mentioned a few issues to work through on t= he mailing list. The first is the proper behavior of a configured subscription when there ar= e 2+ receivers configured. Here for management simplification reasons, we = have been assuming the same subscription-id will be established for all rec= eivers of the same configured subscription. And that notifications will b= e sent tagged with the subscription-id. However there might be different access control permissions associated with= the different receivers (either intentionally or unintentionally). Therefo= re the security filtering process of information to each receiver might dif= fer, and as a result different push updates could potentially be sent to ea= ch receiver. Several approaches on this are: (1) Filter each receiver's updates individually. In this case the streams = notifications might vary. And if something downstream compares the differe= nt received information, they could see deltas. (2) If there are different access permissions for different receivers, susp= end the subscriptions until they are brought back into parity. This will g= uarantee that equivalent notifications are sent, or not sent. (3) Make a different subscription for each receiver so that there is no exp= ectation of comparability in the resulting streams of updates. I believe (1) is superior for the following reasons: a: Method (2) opens an attack vector where you could hijack one of the rece= ivers IP addresses and pull down the full solution. b: Also with (2) if someone changes the access permissions in the middle of= a subscription (via simple misconfiguration or rolling permissions upgrade= ) on one of the receivers, it could pull down the full solution. c: It should not be up to the Publisher to police the permissions of differ= ent receivers. If receivers choose to compare information, the publisher s= houldn't care d: For (3) forcing different subscription IDs doesn't solve anything techni= cally, and it make management and administration harder as there will be re= plicated managed objects. Any objections if we go with approach (1)? Eric --_000_d9a3d58867ea40fe8fdc86885c986376XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on silence, let&= #8217;s go with then (1)….    If a configured yang-pus= h subscription has multiple receivers, each could get different update noti= fications if they have different access permissions.

 

Eric=

 

From: Netconf [mailto:netconf-bounces@ietf.or= g] On Behalf Of Eric Voit (evoit)
Sent: Monday, April 3, 2017 12:37 PM
To: netconf@ietf.org
Subject: [Netconf] Configured Subscription: two receivers with diffe= rent permissions

 

During the IETF98 WG session, I mentioned a few issu= es to work through on the mailing list. 

 

The first is the proper behavior of a configured sub= scription when there are 2+ receivers configured.  Here for manage= ment simplification reasons, we have been assuming the same subscription-id= will be established for all receivers of the same configured subscription.   And that notifications will be s= ent tagged with the subscription-id.

 

However there might be different access control perm= issions associated with the different receivers (either intentionally or un= intentionally). Therefore the security filtering process of information to = each receiver might differ, and as a result different push updates could potentially be sent to each receiver= .

 

Several approaches on this are:

 

(1) Filter each receiver’s updates individuall= y.  In this case the streams notifications might vary.  And if so= mething downstream compares the different received information, they could = see deltas.

 

(2) If there are different access permissions for di= fferent receivers, suspend the subscriptions until they are brought back in= to parity.  This will guarantee that equivalent notifications are sent= , or not sent.

 

(3) Make a different subscription for each receiver = so that there is no expectation of comparability in the resulting streams o= f updates.

 

I believe (1) is superior for the following reasons:=

a: Method (2) opens an attack vector where you could= hijack one of the receivers IP addresses and pull down the full solution.&= nbsp;

b: Also with (2) if someone changes the access permi= ssions in the middle of a subscription (via simple misconfiguration or roll= ing permissions upgrade) on one of the receivers, it could pull down the fu= ll solution.

c: It should not be up to the Publisher to police th= e permissions of different receivers.  If receivers choose to compare = information, the publisher shouldn’t care

d: For (3) forcing different subscription IDs doesn&= #8217;t solve anything technically, and it make management and administrati= on harder as there will be replicated managed objects.

 

Any objections if we go with approach (1)?

 

Eric

 

 

--_000_d9a3d58867ea40fe8fdc86885c986376XCHRTP013ciscocom_-- From nobody Tue Apr 11 06:38:27 2017 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 31307129BBE; Tue, 11 Apr 2017 06:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 sYzhLq-lAlm0; Tue, 11 Apr 2017 06:38:21 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87106129BCB; Tue, 11 Apr 2017 06:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16214; q=dns/txt; s=iport; t=1491917900; x=1493127500; h=from:to:subject:date:message-id:mime-version; bh=Picrwg6sRyPEVDuxuUQr6MMYweLI9iaKPyW9Q/H4QwQ=; b=WYkvkUCkwd8TkVrIvjIkJE0ZKBTCcpYOWiORGbR9I67aWDxKrGwXaOvN 2eSzYxqzQoPsle2EexsxPR0JZ0SuCxYJ45fPtER9iN9GkHR5cAKsMaGL2 VXFayw8fVWSvEcsiqcWnxemDDJGth0tt/vFgeVAXlTFLPO0waxRhCPBgs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQAJ2+xY/5hdJa1TCRsBAQEDAQEBC?= =?us-ascii?q?QEBAYJuZWGBEo1ypySCD4oGPxgBAgEBAQEBAQFrKIVJXgEtUyYBBAEaigirLop?= =?us-ascii?q?6AQEBAQEBBAEBAQEBASKGUIRwhC+GDAWcfwGSVJFNlAABHziBBVsVhxuJPYENA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.37,185,1488844800"; d="scan'208,217";a="409584684" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 13:38:19 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3BDcJVu032229 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 13:38:19 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 09:38:18 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 09:38:18 -0400 From: "Eric Voit (evoit)" To: "draft-ietf-netmod-revised-datastores@ietf.org" , "'netconf-subscriptions-dt@voit.org'" , "netconf@ietf.org" Thread-Topic: Revised-datastores > tweaking yang-push to accommodate Thread-Index: AdKyyC7V30IfX/VVTuaGhstWrh/9bQ== Date: Tue, 11 Apr 2017 13:38:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_ebc2d8f81e194c22aa84dc38153f4753XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Revised-datastores > tweaking yang-push to accommodate X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 13:38:25 -0000 --_000_ebc2d8f81e194c22aa84dc38153f4753XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would be great to cover some implications of the revised-datastore work = within the subscription drafts. The goal should be the we only need augmen= t the yang-push draft with some new identities when the revised-datastore w= ork completes. To accomplish this, I believe that we should tweak the yang-push subscripti= on model by: (1) Adding a 'filter-type' identity (previously filter subtyping was accom= plished via an explicit subtree choice statement) * 'Subtree', 'xpath' would be of filter-type * New filter types (metadata?) could be augmented in (2) Adding a 'datastore-type' identity * 'running', 'candidate', 'startup' would be of filter-type * revised-datastore identities could be augmented in With such a change the yang tree would look like: +--rw filters | +--rw filter* | +--rw identifier filter-id | +--rw filter-type filter-type | +--rw filter anyxml +--rw subscription* +--rw (filter) | +--:(by-reference) | | +--rw filter-ref? filter-ref | +--:(inline) | +--rw filter-type filter-type | +--rw filter anyxml +--rw (target) +--:(datastore) | +--rw datastore datastore-type +--:(event-stream) +--rw stream stream-type I believe such a restructuring should allow the growth of new filter types,= streams, and datastores purely though the addition of new identifies. Thoughts? Concerns? If no, I will submit a new version of draft-ietf-net= conf-yang-push-06 which matches to this later in the week. Eric --_000_ebc2d8f81e194c22aa84dc38153f4753XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It would be great to cover some implications of the = revised-datastore work within the subscription drafts.  The goal shoul= d be the we only need augment the yang-push draft with some new identities = when the revised-datastore work completes. 

 

To accomplish this, I believe that we should tweak t= he yang-push subscription model by:

 

(1) Adding a ‘filter-type’ identity &nbs= p;(previously filter subtyping was accomplished via an explicit subtree cho= ice statement)

·       ‘Subtree’, ‘xpath’ &= nbsp;would be of filter-type

·       New filter types (metadata?) could be augmen= ted in

 

(2) Adding a ‘datastore-type’ identity

·       ‘running’, ‘candidate̵= 7;, ‘startup’  would be of filter-type

·       revised-datastore identities could be augmen= ted in

 

With such a change the yang tree would look like:

 

    +--rw filters

    |  +--rw filter*

    |     +--= rw  identifier        filter-id

    |     +--= rw  filter-type       filter-type <= /o:p>

    |     +--= rw  filter           = ;     anyxml

    +--rw subscription*

         &nb= sp; +--rw (filter)

         &nb= sp; |    +--:(by-reference)

         &nb= sp; |    |  +--rw filter-ref?   &nbs= p;     filter-ref

         &nb= sp; |    +--:(inline)

         &nb= sp; |        +--rw  filter-type = ;      filter-type

         &nb= sp; |        +--rw  filter &nbs= p;             =  anyxml

         &nb= sp; +--rw (target)

          &n= bsp;          +--:(datastore)

         &nb= sp;           | &nbs= p;   +--rw datastore   datastore-type

         &nb= sp;           +--:(ev= ent-stream)

          &n= bsp;            &nbs= p;    +--rw stream       s= tream-type

 

I believe such a restructuring should allow the grow= th of new filter types, streams, and datastores purely though the addition = of new identifies. 

 

Thoughts?  Concerns?   If no, I will = submit a new version of draft-ietf-netconf-yang-push-06 which matches to th= is later in the week.

 

Eric

 

 

--_000_ebc2d8f81e194c22aa84dc38153f4753XCHRTP013ciscocom_-- From nobody Tue Apr 11 07:38:20 2017 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 F3378129B23; Tue, 11 Apr 2017 07:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 ttb6NZhqQwHH; Tue, 11 Apr 2017 07:38:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC54129BEC; Tue, 11 Apr 2017 07:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16942; q=dns/txt; s=iport; t=1491921491; x=1493131091; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=vOoXZ+ZAguxMaBX581ZAZGyGkT854Gcgn8YGfTwQHNA=; b=asqynV8ac1TqCrDsZ8j0OI+BmXkFHntJtCsUQsXL86pNX9ItEsSop6xn JOFsDoxCato+0cJL9SJnnA1LEKe/Y9N2VyBC87+47cZrFqndXoet+q/VE ZpDEP0l0NNZy6wKFKPqTTuby0V0lWNfjNYeFC/Swe6tH7wIJc1lF9JK0H M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQBB6exY/5JdJa1TCRsBAQEDAQEBC?= =?us-ascii?q?QEBAYJuZWGBEo1ykUyVWIIPhiQCg2E/GAECAQEBAQEBAWsohRUBAQEBAy1cAgE?= =?us-ascii?q?IFRAhMiUCBAEaigirNIp+AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZQhHCEL4YMB?= =?us-ascii?q?Zx/AZJUkU2UAAEfOIEFWxWHG4k9gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,186,1488844800"; d="scan'208,217";a="409614267" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 14:38:10 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3BEc97a001555 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 14:38:10 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 10:38:09 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 10:38:09 -0400 From: "Eric Voit (evoit)" To: "draft-ietf-netmod-revised-datastores@ietf.org" , "'netconf-subscriptions-dt@voit.org'" , "netconf@ietf.org" Thread-Topic: [Netconf] Revised-datastores > tweaking yang-push to accommodate Thread-Index: AQHSstE9Z5LNuTuTiUmLOxJcXg3+dw== Date: Tue, 11 Apr 2017 14:38:09 +0000 Message-ID: <5140d5635b564d58b72fff100252b0cf@XCH-RTP-013.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_5140d5635b564d58b72fff100252b0cfXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Revised-datastores > tweaking yang-push to accommodate X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:38:13 -0000 --_000_5140d5635b564d58b72fff100252b0cfXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I should have put in the 'subscription-config' container to make the tree r= eflect this (added in-line in blue below). Note: per the other part of re= vised-datastores, it would be great to merge the separate config and operat= ional data. But that is a different issue. Eric From: Eric Voit, April 11, 2017 9:38 AM It would be great to cover some implications of the revised-datastore work = within the subscription drafts. The goal should be the we only need augmen= t the yang-push draft with some new identities when the revised-datastore w= ork completes. To accomplish this, I believe that we should tweak the yang-push subscripti= on model by: (1) Adding a 'filter-type' identity (previously filter subtyping was accom= plished via an explicit subtree choice statement) * 'Subtree', 'xpath' would be of filter-type * New filter types (metadata?) could be augmented in (2) Adding a 'datastore-type' identity * 'running', 'candidate', 'startup' would be of filter-type * revised-datastore identities could be augmented in With such a change the yang tree would look like: +--rw filters | +--rw filter* | +--rw identifier filter-id | +--rw filter-type filter-type | +--rw filter anyxml +--rw subscription-config +--rw subscription* +--rw (filter) | +--:(by-reference) | | +--rw filter-ref? filter-ref | +--:(inline) | +--rw filter-type filter-type | +--rw filter anyxml +--rw (target) +--:(datastore) | +--rw datastore datastore-type +--:(event-stream) +--rw stream stream-type I believe such a restructuring should allow the growth of new filter types,= streams, and datastores purely though the addition of new identifies. Thoughts? Concerns? If no, I will submit a new version of draft-ietf-net= conf-yang-push-06 which matches to this later in the week. Eric --_000_5140d5635b564d58b72fff100252b0cfXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I should have put in t= he ‘subscription-config’ container to make the tree reflect thi= s (added in-line in blue below).   Note: per the other part of re= vised-datastores, it would be great to merge the separate config and operational data.   But that is a different issue.

 

Eric=

 

From: Eric Voit, April 11, 2017 9:38 AM

It would be great to cover some implications of the = revised-datastore work within the subscription drafts.  The goal shoul= d be the we only need augment the yang-push draft with some new identities = when the revised-datastore work completes. 

 

To accomplish this, I believe that we should tweak t= he yang-push subscription model by:

 

(1) Adding a ‘filter-type’ identity &nbs= p;(previously filter subtyping was accomplished via an explicit subtree cho= ice statement)

·       ‘Subtree’, ‘xpath’ &= nbsp;would be of filter-type

·       New filter types (metadata?) could be augmen= ted in

 

(2) Adding a ‘datastore-type’ identity

·       ‘running’, ‘candidate̵= 7;, ‘startup’  would be of filter-type

·       revised-datastore identities could be augmen= ted in

 

With such a change the yang tree would look like:

 

    +--rw filters

    |  +--rw filter*

    |     +--= rw  identifier        filter-id

    |     +--= rw  filter-type       filter-type <= /o:p>

    |     +--= rw  filter           = ;     anyxml

    = 3;--rw subscription-config

    &nb= sp;   +--rw subscription*

   &nbs= p;           +--rw = (filter)

    &nb= sp;          | &nb= sp;  +--:(by-reference)

               |   &= nbsp;|  +--rw filter-ref?       = ;  filter-ref

               |   &= nbsp;+--:(inline)

    &nb= sp;          | &nb= sp;      +--rw  filter-type   &= nbsp;   filter-type

               |   &= nbsp;    +--rw  filter     &nbs= p;          anyxml

         &nb= sp;     +--rw = (target)

          &n= bsp;              +--:(datastore)

         &nb= sp;               |    = +--rw datastore   datastore-type

         &nb= sp;               +--:(event-stream)

          &n= bsp;            &nbs= p;        +--rw stream       stream-ty= pe

 

I believe such a restructuring should allow the grow= th of new filter types, streams, and datastores purely though the addition = of new identifies. 

 

Thoughts?  Concerns?   If no, I will = submit a new version of draft-ietf-netconf-yang-push-06 which matches to th= is later in the week.

 

Eric

 

 

--_000_5140d5635b564d58b72fff100252b0cfXCHRTP013ciscocom_-- From nobody Wed Apr 12 08:57:08 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 126F912EAA6; Wed, 12 Apr 2017 08:57:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 08:57:00 -0700 Archived-At: Subject: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 15:57:00 -0000 Alia Atlas has entered the following ballot position for charter-ietf-netconf-18-10: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- This charter uses the term "I2RS protocol" and I2RS isn't doing its own protocol. Now, what I heard secondhand is that the intent is for NetConf to defined the needed capabilities so that the I2RS WG can define the necessary extensions - probably to RestConf - to support the well-documented requirements. As Responsible AD for I2RS, I need to actually hear and understand the change and intended split of work. This change is going to require a recharter for I2RS, since it is explicitly not chartered to do any protocol work; the expectation has been that this would be done in NetConf and NetMod, as needed. I am quite positive on the idea of letting the I2RS WG define the necessary extensions and finally be able to move at the speed appropriate to the active contributors - but we need to be correct in terminology, clear on the work split, and understand how this will proceed. From nobody Wed Apr 12 11:05:54 2017 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 B26031317B6; Wed, 12 Apr 2017 11:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 D2ZXbrQlM6Ux; Wed, 12 Apr 2017 11:05:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D89A12EB62; Wed, 12 Apr 2017 11:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5680; q=dns/txt; s=iport; t=1492020345; x=1493229945; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=YYn+s9BZGLnoKsflyhVQH0hKf7YQRjpjG3tCoLHEjnY=; b=aUbR/F3dm067PxH8g1JZqOZCXvxkpEvAk9wCHR6uTZp6hhEAU6KwiAXJ kWFLIZ9h8/SQWWZTJH5tdXo7FjXgkIjnJb5T6vlZzE5hOe6kI8e4tJc// 77PosU8Jszhc66ppf1smYgFly9zD0XLIhSJFiSmUf+5L0y04UsX7rlrbd o=; X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208,217";a="411184362" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 18:05:45 +0000 Received: from [10.155.69.118] (dhcp-10-155-69-118.cisco.com [10.155.69.118]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3CI5ish028624; Wed, 12 Apr 2017 18:05:44 GMT To: Eric Rescorla References: <149157829328.11248.4698360894116169360.idtracker@ietfa.amsl.com> Cc: netconf@ietf.org, "Giles Heron (giheron)" , The IESG , netconf-chairs@ietf.org From: Benoit Claise Message-ID: Date: Wed, 12 Apr 2017 11:05:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D776820EA75F6CCB2E29D5C0" Archived-At: Subject: Re: [Netconf] Eric Rescorla's No Objection on charter-ietf-netconf-18-08: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:05:48 -0000 This is a multi-part message in MIME format. --------------D776820EA75F6CCB2E29D5C0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/10/2017 9:17 AM, Eric Rescorla wrote: > > > On Mon, Apr 10, 2017 at 8:40 AM, Benoit Claise > wrote: > > Eric, > > Eric Rescorla has entered the following ballot position for > charter-ietf-netconf-18-08: No Objection > > When responding, please keep the subject line intact and reply > to all > email addresses included in the To and CC lines. (Feel free to > cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/charter-ietf-netconf/ > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Can you please reflow this sensibly so that each paragraph is > not one > giant line? > > Not sure what you mean. Isn't the goal of a paragraph to combine > related sentences? > Please propose some new text, so that I see what you mean. > > > I'm talking about putting line breaks every 70 characters or so, like > the way RFCs are formatted. Oh, that one. This is a tooling issue. It depends where you look. https://datatracker.ietf.org/doc/html/charter-ietf-netconf (*) versus https://datatracker.ietf.org/doc/charter-ietf-netconf/ (*) Bug report opened. We need the width auto adaptation, depending on the device used to read this page. Regards, Benoit. --------------D776820EA75F6CCB2E29D5C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/10/2017 9:17 AM, Eric Rescorla wrote:


On Mon, Apr 10, 2017 at 8:40 AM, Benoit Claise <bclaise@cisco.com> wrote:
Eric,
Eric Rescorla has entered the following ballot position for
charter-ietf-netconf-18-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-netconf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Can you please reflow this sensibly so that each paragraph is not one
giant line?
 Not sure what you mean. Isn't the goal of a paragraph to combine related sentences?
Please propose some new text, so that I see what you mean.

I'm talking about putting line breaks every 70 characters or so, like
the way RFCs are formatted.
Oh, that one.
This is a tooling issue. It depends where you look.
https://datatracker.ietf.org/doc/html/charter-ietf-netconf  (*)
versus https://datatracker.ietf.org/doc/charter-ietf-netconf/

(*) Bug report opened. We need the width auto adaptation, depending on the device used to read this page.

Regards, Benoit.

--------------D776820EA75F6CCB2E29D5C0-- From nobody Wed Apr 12 11:17:20 2017 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 968BD12948E; Wed, 12 Apr 2017 11:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 P2CRcr4-aYFr; Wed, 12 Apr 2017 11:17:17 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331B4129A8D; Wed, 12 Apr 2017 11:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2632; q=dns/txt; s=iport; t=1492021036; x=1493230636; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ew6WhrUR8jzSXrp/fip+IzQi9ecUgujUHjdknoDd9EE=; b=SqRyoQiPHwZQCDegoUHw03GznJfcxJXeTer7is8vZW9HOfmT5IcVlaAh ofQJuuxw1QTXUYaufTMOnkThJ5c409hfeNKRz41GqSBMBEHF6wq7YloFd yKNVVhhI+7BWOc9jJUWXItzRaCl2qUNJkDr070+GdORSWdNWhZgc/KdM4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAgBLbu5Y/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhhHGKE5ExH5VZgg8uhXYChAE/GAECAQEBAQEBAWsohRYBBAE?= =?us-ascii?q?jFUEFCwsODAImAgJXBgEMCAEBigoIDqh8giaLEAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgQuFRoIICYJjhCgRAYMigl8FiSeHS4U1hmOHAotfgX+FLoM6hl2LZog?= =?us-ascii?q?cHzh9CCUWCBgVhzsghymCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208";a="409538754" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 18:17:15 +0000 Received: from [10.155.69.118] (dhcp-10-155-69-118.cisco.com [10.155.69.118]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3CIHDO4005448; Wed, 12 Apr 2017 18:17:14 GMT To: Alia Atlas , The IESG References: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> Cc: netconf-chairs@ietf.org, netconf@ietf.org From: Benoit Claise Message-ID: Date: Wed, 12 Apr 2017 11:17:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:17:19 -0000 Alia, > Alia Atlas has entered the following ballot position for > charter-ietf-netconf-18-10: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-netconf/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > This charter uses the term "I2RS protocol" and I2RS isn't doing its own > protocol. I'm actually glad you made that point. I introduced that term to make sure we cover I2RS, but I've not been happy about it. I could not find the right wordings. > > Now, what I heard secondhand is that the intent is for NetConf to defined > the needed > capabilities so that the I2RS WG can define the necessary extensions - > probably to > RestConf - to support the well-documented requirements. You're right, the revised DS document specifies the needed capabilities. See https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores#appendix-B Thinking about the text. OLD: Define capabilities for NETCONF and RESTCONF to support I2RS protocol and ephemeral-state datastore requirements. NEW: Define capabilities for NETCONF and RESTCONF to support I2RS and ephemeral-state datastore requirements. Or even better, IMO NEW: Define capabilities for NETCONF and RESTCONF to support the ephemeral-state datastore requirements. Now, wait. Actually, I believe you should have all you need for I2RS part of entry 6 6. Based on the revised datastore concept work in NETMOD, provide a revision for the NETCONF and RESTCONF protocols and the used datastore framework. In the end, we could remove the point 7. Feedback? Regards, Benoit > > As Responsible AD for I2RS, I need to actually hear and understand the > change and intended > split of work. This change is going to require a recharter for I2RS, > since it is explicitly not > chartered to do any protocol work; the expectation has been that this > would be done in NetConf > and NetMod, as needed. > > I am quite positive on the idea of letting the I2RS WG define the > necessary extensions and > finally be able to move at the speed appropriate to the active > contributors - but we need > to be correct in terminology, clear on the work split, and understand how > this will proceed. > > > > > . > From nobody Wed Apr 12 14:22:16 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3503129B6A; Wed, 12 Apr 2017 14:22:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149203213390.15816.16482101400673600771.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 14:22:13 -0700 Archived-At: Subject: [Netconf] Ben Campbell's No Objection on charter-ietf-netconf-18-10: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:22:14 -0000 Ben Campbell has entered the following ballot position for charter-ietf-netconf-18-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think this is ready for external review, which I understand to be the intent. I do not think it is ready for approval until the external review occurs. From nobody Thu Apr 13 06:39:27 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35678129492; Thu, 13 Apr 2017 06:39:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149209076012.15666.6288668415150289747.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 06:39:20 -0700 Archived-At: Subject: [Netconf] Alvaro Retana's No Objection on charter-ietf-netconf-18-10: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 13:39:20 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-netconf-18-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The first paragraph... The NETCONF Working Group, previously named after the NETCONF protocol, now renamed as the NETwork CONFiguration Working Group, is responsible for the development and maintenance of protocols for YANG data model driven management, for the necessary framework where these protocols run, and for the YANG modules that formalize protocol behavior and are required from a protocol perspective. ...seems to have significantly widened what the netconf WG is responsible for beyond NETCONF/RESTCONF, but the rest of the charter only talks about those two protocols. If the intent is to allow the WG to work on other protocols (or at least consider them if they exist, are brought to the WG, etc.), then it may be a good idea to include text that specifically mentions it. From nobody Thu Apr 13 08:11:12 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5182126BF0; Thu, 13 Apr 2017 08:11:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149209627064.15812.16010701045881480441.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 08:11:10 -0700 Archived-At: Subject: [Netconf] Eric Rescorla's No Objection on charter-ietf-netconf-18-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 15:11:11 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-netconf-18-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ There are no remarks associated with this position. From nobody Fri Apr 14 08:14:00 2017 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 3983C1294A9 for ; Fri, 14 Apr 2017 08:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gMlQhJcB1MlI for ; Fri, 14 Apr 2017 08:13:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C06127869 for ; Fri, 14 Apr 2017 08:13:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKY57092; Fri, 14 Apr 2017 15:13:54 +0000 (GMT) Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 14 Apr 2017 16:13:53 +0100 Received: from DGGEMA503-MBS.china.huawei.com ([169.254.2.170]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0301.000; Fri, 14 Apr 2017 23:13:42 +0800 From: Rohit pobbathi To: "dew@tx.technion.ac.il" , "moses@ee.technion.ac.il" CC: netconf Thread-Topic: A query regarding the augment of scheduling-tolerance Thread-Index: AdK1MbFoL08muZWxSRazaKp7RujgfA== Importance: high X-Priority: 1 Date: Fri, 14 Apr 2017 15:13:42 +0000 Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB45602B57@DGGEMA503-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.210.230] Content-Type: multipart/alternative; boundary="_000_2730B0D5F3302249A30EBF0DAE96D4CB45602B57DGGEMA503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58F0E732.0261, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.170, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 782f0665b4052418a2fd11cb6e8367ce Archived-At: Subject: [Netconf] A query regarding the augment of scheduling-tolerance X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 15:13:58 -0000 --_000_2730B0D5F3302249A30EBF0DAE96D4CB45602B57DGGEMA503MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal, Yoram, I have a query regarding RFC 7758 Time Capability in NETCONF. The "scheduling-tolerance-parameters" are augmented to a config "false" con= tainer /ncm:netconf-state. augment /ncm:netconf-state { container scheduling-tolerance { uses scheduling-tolerance-parameters; description "The scheduling tolerance when the time capability is enabled."; } description "The scheduling tolerance of the server."; } If user require to configure the scheduling-tolerance-parameters, how do yo= u suggest to configure ? Rgds, Rohit Pobbathi --_000_2730B0D5F3302249A30EBF0DAE96D4CB45602B57DGGEMA503MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal, Yoram,

 

I have a query regarding RFC 7758 Time Capability in= NETCONF.

 

The “scheduling-tolerance-parameters” are augmented to a config “false” container  /ncm:netconf-state.

 

   aug= ment /ncm:netconf-state {

  &nbs= p;  container scheduling-tolerance {

  &nbs= p;    uses scheduling-tolerance-parameters;

  &nbs= p;    description

  &nbs= p;      "The scheduling tolerance when the ti= me capability

  &nbs= p;       is enabled.";=

  &nbs= p;  }

  &nbs= p;  description

  &nbs= p;    "The scheduling tolerance of the server.";

   }

 

If user require to configure the scheduling-toleranc= e-parameters, how do you suggest to configure ?

 

Rgds,

Rohit Pobbathi

--_000_2730B0D5F3302249A30EBF0DAE96D4CB45602B57DGGEMA503MBSchi_-- From nobody Fri Apr 14 14:36:08 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D91CD129514; Fri, 14 Apr 2017 14:36:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149220576684.15883.142573688980280620@ietfa.amsl.com> Date: Fri, 14 Apr 2017 14:36:06 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:36:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Custom Subscription to Event Notifications Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Einar Nilsen-Nygaard Ambika Prasad Tripathy Filename : draft-ietf-netconf-subscribed-notifications-01.txt Pages : 49 Date : 2017-04-14 Abstract: This document defines capabilities and operations for the customized establishment of subscriptions upon a publisher's event streams. Also defined are delivery mechanisms for instances of the resulting events. Effectively this allows a subscriber to request and receive a continuous, custom influx of publisher generated information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-01 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-subscribed-notifications-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 14 15:08:16 2017 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 B8B0E127077 for ; Fri, 14 Apr 2017 15:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 YsqWMabHu9Ji for ; Fri, 14 Apr 2017 15:08:13 -0700 (PDT) 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 CF434126DED for ; Fri, 14 Apr 2017 15:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3275; q=dns/txt; s=iport; t=1492207692; x=1493417292; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=R1bBS7r4dLhehio6Ct+Zlb3paIzEX6eMqi7BaYmcsNA=; b=ZlRgh07jigE10ozOlzJ3uCNfGKjA1zr2kEq63rKq+ZnWWht8VzGXljtG CyN7D5VMvlXo+ri0uQH1erhmuvcQuzjS3jQgt3pcxGHORhyLiICd1htkW 8t2NpjBgno1xNJAlFtCXgfreeqxupyPGzbB4CAQxcrAg38LOdRyL3coU3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAQDbRvFY/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHjXSRXpVegg8hDYUsSgKDfz8YAQIBAQEBAQEBax0LhRU?= =?us-ascii?q?BAQEBAwEBODQJDgQCAQgRBAEBDhEJBycLFAkIAgQTCIoPDqtjixEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdhlKEdIMYhyQFnRcBhwOLWIIIVYRbiheUCQEfOIEFYxU?= =?us-ascii?q?YKYRiHIFjdYg7gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,200,1488844800"; d="scan'208";a="412628283" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2017 22:08:12 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3EM8BbY015086 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 14 Apr 2017 22:08:11 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Apr 2017 18:08:11 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 14 Apr 2017 18:08:11 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-01.txt Thread-Index: AQHStWcoc6tfDFfTwEiNevGqudpX/aHFZJJQ Date: Fri, 14 Apr 2017 22:08:10 +0000 Message-ID: <74e4f26570454c8c9c3186562f2b6cc5@XCH-RTP-013.cisco.com> References: <149220576684.15883.142573688980280620@ietfa.amsl.com> In-Reply-To: <149220576684.15883.142573688980280620@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 22:08:15 -0000 Changes in this version: 1. Security considerations updated 2. Intro rewrite, as well as scattered text changes 3. Added Appendix A, to help match this to related drafts in progress 4. Updated filtering definitions, and filter types in yang file, and mov= ed to identities for filter types 5. Added Syslog as a stream 6. HTTP2 transport option 7. Replay made an optional feature=20 8. Enabled notification timestamp to have different formats. 9. Two error codes added. To me the most interesting one is #5. Do people have opinions on whether u= nstructured syslog entries should be exposed as a stream? (In RFC-5277, su= ch a definition was eventually skipped, even though looking in its history = draft-ietf-netconf-notification-02 section B.2 laid out a more structured m= ethod of accomplishing this. I don't have history on why it was dropped.) If there is not interest, or is confusion, it can easily be removed just li= ke it was for RFC-5277. Eric > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, April 14, 2017 5:36 PM > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notification= s-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration of the IETF. >=20 > Title : Custom Subscription to Event Notifications > Authors : Eric Voit > Alexander Clemm > Alberto Gonzalez Prieto > Einar Nilsen-Nygaard > Ambika Prasad Tripathy > Filename : draft-ietf-netconf-subscribed-notifications-01.txt > Pages : 49 > Date : 2017-04-14 >=20 > Abstract: > This document defines capabilities and operations for the customized > establishment of subscriptions upon a publisher's event streams. > Also defined are delivery mechanisms for instances of the resulting > events. Effectively this allows a subscriber to request and receive > a continuous, custom influx of publisher generated information. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notificati= ons/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-0= 1 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed- > notifications-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-subscribed-notific= ations-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Apr 18 12:15:45 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECF0126C0F; Tue, 18 Apr 2017 12:15:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: bclaise@cisco.com, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149254294350.29147.1102989407564775317.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 12:15:43 -0700 Archived-At: Subject: [Netconf] netconf - New Meeting Session Request for IETF 99 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:15:44 -0000 A new meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: netmod opsarea opsawg l2sm lime supa Second Priority: nmrg i2rs i2nsf nfvrg Third Priority: anima sacm v6ops core 6tisch 6lo People who must be present: Mehmet Ersue Benoit Claise Mahesh Jethanandani Resources Requested: Special Requests: Please schedule the NETCONF session on Tue, Wed or Thu. Friday is NOT possible. (netmod opsarea opsawg l2sm lime supa are a conflict for the OPS AD Benoit Claise) Thanks. --------------------------------------------------------- From nobody Tue Apr 18 17:34:29 2017 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 E8CEC129465 for ; Tue, 18 Apr 2017 17:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5O3268HctcY5 for ; Tue, 18 Apr 2017 17:34:27 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53EA1250B8 for ; Tue, 18 Apr 2017 17:34:27 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 194so4053749pfv.3 for ; Tue, 18 Apr 2017 17:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=2DLke1T4xPBUcybLQijTMrcRlgGu6tDJbL0cNEMUF0w=; b=eof28AlenGRL/HKUcoBJxgP+3ChjHpNdYy4NnjEX09Epyqy5hSjvU/A7YcYULDNieT R0SNxzjz+1mPTOMFpSyuvA9TP0H0UQU8/hg2FC7YlfefsqhjxrZFSj6gbLv5zc1Yube/ t6sySJtGA3UmimGF8aGSLsougdECz0Iq2K18pyO0/6EVElhpCOgLBuLQVFjedYAt6Ak+ sub6hdKwN+NUd8QJoyz/L6CqnSmESax+J8LTDvwNVhP4+rJhaa3uaupqUBrbN8bg1Tzj lPq4b+qyCv28WJUyQ085/TAbvv9OcnkiBBLHZOF9DJ+ZnNnTowOuNIA2d9wctP/8mnTa pLlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=2DLke1T4xPBUcybLQijTMrcRlgGu6tDJbL0cNEMUF0w=; b=T/19xC0Du2vy9rDHPg7aPUEnoYVuBvZ5DGJt7TJdzGdUq738xu59RM4BeMthqCQ/4V vRLGGkvbz9EHfPc/RzDkjuPBpm9FZL9TxKUGOzEUu3X8Rlmy37hJpWGK6fUdG5m1/zWl ILvZj5WEBAeg0w14hD8IBNA4FnJdKLr3+Qx19QMrluGeGrgrLCRAo768EquTcJkDHtPG SYCjwl3gCHEZXOoMjeh9XpRfj/hTPKtA2XroYHSgQxkK7ITG7pDDaIgE/dL5QObrbxZO IYz0Zrxw8Z0btw4jHqx75/fuE6i2Pp9AxK742ayd6CEDKnoTcczgEILD1bgB4mMyz/eI Ui2g== X-Gm-Message-State: AN3rC/4Qu5X8EQWixrn30wuv05DEqoLQ+PPSU57txwkZW938ARx+qPB+ poHgekAGQOqgygIbp2s= X-Received: by 10.98.202.80 with SMTP id n77mr224526pfg.158.1492562067220; Tue, 18 Apr 2017 17:34:27 -0700 (PDT) Received: from [10.154.163.57] ([128.107.241.174]) by smtp.gmail.com with ESMTPSA id a77sm654236pfj.1.2017.04.18.17.34.26 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Apr 2017 17:34:26 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_C1EFC22F-310E-4156-89F5-BC2E6383466F" Message-Id: Date: Tue, 18 Apr 2017 17:34:25 -0700 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 00:34:29 -0000 --Apple-Mail=_C1EFC22F-310E-4156-89F5-BC2E6383466F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, In IETF 98, the authors indicated that the above draft was ready for = Last Call, and the consensus in the room indicated as much. This is a start of a 2 week WG Last Call for = draft-ietf-netconf-rfc6536bis. After two weeks, the document will be = assigned a shepherd, and the document will be prepared for IESG. The latest version of the draft can be found at: https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-01 = Please review and send any comments to the WG mailing list or by = responding to this e-mail. Comments can be statements such as, I = read/reviewed the document and believe it is ready for publication, or I = have concerns about the document. For the latter, please indicate what = your concerns are.=20 Any reports on implementation status or plans to implement are also very = useful. Authors, please indicate if you are aware of any IPRs related to the = draft. Thanks. Mahesh and Mehmet --Apple-Mail=_C1EFC22F-310E-4156-89F5-BC2E6383466F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii NETCONF WG,

In IETF 98, the = authors indicated that the above draft was ready for Last Call, and the = consensus in the room indicated as much.

This is a start of a 2 week WG Last = Call for draft-ietf-netconf-rfc6536bis. After two weeks, the document = will be assigned a shepherd, and the document will be prepared for = IESG.

The latest version of the draft can = be found at:
https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-01

Please review and send any comments to = the WG mailing list or by responding to this e-mail. Comments can be = statements such as, I read/reviewed the document and believe it is = ready for publication, or I have concerns about the document. For the = latter, please indicate what your concerns are. 

Any reports on implementation status or plans to implement = are also very useful.

Authors, please indicate if you are aware of any IPRs related = to the draft.

Thanks.

Mahesh and Mehmet


= --Apple-Mail=_C1EFC22F-310E-4156-89F5-BC2E6383466F-- From nobody Tue Apr 18 18:33:52 2017 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 E75A61293F3 for ; Tue, 18 Apr 2017 18:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 8DWEXQPrcXDt for ; Tue, 18 Apr 2017 18:33:49 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27131128768 for ; Tue, 18 Apr 2017 18:33:49 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id w64so68948209wma.0 for ; Tue, 18 Apr 2017 18:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WhrBxQPmsZIsh9l/A85l0ZmPQkIXNCRBPgyFOt1zZh0=; b=Us7FBS9WPLN81ZgOvmGkqe8a/hchwBF16+qIyQBWwyiHsEAtbGwfkUHrtc+lwTZyiF v5uxGFLGvhQ/WsmDLhKgiGmDTVTXvyl0CdrwjbOR2/oLgy2cwf5iup08n0NTgERLdV9G iDDXEtT12OgS2AjKTkhXcujdyIcgcBai5VHym5kF4XdEIqArM0+NCyqMUVKhGuTzBdsA ITbGFxL7j7k3J7FeIZq5YOLy2FIoCnDpf2ynlYuXfD2kXlK/kgxC7m/bAUQc4t6G86fq Wgb6eju90yYEG+h4Gabh4dwkDsMzGCo4Hx/OaUVnAJxcXqW7krxwrLe/oaF7Y+fv0vBF beGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WhrBxQPmsZIsh9l/A85l0ZmPQkIXNCRBPgyFOt1zZh0=; b=QSJ9DFvIv0Pvr/laOOF5q/t0gKZY8bLvGhJWGGJzLE0XFwBE/vX73ozzjoTvv4am3X wd5cxOAVJGEDwgJogo6A4R4Ya6fazdCFso8fy5CYbZH3stmXc1KR2jLJYJvOxYDg6xAT 1dBKwYLhfltrU3pbyIhHmvly6x3UADGZmQ+tRSzWLsRm8ub/ajY04+SJOEHQuT2yzvbX 7hFbDRf6QBbf2glvbI8X6ET5eLh7nSEGpx6SUPOHfIFfql2Auj1A9Ff0XIasMdTj9ZW9 k2LjRZiUp+Z/a7E865+/4uPDt0C4oGBL5OFGUFXPJ/zf4C/+DStjvzoAXCdzeNEjmmBw +unw== X-Gm-Message-State: AN3rC/7/HAsJxvHaa+5EN1yVZ1iEETB3HRyzAvW+wtdq86tKo6a1QjK6 cUlQ2aqQYU5Bjx9X8QuindyGC6m4lw== X-Received: by 10.28.46.213 with SMTP id u204mr518308wmu.136.1492565627573; Tue, 18 Apr 2017 18:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Tue, 18 Apr 2017 18:33:46 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Tue, 18 Apr 2017 18:33:46 -0700 Message-ID: To: Mahesh Jethanandani Cc: Netconf Content-Type: multipart/alternative; boundary=001a11497ace092d8c054d7b04b5 Archived-At: Subject: Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 01:33:51 -0000 --001a11497ace092d8c054d7b04b5 Content-Type: text/plain; charset=UTF-8 Hi, Note this issue on github that is already fixed in the next release: https://github.com/netconf-wg/rfc6536bis/issues/1 Andy On Tue, Apr 18, 2017 at 5:34 PM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > NETCONF WG, > > In IETF 98, the authors indicated that the above draft was ready for Last > Call, and the consensus in the room indicated as much. > > This is a start of a 2 week WG Last Call for > draft-ietf-netconf-rfc6536bis. After two weeks, the document will be > assigned a shepherd, and the document will be prepared for IESG. > > The latest version of the draft can be found at: > https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-01 > > Please review and send any comments to the WG mailing list or by > responding to this e-mail. Comments can be statements such as, I > read/reviewed the document and believe it is ready for publication, or I > have concerns about the document. For the latter, please indicate what your > concerns are. > > Any reports on implementation status or plans to implement are also very > useful. > > Authors, please indicate if you are aware of any IPRs related to the draft. > > Thanks. > > Mahesh and Mehmet > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11497ace092d8c054d7b04b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Note this issue on github that is a= lready fixed in the next release:


Andy


On Tue,= Apr 18, 2017 at 5:34 PM, Mahesh Jethanandani <mjethanandani@gmail.c= om> wrote:
NETCONF WG,

In IETF 98, the authors indicated th= at the above draft was ready for Last Call, and the consensus in the room i= ndicated as much.

This is a start of a 2 week WG Last Ca= ll for draft-ietf-netconf-rfc6536bis. After two weeks, the document will be= assigned a shepherd, and the document will be prepared for IESG.

Th= e latest version of the draft can be found at:
https://t= ools.ietf.org/html/draft-ietf-netconf-rfc6536bis-01

Pl= ease review and send any comments to the WG mailing list or by responding t= o this e-mail. Comments can be statements such as, I read/reviewed the docu= ment=C2=A0and believe it is ready for publication, or I have concerns about= the document. For the latter, please indicate what your concerns are.=C2= =A0

Any reports on implementation status or plans to implement are a= lso=C2=A0very useful.

Authors, please indicate if you ar= e aware of any IPRs related to the draft.

Thanks.<= br>
Mahesh and Mehmet



____________________________________________= ___
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--001a11497ace092d8c054d7b04b5-- From nobody Thu Apr 20 06:27:38 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 596AF120227; Thu, 20 Apr 2017 06:27:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149269485632.22298.6638206608571650090@ietfa.amsl.com> Date: Thu, 20 Apr 2017 06:27:36 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:27:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Custom Subscription to Event Notifications Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Einar Nilsen-Nygaard Ambika Prasad Tripathy Filename : draft-ietf-netconf-subscribed-notifications-02.txt Pages : 49 Date : 2017-04-20 Abstract: This document defines capabilities and operations for the customized establishment of subscriptions upon a publisher's event streams. Also defined are delivery mechanisms for instances of the resulting events. Effectively this allows a subscriber to request and receive a continuous, custom influx of publisher generated information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-02 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-subscribed-notifications-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 20 06:34:55 2017 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 B939A131450 for ; Thu, 20 Apr 2017 06:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 d3djwB3umW0v for ; Thu, 20 Apr 2017 06:34:53 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CC5131453 for ; Thu, 20 Apr 2017 06:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2210; q=dns/txt; s=iport; t=1492695293; x=1493904893; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=azjpXPt1GUg5/UaEwdX3c821/jAvjub/2pP8CIRhYKA=; b=PN7LC3XZJbB0Gd/bgT35Ipavl+qqL48WSsSDx68uorGqtmLMQ2gBR0x1 smLuLA0flO1jbnEsjDlPVuF7ErJalgcuzSVkSHE2BNdrK/O6tA3LexnjK X8gdMxwgfixTQjjp4RTAQWMbiS5Rxxh1JYlpu475VzqOor7XStCHw4O6r g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAA9uPhY/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjXWRY5Vjgg8hDYUsSgKDej8YAQIBAQEBAQEBax0LhRU?= =?us-ascii?q?BAQEBAgEBATg0CQcLAgEIFRARECcLJQIEEwiKDAgOrHGLHwEBAQEBAQEBAgEBA?= =?us-ascii?q?QEBAQEBAR+GU4R2gxiHJAWdNAGHFItlgglVhF6KIpQTAR84gQVjFRoqhmV1hnE?= =?us-ascii?q?pgQeBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,225,1488844800"; d="scan'208";a="415128182" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2017 13:34:52 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3KDYq99029148 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Apr 2017 13:34:52 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 09:34:51 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 09:34:51 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-02.txt Thread-Index: AQHSudnnLfBhq35b1kq3gz1HeUNb2aHOQPHQ Date: Thu, 20 Apr 2017 13:34:51 +0000 Message-ID: References: <149269485632.22298.6638206608571650090@ietfa.amsl.com> In-Reply-To: <149269485632.22298.6638206608571650090@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:34:55 -0000 One tweak. Subscription status is moved under "receivers" in the YANG mode= l. This makes it is possible to suspend individual receivers in multi-receiver= configured subscription. Eric > From: internet-drafts@ietf.org Thursday, April 20, 2017 9:28 AM >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration of the IETF. >=20 > Title : Custom Subscription to Event Notifications > Authors : Eric Voit > Alexander Clemm > Alberto Gonzalez Prieto > Einar Nilsen-Nygaard > Ambika Prasad Tripathy > Filename : draft-ietf-netconf-subscribed-notifications-02.txt > Pages : 49 > Date : 2017-04-20 >=20 > Abstract: > This document defines capabilities and operations for the customized > establishment of subscriptions upon a publisher's event streams. > Also defined are delivery mechanisms for instances of the resulting > events. Effectively this allows a subscriber to request and receive > a continuous, custom influx of publisher generated information. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notificati= ons/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-0= 2 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed- > notifications-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-subscribed-notific= ations-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Apr 20 06:49:52 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8F5127873; Thu, 20 Apr 2017 06:49:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149269619133.22294.6355980061162235809@ietfa.amsl.com> Date: Thu, 20 Apr 2017 06:49:51 -0700 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:49:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Subscribing to YANG datastore push updates Authors : Alexander Clemm Eric Voit Alberto Gonzalez Prieto Ambika Prasad Tripathy Einar Nilsen-Nygaard Andy Bierman Balazs Lengyel Filename : draft-ietf-netconf-yang-push-06.txt Pages : 49 Date : 2017-04-20 Abstract: Providing rapid visibility into changes made on YANG configuration and operational objects enables new capabilities such as remote mirroring of configuration and operational state. Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-06 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 20 07:12:17 2017 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 12E45127241 for ; Thu, 20 Apr 2017 07:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 R2qAQBqmADAR for ; Thu, 20 Apr 2017 07:12:13 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D109129520 for ; Thu, 20 Apr 2017 07:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3299; q=dns/txt; s=iport; t=1492697533; x=1493907133; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DAdXNjTxxOThEhvvTbcHqFp6xtRslnyjhHodFFopdOg=; b=Suv8DXo66EsmdgtbnMhrTd3mmMoi69vDawgID3jIA0gprZxnoDCT1lT0 vCcnk7kG5wwk0Lin5kqaj+kVRLfo36iXRag5dTOTeece4YF+kxdUN83ao Q6z64+f2QTCifyr2f8ke8XQGLrBOLCN83mlD1DjDuL/DQVOrN0Rz60loW 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAABNwfhY/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjXWRY3CUc4IPIQuFLkoCg3w/GAECAQEBAQEBAWsdC4U?= =?us-ascii?q?VAQEBAQIBAQE4NAQMCwIBCBUQERAnCyUCBBMIigwIDq0Dix4BAQEBAQEBAQIBA?= =?us-ascii?q?QEBAQEBAQEBAR2GU4FdgmU0gxiHJAWdNAGHFItlgglVhF6KIpQTAR84gQVjFRo?= =?us-ascii?q?qhmV1hnMrgQOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,225,1488844800"; d="scan'208";a="414974067" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2017 14:12:12 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3KECCkC015174 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Apr 2017 14:12:12 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 10:12:11 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 10:12:11 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-yang-push-06.txt Thread-Index: AQHSud0CH5OHZrWov0OAR4uKqcH2IqHOSB5A Date: Thu, 20 Apr 2017 14:12:11 +0000 Message-ID: <573207c6af2c42d28aeccd774e8d5238@XCH-RTP-013.cisco.com> References: <149269619133.22294.6355980061162235809@ietfa.amsl.com> In-Reply-To: <149269619133.22294.6355980061162235809@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-push-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:12:16 -0000 Changes in the new version include: - Intro simplified, and appendix added talking about relationship to other = subscription drafts. - Datastore replaces stream as the target for a filter. - Definitions of filters improved. Filters are also now identities, so new= ones can be more easily added (looking towards OpState work for new option= s here). - Security sections improved to better describe per receiver filtering opti= ons. - The YANG model which is augmented from draft-ietf-netconf-subscribed-not= ifications moved to identities for filters and , YANG augmentations in thi= s doc matched up. - Terms refined and text redundancies cleaned-up throughout The open questions/issues list is getting smaller. Top of mind are those b= elow. Please feel to ask questions on these (or anything else). * do we want a new RPC to allow a subscriber to force on-change resynchroni= zation? * should we require support for all YANG patch operations? * do the OpState draft authors feel the filter format meet their needs * validation needed that new bundled notification message can be extended/a= ugmented later. * GRPC support still desired. Not how to accomplish within IETF * pyang crashes on deviation which adds notifiable on change extension Eric > From: internet-drafts@ietf.org, April 20, 2017 9:50 AM >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration of the IETF. >=20 > Title : Subscribing to YANG datastore push updates > Authors : Alexander Clemm > Eric Voit > Alberto Gonzalez Prieto > Ambika Prasad Tripathy > Einar Nilsen-Nygaard > Andy Bierman > Balazs Lengyel > Filename : draft-ietf-netconf-yang-push-06.txt > Pages : 49 > Date : 2017-04-20 >=20 > Abstract: > Providing rapid visibility into changes made on YANG configuration > and operational objects enables new capabilities such as remote > mirroring of configuration and operational state. Via the mechanism > described in this document, subscriber applications may request a > continuous, customized stream of updates from a YANG datastore. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-yang-push-06 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-yang-push-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Apr 20 13:59:26 2017 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 BA3C01316A0 for ; Thu, 20 Apr 2017 13:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 hG7G-w3i_ZS4 for ; Thu, 20 Apr 2017 13:59:23 -0700 (PDT) Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D83129C2A for ; Thu, 20 Apr 2017 13:59:19 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.37,227,1488866400"; d="scan'208,217"; a="92215831" Received: from unknown (HELO g05usexrtxa04.g05.fujitsu.local) ([168.127.194.64]) by fncnmp02.fnc.fujitsu.com with ESMTP/TLS/AES256-SHA; 20 Apr 2017 15:59:20 -0500 Received: from g05usexrtxa05.g05.fujitsu.local (168.127.194.65) by g05usexrtxa04.g05.fujitsu.local (168.127.194.64) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 20 Apr 2017 15:59:14 -0500 Received: from g05usexrtxa05.g05.fujitsu.local ([168.127.194.65]) by g05usexrtxa05.g05.fujitsu.local ([168.127.194.65]) with mapi id 15.00.1178.000; Thu, 20 Apr 2017 15:59:14 -0500 From: "Vasudevan.Sridharan@us.fujitsu.com" To: "netconf@ietf.org" , "netconf@ops.ietf.org" CC: "Jing.Xu@us.fujitsu.com" , "david.terwilliger@us.fujitsu.com" , "Sanjay.Gera@us.fujitsu.com" Thread-Topic: NETCONF Notification - Yang support Thread-Index: AdK6GDAirR2YMDiwQTO3/oeu9sXuOA== Date: Thu, 20 Apr 2017 20:59:14 +0000 Message-ID: <84987e7634e842f790f1332caee7257c@g05usexrtxa05.g05.fujitsu.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-11.0.0.1191-8.100.1062-23020.002 x-tm-as-result: No--14.858500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_84987e7634e842f790f1332caee7257cg05usexrtxa05g05fujitsu_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] NETCONF Notification - Yang support X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:59:25 -0000 --_000_84987e7634e842f790f1332caee7257cg05usexrtxa05g05fujitsu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, I 'm looking at the notifications.yang and nc-notifications.yang. Is this s= tandardized? RFC5277 (which predates Yang RFC6020) doesn't mention of the any yang for n= otifications. So can you please guide me on the status of this yang. Is a N= ETCONF server/client compliant with RFC5277 expected to support this yang f= or schema discovery or is it an inherent capability as part of "urn:ietf:pa= rams:netconf:capability:notification:1.0" capability? Thanks a lot in advance for the response. Thanks, Vasudevan Sridharan. --_000_84987e7634e842f790f1332caee7257cg05usexrtxa05g05fujitsu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

I ‘m looking at the notifications.yang and nc-= notifications.yang. Is this standardized?

 

RFC5277 (which predates Yang RFC6020) doesn’t = mention of the any yang for notifications. So can you please guide me on th= e status of this yang. Is a NETCONF server/client compliant with RFC5277 ex= pected to support this yang for schema discovery or is it an inherent capability as part of “urn:ietf:params:netco= nf:capability:notification:1.0” capability?

 

Thanks a lot in advance for the response.=

 

Thanks,

Vasudevan Sridharan.

--_000_84987e7634e842f790f1332caee7257cg05usexrtxa05g05fujitsu_-- From nobody Thu Apr 20 14:08:13 2017 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 E999F129C20 for ; Thu, 20 Apr 2017 14:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 s3tBBI3BPCFS for ; Thu, 20 Apr 2017 14:08:10 -0700 (PDT) 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 30C4F129442 for ; Thu, 20 Apr 2017 14:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6675; q=dns/txt; s=iport; t=1492722490; x=1493932090; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=55lcxmz6cvQo4vrvkYcgEG1e0VIYTbAdfFbOVdysqwM=; b=jQrpaQSGE2ysSIypJZYHPpoO4hTUA9gy1iUre6JroYMZR+H4vjzI+rGg mM2CWgRssrBYuP+nWw9q+ndWmQYpWnPCzmwkvxT8BpaLO13zvRKemh3ee 7BqTjFUSxcat1mbTipbg9TNMFoRtQQC4DFclWyT5bJJ0Exx92SeeGP2xH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAAD5IvlY/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYEMB411kWiQLoU1gg8uhXYCg30/GAECAQEBAQEBAWsdC4U?= =?us-ascii?q?VAQEBAQMtSgIQAgEIEQQBASgHMhQJCAEBBA4FCIoUDqxGiyIBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZThHaEQUyFLwWWQIZ0AYcUi2WCCYUziiKUEwEfOIEFYxW?= =?us-ascii?q?HKXUBiCCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,227,1488844800"; d="scan'208,217";a="225074408" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2017 21:07:51 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3KL7o1Y024154 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2017 21:07:51 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 17:07:50 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 17:07:50 -0400 From: "Eric Voit (evoit)" To: "Vasudevan.Sridharan@us.fujitsu.com" CC: "Sanjay.Gera@us.fujitsu.com" , "Jing.Xu@us.fujitsu.com" , "david.terwilliger@us.fujitsu.com" , "netconf@ietf.org" , "netconf@ops.ietf.org" Thread-Topic: NETCONF Notification - Yang support Thread-Index: AdK6GDAirR2YMDiwQTO3/oeu9sXuOAAAWT0Q Date: Thu, 20 Apr 2017 21:07:50 +0000 Message-ID: <8a0f4aa3d7e348c48ca33ed0a5cd41da@XCH-RTP-013.cisco.com> References: <84987e7634e842f790f1332caee7257c@g05usexrtxa05.g05.fujitsu.local> In-Reply-To: <84987e7634e842f790f1332caee7257c@g05usexrtxa05.g05.fujitsu.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_8a0f4aa3d7e348c48ca33ed0a5cd41daXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] NETCONF Notification - Yang support X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 21:08:12 -0000 --_000_8a0f4aa3d7e348c48ca33ed0a5cd41daXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vasudevan, Have you looked yet at: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification= s/ This is on a path to obsolete RFC-5277. Also there is work discussed at the last IETF: https://tools.ietf.org/html/draft-voit-netmod-yang-notifications2-00 is this hitting the areas in which you are asking? Eric From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Vasudevan.Srid= haran@us.fujitsu.com Sent: Thursday, April 20, 2017 4:59 PM To: netconf@ietf.org; netconf@ops.ietf.org Cc: Sanjay.Gera@us.fujitsu.com; Jing.Xu@us.fujitsu.com; david.terwilliger@u= s.fujitsu.com Subject: [Netconf] NETCONF Notification - Yang support Hi Authors, I 'm looking at the notifications.yang and nc-notifications.yang. Is this s= tandardized? RFC5277 (which predates Yang RFC6020) doesn't mention of the any yang for n= otifications. So can you please guide me on the status of this yang. Is a N= ETCONF server/client compliant with RFC5277 expected to support this yang f= or schema discovery or is it an inherent capability as part of "urn:ietf:pa= rams:netconf:capability:notification:1.0" capability? Thanks a lot in advance for the response. Thanks, Vasudevan Sridharan. --_000_8a0f4aa3d7e348c48ca33ed0a5cd41daXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vasudevan,

 

Have you looked yet at= :

https:/= /datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/<= o:p>

This is on a path to o= bsolete RFC-5277.

 

Also there is work dis= cussed at the last IETF:

https://tools.ie= tf.org/html/draft-voit-netmod-yang-notifications2-00<= /p>

is this hitting the ar= eas in which you are asking?


Eric

 

From: Netconf [mailto:netconf-bounces@ietf.or= g] On Behalf Of Vasudevan.Sridharan@us.fujitsu.com
Sent: Thursday, April 20, 2017 4:59 PM
To: netconf@ietf.org; netconf@ops.ietf.org
Cc: Sanjay.Gera@us.fujitsu.com; Jing.Xu@us.fujitsu.com; david.terwil= liger@us.fujitsu.com
Subject: [Netconf] NETCONF Notification - Yang support

 

Hi Authors,

 

I ‘m looking at the notifications.yang and nc-= notifications.yang. Is this standardized?

 

RFC5277 (which predates Yang RFC6020) doesn’t = mention of the any yang for notifications. So can you please guide me on th= e status of this yang. Is a NETCONF server/client compliant with RFC5277 ex= pected to support this yang for schema discovery or is it an inherent capability as part of “urn:ietf:params:netco= nf:capability:notification:1.0” capability?

 

Thanks a lot in advance for the response.=

 

Thanks,

Vasudevan Sridharan.

--_000_8a0f4aa3d7e348c48ca33ed0a5cd41daXCHRTP013ciscocom_-- From nobody Thu Apr 20 14:39:04 2017 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 D7F53129C60 for ; Thu, 20 Apr 2017 14:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 OkRO0VG9g-7V for ; Thu, 20 Apr 2017 14:39:00 -0700 (PDT) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6FB129459 for ; Thu, 20 Apr 2017 14:39:00 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.37,227,1488866400"; d="scan'208,217"; a="90631916" Received: from unknown (HELO g05usexrtxa03.g05.fujitsu.local) ([168.127.194.63]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES256-SHA; 20 Apr 2017 16:39:01 -0500 Received: from g05usexrtxa05.g05.fujitsu.local (168.127.194.65) by g05usexrtxa03.g05.fujitsu.local (168.127.194.63) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 20 Apr 2017 16:38:59 -0500 Received: from g05usexrtxa05.g05.fujitsu.local ([168.127.194.65]) by g05usexrtxa05.g05.fujitsu.local ([168.127.194.65]) with mapi id 15.00.1178.000; Thu, 20 Apr 2017 16:38:59 -0500 From: "Vasudevan.Sridharan@us.fujitsu.com" To: "Eric Voit (evoit)" CC: "Sanjay.Gera@us.fujitsu.com" , "Jing.Xu@us.fujitsu.com" , "david.terwilliger@us.fujitsu.com" , "netconf@ietf.org" , "netconf@ops.ietf.org" Thread-Topic: NETCONF Notification - Yang support Thread-Index: AdK6GDAirR2YMDiwQTO3/oeu9sXuOAAAWT0QAACWEKA= Date: Thu, 20 Apr 2017 21:38:59 +0000 Message-ID: References: <84987e7634e842f790f1332caee7257c@g05usexrtxa05.g05.fujitsu.local> <8a0f4aa3d7e348c48ca33ed0a5cd41da@XCH-RTP-013.cisco.com> In-Reply-To: <8a0f4aa3d7e348c48ca33ed0a5cd41da@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-11.0.0.1191-8.100.1062-23020.003 x-tm-as-result: No--14.197200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_e8028c2167c440dc885570ca6813a7cag05usexrtxa05g05fujitsu_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] NETCONF Notification - Yang support X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 21:39:03 -0000 --_000_e8028c2167c440dc885570ca6813a7cag05usexrtxa05g05fujitsu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, Thanks for the quick response. My question is more of a basic one - If a NE= TCONF server advertises a capability in hello exchange, is it necessary to = have a yang implementation to support the advertised capability? I don't see this in RFC5277 (may be because it was standardized before yang= RFC came into picture). I see this as a requirement in https://tools.ietf.org/html/rfc6243#section-= 4.1 Thanks, Vasu. From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, April 20, 2017 4:08 PM To: Sridharan, Vasudevan Cc: Gera, Sanjay ; Xu, Jing ; Terwilliger, David ; netconf@ietf.= org; netconf@ops.ietf.org Subject: RE: NETCONF Notification - Yang support Hi Vasudevan, Have you looked yet at: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification= s/ This is on a path to obsolete RFC-5277. Also there is work discussed at the last IETF: https://tools.ietf.org/html/draft-voit-netmod-yang-notifications2-00 is this hitting the areas in which you are asking? Eric From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Vasudevan.Srid= haran@us.fujitsu.com Sent: Thursday, April 20, 2017 4:59 PM To: netconf@ietf.org; netconf@ops.ietf.org Cc: Sanjay.Gera@us.fujitsu.com; Jing.Xu@= us.fujitsu.com; david.terwilliger@us.fujitsu= .com Subject: [Netconf] NETCONF Notification - Yang support Hi Authors, I 'm looking at the notifications.yang and nc-notifications.yang. Is this s= tandardized? RFC5277 (which predates Yang RFC6020) doesn't mention of the any yang for n= otifications. So can you please guide me on the status of this yang. Is a N= ETCONF server/client compliant with RFC5277 expected to support this yang f= or schema discovery or is it an inherent capability as part of "urn:ietf:pa= rams:netconf:capability:notification:1.0" capability? Thanks a lot in advance for the response. Thanks, Vasudevan Sridharan. --_000_e8028c2167c440dc885570ca6813a7cag05usexrtxa05g05fujitsu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

Thanks for the quick r= esponse. My question is more of a basic one – If a NETCONF server adv= ertises a capability in hello exchange, is it necessary to have a yang impl= ementation to support the advertised capability?

 

I don’t see this= in RFC5277 (may be because it was standardized before yang RFC came into p= icture).

 

I see this as a requir= ement in https://tools.ietf.org/html/rfc6243#section-4.1

 

Thanks,

Vasu.

 

From: Eric Voit (evoit) [mailto:evoit@cisco.c= om]
Sent: Thursday, April 20, 2017 4:08 PM
To: Sridharan, Vasudevan <Vasudevan.Sridharan@us.fujitsu.com><= br> Cc: Gera, Sanjay <Sanjay.Gera@us.fujitsu.com>; Xu, Jing <Ji= ng.Xu@us.fujitsu.com>; Terwilliger, David <david.terwilliger@us.fujit= su.com>; netconf@ietf.org; netconf@ops.ietf.org
Subject: RE: NETCONF Notification - Yang support

 

Hi Vasudevan,

 

Have you looked yet at= :

https:/= /datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/<= o:p>

This is on a path to o= bsolete RFC-5277.

 

Also there is work dis= cussed at the last IETF:

https://tools.ie= tf.org/html/draft-voit-netmod-yang-notifications2-00<= /p>

is this hitting the ar= eas in which you are asking?


Eric

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of V= asudevan.Sridharan@us.fujitsu.com
Sent: Thursday, April 20, 2017 4:59 PM
To: netconf@ietf.org; netconf@ops.ietf.org
Cc: Sanjay.Gera@us.fuj= itsu.com; Jing.Xu@us.fujitsu.com; david.terwilliger@us.fujitsu.com
Subject: [Netconf] NETCONF Notification - Yang support

 

Hi Authors,

 

I ‘m looking at the notifications.yang and nc-= notifications.yang. Is this standardized?

 

RFC5277 (which predates Yang RFC6020) doesn’t = mention of the any yang for notifications. So can you please guide me on th= e status of this yang. Is a NETCONF server/client compliant with RFC5277 ex= pected to support this yang for schema discovery or is it an inherent capability as part of “urn:ietf:params:netco= nf:capability:notification:1.0” capability?

 

Thanks a lot in advance for the response.=

 

Thanks,

Vasudevan Sridharan.

--_000_e8028c2167c440dc885570ca6813a7cag05usexrtxa05g05fujitsu_-- From nobody Thu Apr 20 15:19:05 2017 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 9147E1316EA for ; Thu, 20 Apr 2017 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 S_6WEc9gcSvT for ; Thu, 20 Apr 2017 15:18:54 -0700 (PDT) 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 8ADD8128799 for ; Thu, 20 Apr 2017 15:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14821; q=dns/txt; s=iport; t=1492726734; x=1493936334; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xJrQVCnszGtOJ+72ja21/w/Z08sL9QSMmWBWzAxaj34=; b=lA2Tjr5Jl0Rv/KS7LpgVMG7gkhTotjyyhVcePxebfESpQLIUU1h18OUC 01aZqAGiosUXM43nuvoZDHpWcLA68nATA3neOCyj9VSsCvH5cd76YT+WM WosPeJYamByC5iyMjTU9txkpbvtTyDWcHK/AbiGjHqyJYcyu6Tk8gkPIV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAAD9MvlY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYEMB411kWiQLoU1gg8uhXYCg30/GAECAQEBAQEBAWsdC4U?= =?us-ascii?q?VAQEBAQMtSgIQAgEIEQQBASgHMhQJCAEBBA4FCAGKEw6sOYsiAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYZThHaEQSQohS8FlkCGdAGHFItlggmFM4oilBMBHziBBWM?= =?us-ascii?q?Vhyl1AYgggQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,227,1488844800"; d="scan'208,217";a="415349133" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2017 22:18:52 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3KMIqIt004712 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2017 22:18:52 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 18:18:51 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 18:18:51 -0400 From: "Eric Voit (evoit)" To: "Vasudevan.Sridharan@us.fujitsu.com" CC: "Sanjay.Gera@us.fujitsu.com" , "Jing.Xu@us.fujitsu.com" , "david.terwilliger@us.fujitsu.com" , "netconf@ietf.org" , "netconf@ops.ietf.org" Thread-Topic: NETCONF Notification - Yang support Thread-Index: AdK6GDAirR2YMDiwQTO3/oeu9sXuOAAAWT0QAACWEKAAAb7TwA== Date: Thu, 20 Apr 2017 22:18:51 +0000 Message-ID: References: <84987e7634e842f790f1332caee7257c@g05usexrtxa05.g05.fujitsu.local> <8a0f4aa3d7e348c48ca33ed0a5cd41da@XCH-RTP-013.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_c611dbbe42534524b63aa5cadd79f1efXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] NETCONF Notification - Yang support X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 22:18:58 -0000 --_000_c611dbbe42534524b63aa5cadd79f1efXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If I am reading your thread right, you are looking at models like: http://www.netconfcentral.org/modules/nc-notifications/2008-07-14 and seeing if they have been standardized. They have not. As RFC 5277 predated yang, there is no yang-model. But "urn:ietf:params:netconf:capability:notification:1.0" Is still advertised. This is not an issue. https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification= s/ will eventually advertise: "urn:ietf:params:netconf:capability:notification:2.0" with a yang model behind it. Eric From: Vasudevan.Sridharan@us.fujitsu.com [mailto:Vasudevan.Sridharan@us.fuj= itsu.com] Sent: Thursday, April 20, 2017 5:39 PM To: Eric Voit (evoit) Cc: Sanjay.Gera@us.fujitsu.com; Jing.Xu@us.fujitsu.com; david.terwilliger@u= s.fujitsu.com; netconf@ietf.org; netconf@ops.ietf.org Subject: RE: NETCONF Notification - Yang support Eric, Thanks for the quick response. My question is more of a basic one - If a NE= TCONF server advertises a capability in hello exchange, is it necessary to = have a yang implementation to support the advertised capability? I don't see this in RFC5277 (may be because it was standardized before yang= RFC came into picture). I see this as a requirement in https://tools.ietf.org/html/rfc6243#section-= 4.1 Thanks, Vasu. From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, April 20, 2017 4:08 PM To: Sridharan, Vasudevan > Cc: Gera, Sanjay >; Xu, Jing >; Te= rwilliger, David >; netconf@ietf.org; netconf@ops.i= etf.org Subject: RE: NETCONF Notification - Yang support Hi Vasudevan, Have you looked yet at: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification= s/ This is on a path to obsolete RFC-5277. Also there is work discussed at the last IETF: https://tools.ietf.org/html/draft-voit-netmod-yang-notifications2-00 is this hitting the areas in which you are asking? Eric From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Vasudevan.Srid= haran@us.fujitsu.com Sent: Thursday, April 20, 2017 4:59 PM To: netconf@ietf.org; netconf@ops.ietf.org Cc: Sanjay.Gera@us.fujitsu.com; Jing.Xu@= us.fujitsu.com; david.terwilliger@us.fujitsu= .com Subject: [Netconf] NETCONF Notification - Yang support Hi Authors, I 'm looking at the notifications.yang and nc-notifications.yang. Is this s= tandardized? RFC5277 (which predates Yang RFC6020) doesn't mention of the any yang for n= otifications. So can you please guide me on the status of this yang. Is a N= ETCONF server/client compliant with RFC5277 expected to support this yang f= or schema discovery or is it an inherent capability as part of "urn:ietf:pa= rams:netconf:capability:notification:1.0" capability? Thanks a lot in advance for the response. Thanks, Vasudevan Sridharan. --_000_c611dbbe42534524b63aa5cadd79f1efXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If I am reading your t= hread right, you are looking at models like:

http://www.netconfc= entral.org/modules/nc-notifications/2008-07-14

and seeing if they hav= e been standardized.   They have not. 

 

As RFC 5277 predated y= ang, there is no yang-model.  But

"urn:ietf:params:= netconf:capability:notification:1.0"

Is still advertised.&n= bsp; This is not an issue.

 

https:/= /datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/<= o:p>

will eventually advert= ise:

"urn:ietf:params:= netconf:capability:notification:2.0"

with a yang model behi= nd it.

 

Eric

 

From: Vasudevan.Sridharan@us.fujitsu.com [mai= lto:Vasudevan.Sridharan@us.fujitsu.com]
Sent: Thursday, April 20, 2017 5:39 PM
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: Sanjay.Gera@us.fujitsu.com; Jing.Xu@us.fujitsu.com; david.terwil= liger@us.fujitsu.com; netconf@ietf.org; netconf@ops.ietf.org
Subject: RE: NETCONF Notification - Yang support

 

Eric,

 

Thanks for the quick r= esponse. My question is more of a basic one – If a NETCONF server adv= ertises a capability in hello exchange, is it necessary to have a yang impl= ementation to support the advertised capability?

 

I don’t see this= in RFC5277 (may be because it was standardized before yang RFC came into p= icture).

 

I see this as a requir= ement in https://tools.ietf.org/html/rfc6243#section-4.1

 

Thanks,

Vasu.

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Thursday, April 20, 2017 4:08 PM
To: Sridharan, Vasudevan <Vasudevan.Sridharan@us.fujitsu.com>
Cc: Gera, Sanjay <S= anjay.Gera@us.fujitsu.com>; Xu, Jing <Jing.Xu@us.fujitsu.com>; Terwilliger, David <david.terwilliger@us.fujitsu= .com>; netconf@ietf.org; netconf@ops.ietf.org
Subject: RE: NETCONF Notification - Yang support

 

Hi Vasudevan,

 

Have you looked yet at= :

https:/= /datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/<= o:p>

This is on a path to o= bsolete RFC-5277.

 

Also there is work dis= cussed at the last IETF:

https://tools.ie= tf.org/html/draft-voit-netmod-yang-notifications2-00<= /p>

is this hitting the ar= eas in which you are asking?


Eric

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of V= asudevan.Sridharan@us.fujitsu.com
Sent: Thursday, April 20, 2017 4:59 PM
To: netconf@ietf.org; netconf@ops.ietf.org
Cc: Sanjay.Gera@us.fuj= itsu.com; Jing.Xu@us.fujitsu.com; david.terwilliger@us.fujitsu.com
Subject: [Netconf] NETCONF Notification - Yang support

 

Hi Authors,

 

I ‘m looking at the notifications.yang and nc-= notifications.yang. Is this standardized?

 

RFC5277 (which predates Yang RFC6020) doesn’t = mention of the any yang for notifications. So can you please guide me on th= e status of this yang. Is a NETCONF server/client compliant with RFC5277 ex= pected to support this yang for schema discovery or is it an inherent capability as part of “urn:ietf:params:netco= nf:capability:notification:1.0” capability?

 

Thanks a lot in advance for the response.=

 

Thanks,

Vasudevan Sridharan.

--_000_c611dbbe42534524b63aa5cadd79f1efXCHRTP013ciscocom_-- From nobody Thu Apr 20 15:20:57 2017 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 3371C1316D6 for ; Thu, 20 Apr 2017 15:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 ACncF6CcR1BB for ; Thu, 20 Apr 2017 15:20:53 -0700 (PDT) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12521316EA for ; Thu, 20 Apr 2017 15:20:52 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.37,227,1488866400"; d="scan'208,217"; a="90633393" Received: from unknown (HELO g05usexrtxa03.g05.fujitsu.local) ([168.127.194.63]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES256-SHA; 20 Apr 2017 17:20:52 -0500 Received: from g05usexrtxa05.g05.fujitsu.local (168.127.194.65) by g05usexrtxa03.g05.fujitsu.local (168.127.194.63) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 20 Apr 2017 17:20:51 -0500 Received: from g05usexrtxa05.g05.fujitsu.local ([168.127.194.65]) by g05usexrtxa05.g05.fujitsu.local ([168.127.194.65]) with mapi id 15.00.1178.000; Thu, 20 Apr 2017 17:20:51 -0500 From: "Vasudevan.Sridharan@us.fujitsu.com" To: "Eric Voit (evoit)" CC: "Sanjay.Gera@us.fujitsu.com" , "Jing.Xu@us.fujitsu.com" , "david.terwilliger@us.fujitsu.com" , "netconf@ietf.org" , "netconf@ops.ietf.org" Thread-Topic: NETCONF Notification - Yang support Thread-Index: AdK6GDAirR2YMDiwQTO3/oeu9sXuOAAAWT0QAACWEKAAAb7TwAAAWR5g Date: Thu, 20 Apr 2017 22:20:51 +0000 Message-ID: <1d28a02d31414a748f8ca08f206ec00d@g05usexrtxa05.g05.fujitsu.local> References: <84987e7634e842f790f1332caee7257c@g05usexrtxa05.g05.fujitsu.local> <8a0f4aa3d7e348c48ca33ed0a5cd41da@XCH-RTP-013.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-11.0.0.1191-8.100.1062-23020.003 x-tm-as-result: No--20.591900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_1d28a02d31414a748f8ca08f206ec00dg05usexrtxa05g05fujitsu_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] NETCONF Notification - Yang support X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 22:20:56 -0000 --_000_1d28a02d31414a748f8ca08f206ec00dg05usexrtxa05g05fujitsu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks again Eric for the quick response! From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, April 20, 2017 5:19 PM To: Sridharan, Vasudevan Cc: Gera, Sanjay ; Xu, Jing ; Terwilliger, David ; netconf@ietf.= org; netconf@ops.ietf.org Subject: RE: NETCONF Notification - Yang support If I am reading your thread right, you are looking at models like: http://www.netconfcentral.org/modules/nc-notifications/2008-07-14 and seeing if they have been standardized. They have not. As RFC 5277 predated yang, there is no yang-model. But "urn:ietf:params:netconf:capability:notification:1.0" Is still advertised. This is not an issue. https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification= s/ will eventually advertise: "urn:ietf:params:netconf:capability:notification:2.0" with a yang model behind it. Eric From: Vasudevan.Sridharan@us.fujitsu.com [mailto:Vasudevan.Sridharan@us.fujitsu.com] Sent: Thursday, April 20, 2017 5:39 PM To: Eric Voit (evoit) > Cc: Sanjay.Gera@us.fujitsu.com; Jing.Xu@= us.fujitsu.com; david.terwilliger@us.fujitsu= .com; netconf@ietf.org; netconf@ops.ietf.org Subject: RE: NETCONF Notification - Yang support Eric, Thanks for the quick response. My question is more of a basic one - If a NE= TCONF server advertises a capability in hello exchange, is it necessary to = have a yang implementation to support the advertised capability? I don't see this in RFC5277 (may be because it was standardized before yang= RFC came into picture). I see this as a requirement in https://tools.ietf.org/html/rfc6243#section-= 4.1 Thanks, Vasu. From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, April 20, 2017 4:08 PM To: Sridharan, Vasudevan > Cc: Gera, Sanjay >; Xu, Jing >; Te= rwilliger, David >; netconf@ietf.org; netconf@ops.i= etf.org Subject: RE: NETCONF Notification - Yang support Hi Vasudevan, Have you looked yet at: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification= s/ This is on a path to obsolete RFC-5277. Also there is work discussed at the last IETF: https://tools.ietf.org/html/draft-voit-netmod-yang-notifications2-00 is this hitting the areas in which you are asking? Eric From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Vasudevan.Srid= haran@us.fujitsu.com Sent: Thursday, April 20, 2017 4:59 PM To: netconf@ietf.org; netconf@ops.ietf.org Cc: Sanjay.Gera@us.fujitsu.com; Jing.Xu@= us.fujitsu.com; david.terwilliger@us.fujitsu= .com Subject: [Netconf] NETCONF Notification - Yang support Hi Authors, I 'm looking at the notifications.yang and nc-notifications.yang. Is this s= tandardized? RFC5277 (which predates Yang RFC6020) doesn't mention of the any yang for n= otifications. So can you please guide me on the status of this yang. Is a N= ETCONF server/client compliant with RFC5277 expected to support this yang f= or schema discovery or is it an inherent capability as part of "urn:ietf:pa= rams:netconf:capability:notification:1.0" capability? Thanks a lot in advance for the response. Thanks, Vasudevan Sridharan. --_000_1d28a02d31414a748f8ca08f206ec00dg05usexrtxa05g05fujitsu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks again Eric for = the quick response!

 

From: Eric Voit (evoit) [mailto:evoit@cisco.c= om]
Sent: Thursday, April 20, 2017 5:19 PM
To: Sridharan, Vasudevan <Vasudevan.Sridharan@us.fujitsu.com><= br> Cc: Gera, Sanjay <Sanjay.Gera@us.fujitsu.com>; Xu, Jing <Ji= ng.Xu@us.fujitsu.com>; Terwilliger, David <david.terwilliger@us.fujit= su.com>; netconf@ietf.org; netconf@ops.ietf.org
Subject: RE: NETCONF Notification - Yang support

 

If I am reading your t= hread right, you are looking at models like:

http://www.netconfc= entral.org/modules/nc-notifications/2008-07-14

and seeing if they hav= e been standardized.   They have not. 

 

As RFC 5277 predated y= ang, there is no yang-model.  But

"urn:ietf:params:= netconf:capability:notification:1.0"

Is still advertised.&n= bsp; This is not an issue.

 

https:/= /datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/<= o:p>

will eventually advert= ise:

"urn:ietf:params:= netconf:capability:notification:2.0"

with a yang model behi= nd it.

 

Eric

 

 

Eric,

 

Thanks for the quick r= esponse. My question is more of a basic one – If a NETCONF server adv= ertises a capability in hello exchange, is it necessary to have a yang impl= ementation to support the advertised capability?

 

I don’t see this= in RFC5277 (may be because it was standardized before yang RFC came into p= icture).

 

I see this as a requir= ement in https://tools.ietf.org/html/rfc6243#section-4.1

 

Thanks,

Vasu.

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Thursday, April 20, 2017 4:08 PM
To: Sridharan, Vasudevan <Vasudevan.Sridharan@us.fujitsu.com>
Cc: Gera, Sanjay <S= anjay.Gera@us.fujitsu.com>; Xu, Jing <Jing.Xu@us.fujitsu.com>; Terwilliger, David <david.terwilliger@us.fujitsu= .com>; netconf@ietf.org; netconf@ops.ietf.org
Subject: RE: NETCONF Notification - Yang support

 

Hi Vasudevan,

 

Have you looked yet at= :

https:/= /datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/<= o:p>

This is on a path to o= bsolete RFC-5277.

 

Also there is work dis= cussed at the last IETF:

https://tools.ie= tf.org/html/draft-voit-netmod-yang-notifications2-00<= /p>

is this hitting the ar= eas in which you are asking?


Eric

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of V= asudevan.Sridharan@us.fujitsu.com
Sent: Thursday, April 20, 2017 4:59 PM
To: netconf@ietf.org; netconf@ops.ietf.org
Cc: Sanjay.Gera@us.fuj= itsu.com; Jing.Xu@us.fujitsu.com; david.terwilliger@us.fujitsu.com
Subject: [Netconf] NETCONF Notification - Yang support

 

Hi Authors,

 

I ‘m looking at the notifications.yang and nc-= notifications.yang. Is this standardized?

 

RFC5277 (which predates Yang RFC6020) doesn’t = mention of the any yang for notifications. So can you please guide me on th= e status of this yang. Is a NETCONF server/client compliant with RFC5277 ex= pected to support this yang for schema discovery or is it an inherent capability as part of “urn:ietf:params:netco= nf:capability:notification:1.0” capability?

 

Thanks a lot in advance for the response.=

 

Thanks,

Vasudevan Sridharan.

--_000_1d28a02d31414a748f8ca08f206ec00dg05usexrtxa05g05fujitsu_-- From nobody Tue Apr 25 01:04:19 2017 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 7CF301319FB; Tue, 25 Apr 2017 01:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 GqbiZaAfp7gW; Tue, 25 Apr 2017 01:04:10 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06AE51319FC; Tue, 25 Apr 2017 01:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1734; q=dns/txt; s=iport; t=1493107449; x=1494317049; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=YcWDO6zcugvVroL51kp6NEoTRiiC3Yrq8EB1T+at3kk=; b=ipZMBlR/umlr4F5BIReThX7EDixhtd3hLaNRliHRcxbYOEkWI10pgxSz BDqwxO5UcbbPnttIpc3FMAAuYnrAynp00r3b7znXEEQ2fF3RvI04b4AXx R24n/hOvvFF9JoUZmJzJAbz8Jh6rGLY4QA/y1QhjPQ7Iu5GKPpOI62pVS A=; X-IronPort-AV: E=Sophos;i="5.37,248,1488844800"; d="scan'208";a="651390816" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 08:04:07 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3P84685030714; Tue, 25 Apr 2017 08:04:06 GMT To: Alvaro Retana , The IESG References: <149209076012.15666.6288668415150289747.idtracker@ietfa.amsl.com> Cc: netconf-chairs@ietf.org, netconf@ietf.org From: Benoit Claise Message-ID: <2b72214e-ba1b-2903-1569-92761d958566@cisco.com> Date: Tue, 25 Apr 2017 10:04:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149209076012.15666.6288668415150289747.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Alvaro Retana's No Objection on charter-ietf-netconf-18-10: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:04:12 -0000 FYI, NETCONF WG. I clarified the situation with Alvaro during the IESG telechat. No action is needed on this one. Regards, Benoit > Alvaro Retana has entered the following ballot position for > charter-ietf-netconf-18-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-netconf/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The first paragraph... > > The NETCONF Working Group, previously named after the NETCONF protocol, > now renamed as the NETwork CONFiguration Working Group, is responsible > for the development and maintenance of protocols for YANG data model > driven management, for the necessary framework where these protocols run, > and for the YANG modules that formalize protocol behavior and are > required from a protocol perspective. > > ...seems to have significantly widened what the netconf WG is > responsible for beyond NETCONF/RESTCONF, but the rest of the charter only > talks about those two protocols. If the intent is to allow the WG to > work on other protocols (or at least consider them if they exist, are > brought to the WG, etc.), then it may be a good idea to include text that > specifically mentions it. > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From nobody Tue Apr 25 01:52:18 2017 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 B2A6F12946E; Tue, 25 Apr 2017 01:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 ziZR2Iu3xjeA; Tue, 25 Apr 2017 01:52:07 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EC7129493; Tue, 25 Apr 2017 01:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10230; q=dns/txt; s=iport; t=1493110327; x=1494319927; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=PCuU3VsohdccEgtCcAAWBDXUl3qEWRllztkPdx+OyDo=; b=F+Kxeg+Lsx+AaLwL/s+7REgZwgNzl/iaEV3Am5eYOb2zNGrQvauuWvuM hVvx5RS+f0h0Z1sxDZtxpRV6mBYQKiz5ZXnOUU8O8pWjZhPEnMlUlX43U Ff+55LM2lRgdjmKbcvlLnWsfwCeVJ5joVpmj0srbco9tCJQS45orIXIyk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAQDnDf9Y/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgymBDIRzihVzkHmQMIU1gg8uhXYChFkYAQIBAQEBAQEBayiFFgE?= =?us-ascii?q?EASNWEAsONAICVwYBDAgBAYoQCA6qfIImK4pyAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGAWGU4IIgm6EKREBgyKCXwWJOo0PhniHF4MxiD6CAIUzg0KGYot4iCEfOH4?= =?us-ascii?q?IJh0IGBWHLj6HPYIuAQEB?= X-IronPort-AV: E=Sophos;i="5.37,248,1488844800"; d="scan'208,217";a="693955995" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 08:52:04 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3P8q3kt009295; Tue, 25 Apr 2017 08:52:04 GMT To: Alia Atlas , The IESG References: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> Cc: netconf-chairs@ietf.org, netconf@ietf.org From: Benoit Claise Message-ID: <0127af84-63b2-e9fe-4df1-25cedb1fd312@cisco.com> Date: Tue, 25 Apr 2017 10:52:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7CCD0EC6F3BC2C1DA71EC0F4" Archived-At: Subject: Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:52:10 -0000 This is a multi-part message in MIME format. --------------7CCD0EC6F3BC2C1DA71EC0F4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, In order to progress this charter, I would like to clarify one point with the revised datastore concept authors. See below. > Alia, > >> Alia Atlas has entered the following ballot position for >> charter-ietf-netconf-18-10: Block >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-netconf/ >> >> >> >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> This charter uses the term "I2RS protocol" and I2RS isn't doing its own >> protocol. > I'm actually glad you made that point. I introduced that term to make > sure we cover I2RS, but I've not been happy about it. I could not find > the right wordings. >> >> Now, what I heard secondhand is that the intent is for NetConf to >> defined >> the needed >> capabilities so that the I2RS WG can define the necessary extensions - >> probably to >> RestConf - to support the well-documented requirements. > > You're right, the revised DS document specifies the needed > capabilities. See > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores#appendix-B > > Thinking about the text. > > OLD: Define capabilities for NETCONF and RESTCONF to support I2RS > protocol and ephemeral-state datastore requirements. > > NEW: Define capabilities for NETCONF and RESTCONF to support I2RS and > ephemeral-state datastore requirements. > > Or even better, IMO > NEW: Define capabilities for NETCONF and RESTCONF to support the > ephemeral-state datastore requirements. > > Now, wait. Actually, I believe you should have all you need for I2RS > part of entry 6 > 6. Based on the revised datastore concept work in NETMOD, provide a > revision for the NETCONF and RESTCONF protocols and the used datastore > framework. > > In the end, we could remove the point 7. The current charter is at https://datatracker.ietf.org/doc/charter-ietf-netconf/ Am I correct that the entry 6 will cover all the new NETCONF/RESTCONF capabilities that I2RS might need, based on draft-ietf-netmod-revised-datastores? Am I correct that it will be up to I2RS authors to specify the I2RS datastore semantic, persistence, guidelines, along with the I2RS concept of priorities? If yes to both questions, the current charter point 7 is not right ... 7. Define capabilities for NETCONF and RESTCONF to support I2RS protocol and ephemeral-state datastore requirements. ... because there are no new RESCONF/NETCONF capabilities needed. Hence my proposal to remove it. The last question is: what is the right place for this "I2RS datastore semantic, persistence, guidelines, along with the notion of priorities" document? Regards, Benoit > > Feedback? > > Regards, Benoit >> >> As Responsible AD for I2RS, I need to actually hear and understand the >> change and intended >> split of work. This change is going to require a recharter for I2RS, >> since it is explicitly not >> chartered to do any protocol work; the expectation has been that this >> would be done in NetConf >> and NetMod, as needed. >> >> I am quite positive on the idea of letting the I2RS WG define the >> necessary extensions and >> finally be able to move at the speed appropriate to the active >> contributors - but we need >> to be correct in terminology, clear on the work split, and understand >> how >> this will proceed. >> >> >> >> >> . >> > > . > --------------7CCD0EC6F3BC2C1DA71EC0F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

In order to progress this charter, I would like to clarify one point with the revised datastore concept authors. See below.
Alia,

Alia Atlas has entered the following ballot position for
charter-ietf-netconf-18-10: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-netconf/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

This charter uses the term "I2RS protocol" and I2RS isn't doing its own
protocol.
I'm actually glad you made that point. I introduced that term to make sure we cover I2RS, but I've not been happy about it. I could not find the right wordings.

Now, what I heard secondhand is that the intent is for NetConf to defined
the needed
capabilities so that the I2RS WG can define the necessary extensions -
probably to
RestConf - to support the well-documented requirements.

You're right, the revised DS document specifies the needed capabilities. See https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores#appendix-B

Thinking about the text.

OLD: Define capabilities for NETCONF and RESTCONF to support I2RS protocol and ephemeral-state datastore requirements.

NEW: Define capabilities for NETCONF and RESTCONF to support I2RS and ephemeral-state datastore requirements.

Or even better, IMO
NEW: Define capabilities for NETCONF and RESTCONF to support the ephemeral-state datastore requirements.

Now, wait. Actually, I believe you should have all you need for I2RS part of entry 6
6. Based on the revised datastore concept work in NETMOD, provide a revision for the NETCONF and RESTCONF protocols and the used datastore framework.

In the end, we could remove the point 7.
The current charter is at https://datatracker.ietf.org/doc/charter-ietf-netconf/

Am I correct that the entry 6 will cover all the new NETCONF/RESTCONF capabilities that I2RS might need, based on draft-ietf-netmod-revised-datastores?
Am I correct that it will be up to I2RS authors to specify the I2RS datastore semantic, persistence, guidelines, along with the I2RS concept of priorities?
If yes to both questions, the current charter point 7 is not right ...
7. Define capabilities for NETCONF and RESTCONF to support I2RS protocol
and ephemeral-state datastore requirements.
... because there are no new RESCONF/NETCONF capabilities needed.
Hence my proposal to remove it.

The last question is: what is the right place for this  "I2RS datastore semantic, persistence, guidelines, along with the notion of priorities" document?

Regards, Benoit


Feedback?

Regards, Benoit

As Responsible AD for I2RS, I need to actually hear and understand the
change and intended
split of work.  This change is going to require a recharter for I2RS,
since it is explicitly not
chartered to do any protocol work; the expectation has been that this
would be done in NetConf
and NetMod, as needed.

I am quite positive on the idea of letting the I2RS WG define the
necessary extensions and
finally be able to move at the speed appropriate to the active
contributors - but we need
to be correct in terminology, clear on the work split, and understand how
this will proceed.




.


.


--------------7CCD0EC6F3BC2C1DA71EC0F4-- From nobody Tue Apr 25 09:45:49 2017 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 CEFDA1316A3; Tue, 25 Apr 2017 09:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 C8tgJ8HleX0r; Tue, 25 Apr 2017 09:45:36 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F976131657; Tue, 25 Apr 2017 09:45:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5B5F1676; Tue, 25 Apr 2017 18:45:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 9ntDK7tPvzdw; Tue, 25 Apr 2017 18:45:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 25 Apr 2017 18:45:35 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 457D820053; Tue, 25 Apr 2017 18:45:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lj2QEbPKJyAR; Tue, 25 Apr 2017 18:45:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFB5020050; Tue, 25 Apr 2017 18:45:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2327C3F2C49A; Tue, 25 Apr 2017 18:45:36 +0200 (CEST) Date: Tue, 25 Apr 2017 18:45:36 +0200 From: Juergen Schoenwaelder To: Benoit Claise Cc: Alia Atlas , The IESG , netconf-chairs@ietf.org, netconf@ietf.org Message-ID: <20170425164536.GA37805@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Benoit Claise , Alia Atlas , The IESG , netconf-chairs@ietf.org, netconf@ietf.org References: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> <0127af84-63b2-e9fe-4df1-25cedb1fd312@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0127af84-63b2-e9fe-4df1-25cedb1fd312@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 16:45:39 -0000 On Tue, Apr 25, 2017 at 10:52:02AM +0200, Benoit Claise wrote: > Dear all, > > In order to progress this charter, I would like to clarify one point with > the revised datastore concept authors. See below. [...] > The last question is: what is the right place for this "I2RS datastore > semantic, persistence, guidelines, along with the notion of priorities" > document? Here is my take: a) Once we have NMDA extensions in place, the protocols (NETCONF and RESTCONF) should not need any additional protocol work to support I2RS. If the NETCONF WG, for whatever reason, fails to reach this goal, then I think it should be the NETCONF WG's task to fix this. b) Once we have NMDA extensions in place, the definition of an I2RS datastore with its specific semantics should be done in the I2RS working group. None of this should require _changes_ to the NMDA enabled NETCONF/RESTCONF protocols or the YANG language. If the NETCONF WG and the NETMOD WG, for whatever reason, fails to reach this goal, then I think it should be the NETCONF or NETMOD WG's task to fix this. In other words, my hope is that the NMDA solution provides a workable separation of concerns. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 25 11:45:59 2017 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 B9018131789; Tue, 25 Apr 2017 11:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 L4HdHIwsJAnh; Tue, 25 Apr 2017 11:45:48 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673BE131787; Tue, 25 Apr 2017 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bkwdGdA4V90TE9/tG4V8M+5F5U3LuFdCIMSvEGZnDbM=; b=Sjnes5vPp/Tcoe/m/i58t2jeozmV5EkN9FMauG/FEJjjjL8GPMB+bc5hTqq+aqr5yNPFbv3OtI6d8yMBDh41z6mAqNyNhFlrd9NKfJEh2B8xqqxv790+uWloUGfpVpzDU0zf3wCRJctOyDhpHhRxp/UINVPmsGk/oScVQe6m3Bk= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 18:45:46 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1061.011; Tue, 25 Apr 2017 18:45:46 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Benoit Claise" CC: "netconf@ietf.org" , "netconf-chairs@ietf.org" , The IESG , Alia Atlas Thread-Topic: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) Thread-Index: AQHSs6VuOZMRwjkjZkOAbNfm1luKFKHCCrmAgBPQZQCAAIRQAP//3oSA Date: Tue, 25 Apr 2017 18:45:46 +0000 Message-ID: <956293CB-8922-4E4A-A096-76EEB89FB8B3@juniper.net> References: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> <0127af84-63b2-e9fe-4df1-25cedb1fd312@cisco.com> <20170425164536.GA37805@elstar.local> In-Reply-To: <20170425164536.GA37805@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:OF+h2Z1QnuiWy32uPFDQA3UoB++DX0ieUidze8LphGIaHeN4blMRxvVU71hrxldBX4mnJYlROvdheC1KD0oPZPCDKIXApm46TtLiU3mJ4FCX7C5Xgi8u+fA7pJDbiVHMwMMvCbn4tA1W7cMjpz+SJqdWG7YmeM21iLE0v1gulSjVNa4bpYIadjt8AfLu6VNjOYTVsyAqp6lBpdh6oVDpkmJpSio4pNRvEnjfVmKa2TXMrstdlySEDNqguRtEBwP/GPn3E+XAfpIOkTwOzZ5Zhq5L6Rkj3aQtBcsxIv883wYYB89CyX2S9ZKt9w7pWbgd2YAtvrOIdOIQVoufNDYPEQ== x-ms-office365-filtering-correlation-id: 33f8c7c1-20f5-44d3-9f58-08d48c0b4953 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39860400002)(39410400002)(24454002)(81166006)(8676002)(229853002)(39060400002)(4326008)(3660700001)(83716003)(3280700002)(3846002)(102836003)(8936002)(6116002)(6436002)(25786009)(36756003)(82746002)(83506001)(4001350100001)(50986999)(76176999)(6246003)(54356999)(38730400002)(2906002)(189998001)(305945005)(86362001)(7736002)(230783001)(53936002)(5660300001)(77096006)(6486002)(6512007)(54906002)(6306002)(66066001)(99286003)(106356001)(93886004)(2900100001)(6506006)(122556002)(2950100002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <85BBB2C3386F4744895F10675B2F0B1C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 18:45:46.6386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Subject: Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 18:45:51 -0000 DQpNeSB0YWtlIGlzIHRoYXQsIG9uY2Ugd2UgdXBkYXRlIE5DL1JDIHRvIHN1cHBvcnQgdGhlIGlu dGVuZGVkLCBkeW5hbWljLCBhbmQgb3BlcmF0aW9uYWwgZGF0YXN0b3JlcywgdGhhdCB3aWxsIGdv IGEgbG9uZyB3YXkgdG93YXJkcyBhY2hpZXZpbmcgd2hhdCBJMlJTIG5lZWRzLCBtYXliZSBldmVu IGFsbCB0aGUgd2F5LiAgVGhhdCBzYWlkLCBJIGRvbuKAmXQga25vdyBob3cgZ2VuZXJpYyBzb21l IG9mIHRoZSB0aGluZ3MgZGlzY3Vzc2VkIGluIHRoZSBmb2xsb3dpbmcgY2FuIGJlIG1hZGU6DQoN CiAgZHJhZnQtaGFyZXMtbmV0bW9kLWkycnMteWFuZw0KICBkcmFmdC1oYXJlcy1uZXRjb25mLWky cnMtbmV0Y29uZg0KICBkcmFmdC1oYXJlcy1uZXRjb25mLWkycnMtcmVzdGNvbmYNCg0KRm9yIGlu c3RhbmNlLCB0aGUgc2Vjb25kYXJ5IHByaW9yaXR5IGNvbmNlcHQgc2VlbXMgdmVyeSB1bmlxdWUg dG8gSTJSUyBhbmQgdGh1cyBtYXkgZW50YWlsIGFuIEkyUlMtc3BlY2lmaWMgcGFyYW1ldGVyIHBh c3NlZCBpbiA8ZWRpdC1kYXRhPi4gIEZvciBleHRlbnNpb25zIHN1Y2ggYXMgdGhpcywgSSB3b3Vs ZCB0aGluayB0aGV5J2QgYmUgZG9uZSBpbiBJMlJTLg0KDQpUbyBhbnN3ZXIgQmVub2l0J3MgcXVl c3Rpb24sIEkgYWdyZWUgdGhhdCAjNyBzZWVtcyBvdXQgb2YgcGxhY2UuICBJZiB3ZSByZW1vdmUg aXQsIHRoZW4gIzYgbWlnaHQgYmUgYmV0dGVyIHdyaXR0ZW46DQoNCk9MRA0KICBCYXNlZCBvbiB0 aGUgcmV2aXNlZCBkYXRhc3RvcmUgY29uY2VwdCB3b3JrIGluIE5FVE1PRCwgLi4uDQpORVcNCiAg QmFzZWQgb24gdGhlIHJldmlzZWQgZGF0YXN0b3JlIGNvbmNlcHQgd29yayBpbiBORVRNT0QsIGFu ZA0KICBwcm90b2NvbCByZXF1aXJlbWVudHMgcHJvdmlkZWQgYnkgSTJSUywgLi4uDQoNCg0KVGhv dWdodHM/DQoNCktlbnQNCg0KDQpPbiBUdWUsIEFwciAyNSwgMjAxNyBhdCAxMDo1MjowMkFNICsw MjAwLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOg0KPiBEZWFyIGFsbCwNCj4gDQo+IEluIG9yZGVyIHRv IHByb2dyZXNzIHRoaXMgY2hhcnRlciwgSSB3b3VsZCBsaWtlIHRvIGNsYXJpZnkgb25lIHBvaW50 IHdpdGgNCj4gdGhlIHJldmlzZWQgZGF0YXN0b3JlIGNvbmNlcHQgYXV0aG9ycy4gU2VlIGJlbG93 Lg0KDQpbLi4uXQ0KIA0KPiBUaGUgbGFzdCBxdWVzdGlvbiBpczogd2hhdCBpcyB0aGUgcmlnaHQg cGxhY2UgZm9yIHRoaXMgICJJMlJTIGRhdGFzdG9yZQ0KPiBzZW1hbnRpYywgcGVyc2lzdGVuY2Us IGd1aWRlbGluZXMsIGFsb25nIHdpdGggdGhlIG5vdGlvbiBvZiBwcmlvcml0aWVzIg0KPiBkb2N1 bWVudD8NCg0KSGVyZSBpcyBteSB0YWtlOg0KDQphKSBPbmNlIHdlIGhhdmUgTk1EQSBleHRlbnNp b25zIGluIHBsYWNlLCB0aGUgcHJvdG9jb2xzIChORVRDT05GIGFuZA0KICAgUkVTVENPTkYpIHNo b3VsZCBub3QgbmVlZCBhbnkgYWRkaXRpb25hbCBwcm90b2NvbCB3b3JrIHRvIHN1cHBvcnQNCiAg IEkyUlMuIElmIHRoZSBORVRDT05GIFdHLCBmb3Igd2hhdGV2ZXIgcmVhc29uLCBmYWlscyB0byBy ZWFjaCB0aGlzDQogICBnb2FsLCB0aGVuIEkgdGhpbmsgaXQgc2hvdWxkIGJlIHRoZSBORVRDT05G IFdHJ3MgdGFzayB0byBmaXggdGhpcy4NCg0KYikgT25jZSB3ZSBoYXZlIE5NREEgZXh0ZW5zaW9u cyBpbiBwbGFjZSwgdGhlIGRlZmluaXRpb24gb2YgYW4gSTJSUw0KICAgZGF0YXN0b3JlIHdpdGgg aXRzIHNwZWNpZmljIHNlbWFudGljcyBzaG91bGQgYmUgZG9uZSBpbiB0aGUgSTJSUw0KICAgd29y a2luZyBncm91cC4gTm9uZSBvZiB0aGlzIHNob3VsZCByZXF1aXJlIF9jaGFuZ2VzXyB0byB0aGUg Tk1EQQ0KICAgZW5hYmxlZCBORVRDT05GL1JFU1RDT05GIHByb3RvY29scyBvciB0aGUgWUFORyBs YW5ndWFnZS4gSWYgdGhlDQogICBORVRDT05GIFdHIGFuZCB0aGUgTkVUTU9EIFdHLCBmb3Igd2hh dGV2ZXIgcmVhc29uLCBmYWlscyB0byByZWFjaA0KICAgdGhpcyBnb2FsLCB0aGVuIEkgdGhpbmsg aXQgc2hvdWxkIGJlIHRoZSBORVRDT05GIG9yIE5FVE1PRCBXRydzDQogICB0YXNrIHRvIGZpeCB0 aGlzLg0KDQpJbiBvdGhlciB3b3JkcywgbXkgaG9wZSBpcyB0aGF0IHRoZSBOTURBIHNvbHV0aW9u IHByb3ZpZGVzIGEgd29ya2FibGUNCnNlcGFyYXRpb24gb2YgY29uY2VybnMuDQoNCi9qcw0KDQot LSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJl bWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEg fCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAg IDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRj b25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYNCg0KDQo= From nobody Tue Apr 25 14:46:55 2017 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 CBAE7128BB6; Tue, 25 Apr 2017 14:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 IOTuC33o3u-u; Tue, 25 Apr 2017 14:46:52 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84F21272E1; Tue, 25 Apr 2017 14:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1449; q=dns/txt; s=iport; t=1493156812; x=1494366412; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=LPha+/lK4Hie2IKe/tvchgkvbLMChDlqmsIatYpxx3o=; b=ectEo/VavGZq+Rzb7WF6Xa4DIyw2WmZ6xS01WPghdg0BvwD/GE8b493e RSn7ysg93WTjB1GfnLFhfQdH1O/UrwxmRApxy+ehKlGGhW7b46vJIUet8 sEP5LpYfFnyfEoXMsanWi4VaHQ6QjygEvJebFRR2mWqJEaX1o8DYpEdBn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAADSwv9Y/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBkz1zkFshlWWCD4YkAoRUGAECAQEBAQEBAWsohRYBBTIBBVELDgo?= =?us-ascii?q?uVwYBDAgBAReKAa0XiyUBAQEBAQEBAwEBAQEBASKGU4FdKwuCY4o8AQSdQYpIi?= =?us-ascii?q?D6KdYZii3iIIR84gQYmHQgYFYcuPolrAQEB?= X-IronPort-AV: E=Sophos;i="5.37,251,1488844800"; d="scan'208";a="651409402" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 21:46:49 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3PLknpO019154; Tue, 25 Apr 2017 21:46:49 GMT To: Alia Atlas , The IESG , netconf-chairs@ietf.org, netconf@ietf.org References: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> <0127af84-63b2-e9fe-4df1-25cedb1fd312@cisco.com> <20170425164536.GA37805@elstar.local> From: Benoit Claise Message-ID: Date: Tue, 25 Apr 2017 23:46:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170425164536.GA37805@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:46:55 -0000 On 4/25/2017 6:45 PM, Juergen Schoenwaelder wrote: > On Tue, Apr 25, 2017 at 10:52:02AM +0200, Benoit Claise wrote: >> Dear all, >> >> In order to progress this charter, I would like to clarify one point with >> the revised datastore concept authors. See below. > [...] > >> The last question is: what is the right place for this "I2RS datastore >> semantic, persistence, guidelines, along with the notion of priorities" >> document? > Here is my take: > > a) Once we have NMDA extensions in place, the protocols (NETCONF and > RESTCONF) should not need any additional protocol work to support > I2RS. If the NETCONF WG, for whatever reason, fails to reach this > goal, then I think it should be the NETCONF WG's task to fix this. > > b) Once we have NMDA extensions in place, the definition of an I2RS > datastore with its specific semantics should be done in the I2RS > working group. None of this should require _changes_ to the NMDA > enabled NETCONF/RESTCONF protocols or the YANG language. If the > NETCONF WG and the NETMOD WG, for whatever reason, fails to reach > this goal, then I think it should be the NETCONF or NETMOD WG's > task to fix this. > > In other words, my hope is that the NMDA solution provides a workable > separation of concerns. As I understand, you're in favor of removing the item 7 from the charter. Thanks Jürgen. Regards, Benoit > > /js > From nobody Tue Apr 25 14:47:59 2017 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 316701275AB; Tue, 25 Apr 2017 14:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 l_TyYS7WPFyN; Tue, 25 Apr 2017 14:47:51 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51861252BA; Tue, 25 Apr 2017 14:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2354; q=dns/txt; s=iport; t=1493156871; x=1494366471; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ml4nzg0y2f/4BR8IagtM+55bGOE202AiTRHDL2D7mmY=; b=eQzXo9Z7pLW4HHd/KeRrpOnrpaIRzhrldP1pLXG6jFqeU0THFyEfmFwb ntW00w/k6siojFb0o0Dn3hYdaNltIJJoJIuH2t2LwAfU5NY3EjddWBqbA FwnCHyVsvVX0K2zLTq7zZ/4hEVdkD63NKsP6FcsOQb8P4PdvubVs/W5g1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAQALw/9Y/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBiSiKFXOQfJVlgg+GJAKEVBgBAgEBAQEBAQFrKIUWAQUjDwEFQRA?= =?us-ascii?q?LDgoCAiYCAlcGAQwIAQEXigGqcIImiyUBAQEBAQEBAQEBAQEBAQEBAQEggQuFS?= =?us-ascii?q?IFdK4Juh12CXwEEnUGKSIg+ggCIdYZiiG+DCYghHziBBiYdCBgVhS0cgWU+iWs?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.37,251,1488844800"; d="scan'208";a="693973381" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 21:47:48 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3PLlmep030398; Tue, 25 Apr 2017 21:47:48 GMT To: Kent Watsen , Juergen Schoenwaelder References: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> <0127af84-63b2-e9fe-4df1-25cedb1fd312@cisco.com> <20170425164536.GA37805@elstar.local> <956293CB-8922-4E4A-A096-76EEB89FB8B3@juniper.net> Cc: "netconf@ietf.org" , "netconf-chairs@ietf.org" , The IESG , Alia Atlas From: Benoit Claise Message-ID: <58591dea-57ac-7c26-368f-9962b24a7689@cisco.com> Date: Tue, 25 Apr 2017 23:47:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <956293CB-8922-4E4A-A096-76EEB89FB8B3@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:47:53 -0000 On 4/25/2017 8:45 PM, Kent Watsen wrote: > My take is that, once we update NC/RC to support the intended, dynamic, and operational datastores, that will go a long way towards achieving what I2RS needs, maybe even all the way. That said, I don’t know how generic some of the things discussed in the following can be made: > > draft-hares-netmod-i2rs-yang > draft-hares-netconf-i2rs-netconf > draft-hares-netconf-i2rs-restconf > > For instance, the secondary priority concept seems very unique to I2RS and thus may entail an I2RS-specific parameter passed in . For extensions such as this, I would think they'd be done in I2RS. > > To answer Benoit's question, I agree that #7 seems out of place. If we remove it, then #6 might be better written: > > OLD > Based on the revised datastore concept work in NETMOD, ... > NEW > Based on the revised datastore concept work in NETMOD, and > protocol requirements provided by I2RS, ... That makes sense. Alia, fine with you? Regards, B. > > Thoughts? > > Kent > > > On Tue, Apr 25, 2017 at 10:52:02AM +0200, Benoit Claise wrote: >> Dear all, >> >> In order to progress this charter, I would like to clarify one point with >> the revised datastore concept authors. See below. > [...] > >> The last question is: what is the right place for this "I2RS datastore >> semantic, persistence, guidelines, along with the notion of priorities" >> document? > Here is my take: > > a) Once we have NMDA extensions in place, the protocols (NETCONF and > RESTCONF) should not need any additional protocol work to support > I2RS. If the NETCONF WG, for whatever reason, fails to reach this > goal, then I think it should be the NETCONF WG's task to fix this. > > b) Once we have NMDA extensions in place, the definition of an I2RS > datastore with its specific semantics should be done in the I2RS > working group. None of this should require _changes_ to the NMDA > enabled NETCONF/RESTCONF protocols or the YANG language. If the > NETCONF WG and the NETMOD WG, for whatever reason, fails to reach > this goal, then I think it should be the NETCONF or NETMOD WG's > task to fix this. > > In other words, my hope is that the NMDA solution provides a workable > separation of concerns. > > /js > From nobody Wed Apr 26 05:29:41 2017 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 D1FB9129B6F; Wed, 26 Apr 2017 05:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0VbH5agodQzJ; Wed, 26 Apr 2017 05:29:38 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F00E129B6D; Wed, 26 Apr 2017 05:29:38 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id u65so48816863wmu.1; Wed, 26 Apr 2017 05:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=yWj+gmD7mUheVmM/FbfngC4jeZ8Bfi1098jJmBRVHEs=; b=QnS9LHucauhrHan2L0vMkffw3q0crSZlDB17u+ypQIDCZqbMkuWeXcppUkpWE2SB/s auLDnNcOOiwYkEZg1KHToo/m1Rj95w2rTuk2X3iLzcn0dJsq1tigxJFXVEbUiu3Eu8lS q6etmK6aqLZmUQCBcfXx4ZRxAHVn8vjJvnPh/1vMCqjTk+ckAtNfgLYHh59KwRdyafU4 zblM/VX/phk4ucqqo4MsbVIQc9LVcX3N6cJ20OGLyfauwtAJMreYCEuHqXFCr9c1yjwI ucUQaK9Vd3Pj7YjHbSZPtSop4AaDa5uGNoKNGZO4PiQwBemGmDkcP0gGyPIHbqeevAkU m5AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=yWj+gmD7mUheVmM/FbfngC4jeZ8Bfi1098jJmBRVHEs=; b=BRuBdUs4Lmxn61iQxrcdN7DugDzY+OrUgyxqCxU2oW6DSO25NObJ3OwBvkynAsFtdY UVgfsBnE9IQXh8wumv6j6H/fGbMXwc0hYcIFSNxrC8XwFFr5WaGP4/17d6aWn7LSVB50 KlgzbRjtaRLCSnkp4fJWu6TFIWNNyU932z5V+S1YDe8NWfrlkmgsTY+G75KjNuPRzxd8 zFVT0TNdHkNqBGoCKs6DH/XA0PKKzr3gC74Zvh7geiZuOW8Gh3Iy3aJoiJS7xNB0MUeX GIni1YLRicOb4AsBau6w3m6opa5EL4aNLuMER6t3wUfqci7gYNbBMXX4EYI4ozUiS1p1 muqg== X-Gm-Message-State: AN3rC/56J4RxB8cAIQZe0Y1ZzpXrRQu528Df8dXTV9nexG+ArWkfy/Za 8hZZNaPk2YBLjQ== X-Received: by 10.28.168.1 with SMTP id r1mr845000wme.134.1493209776463; Wed, 26 Apr 2017 05:29:36 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p508A258A.dip0.t-ipconnect.de. [80.138.37.138]) by smtp.gmail.com with ESMTPSA id h8sm4543742wmf.28.2017.04.26.05.29.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 05:29:35 -0700 (PDT) From: "Mehmet Ersue" To: "'Benoit Claise'" , "'Alia Atlas'" , "'The IESG'" , , References: <149201262002.15649.14237088936132264953.idtracker@ietfa.amsl.com> <0127af84-63b2-e9fe-4df1-25cedb1fd312@cisco.com> <20170425164536.GA37805@elstar.local> In-Reply-To: Date: Wed, 26 Apr 2017 14:29:36 +0200 Message-ID: <00f101d2be88$c4bfa790$4e3ef6b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJfJ1bW2BsYxanrYKCYphLkju1YQgIfS0T9Ai0n6x4B5d6AyAIxTzx+oHuhDsA= Content-Language: de Archived-At: Subject: Re: [Netconf] Alia Atlas' Block on charter-ietf-netconf-18-10: (with BLOCK) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 12:29:40 -0000 Hi Benoit, All, I think we all agree that any NC/RC extensions, including new and = changed capabilities/RPCs as well as YANG modules describing formal protocol behavior, should be developed in NETCONF WG. Point 6) and 7) in NETCONF charter proposal have been so far discussed = as two different work items done by people with different background. Where point 6 was meant to be only the basic DS support point 7 covers the remaining functionality/capabilities from I2RS pov. e.g. supporting ephemeral DS. The idea was that the authors of point 6) focus only on = basic DS support and Sue Harris shouldn't need to care of that part. This is = the reason why we kept them separate. The question raised is actually whether point 6) can be done in such a generic way (e.g. the generic handling of dynamic datastores) so that it addresses the I2RS requirements on DS handling using NC/RC.=20 I think it is no issue to merge the two charter items which could be = still addressed with two documents. I also agree that any I2RS specific parts like "I2RS datastore semantic, persistence, guidelines, along with the notion of priorities" should be = done in I2RS WG. Concerning the different proposals for the formulation of the charter = item: >>> NEW: Define capabilities for NETCONF and RESTCONF to support the ephemeral-state datastore requirements. >>> NEW Based on the revised datastore concept work in NETMOD, and protocol requirements provided by I2RS, ... I think we should talk on DS handling in general and use the generic = term "dynamic datastore" instead of " ephemeral-state datastore". Also assuming that this functionality will be used by other WGs in the future we shouldn't limit it to and mention I2RS explicitly. Regards, Mehmet > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Tuesday, April 25, 2017 11:47 PM > To: Alia Atlas ; The IESG ; netconf- > chairs@ietf.org; netconf@ietf.org > Subject: Re: [Netconf] Alia Atlas' Block on = charter-ietf-netconf-18-10: (with > BLOCK) >=20 > On 4/25/2017 6:45 PM, Juergen Schoenwaelder wrote: > > On Tue, Apr 25, 2017 at 10:52:02AM +0200, Benoit Claise wrote: > >> Dear all, > >> > >> In order to progress this charter, I would like to clarify one = point > >> with the revised datastore concept authors. See below. > > [...] > > > >> The last question is: what is the right place for this "I2RS > >> datastore semantic, persistence, guidelines, along with the notion = of > priorities" > >> document? > > Here is my take: > > > > a) Once we have NMDA extensions in place, the protocols (NETCONF and > > RESTCONF) should not need any additional protocol work to = support > > I2RS. If the NETCONF WG, for whatever reason, fails to reach = this > > goal, then I think it should be the NETCONF WG's task to fix = this. > > > > b) Once we have NMDA extensions in place, the definition of an I2RS > > datastore with its specific semantics should be done in the I2RS > > working group. None of this should require _changes_ to the NMDA > > enabled NETCONF/RESTCONF protocols or the YANG language. If the > > NETCONF WG and the NETMOD WG, for whatever reason, fails to = reach > > this goal, then I think it should be the NETCONF or NETMOD WG's > > task to fix this. > > > > In other words, my hope is that the NMDA solution provides a = workable > > separation of concerns. > As I understand, you're in favor of removing the item 7 from the = charter. > Thanks J=FCrgen. >=20 > Regards, Benoit > > > > /js > > From nobody Wed Apr 26 13:49:12 2017 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 8311F13144C for ; Wed, 26 Apr 2017 13:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 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 TFN6KLigaIuF for ; Wed, 26 Apr 2017 13:49:09 -0700 (PDT) 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 D7A7A1294EC for ; Wed, 26 Apr 2017 13:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7768; q=dns/txt; s=iport; t=1493239748; x=1494449348; h=from:to:subject:date:message-id:mime-version; bh=Wn+ibUbkF+SZXVZB+vHH82uCd8NjML40Z3nSh1mb69c=; b=aNXb8Jjgb4mQZY9UWiB5hNy8oav9tReseXLvmH1+SET5vRVp8TrejqJu BG4YbJstosKTEQdR9A+qGR1IRgX8Mt/vHpnUhwgbKhElZ/ksi8JRWnWVU buWznqw9uQIwwi/2VC09hAd9zlRccdOPQ++COtZRwijLQ5GgkZdWAAwdU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAAPBwFZ/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYYETjXehfYU3gg8uiiI/GAECAQEBAQEBAWsohUlKFAGBACY?= =?us-ascii?q?BBAEaihMOrVOLJgEBAQEBAQEBAgEBAQEBAQEBGwWGVI88BZ1QAYcYi2qCC49ci?= =?us-ascii?q?HSLMgEfOIEHZRWHMIhdgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208,217";a="418253577" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 20:49:07 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3QKn7Jp013180 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 20:49:07 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 16:49:06 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 16:49:07 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" , "Andy Bierman (andy@yumaworks.com)" , Alexander Clemm , "Tim Jenkins (timjenki)" Thread-Topic: draft-voit-netconf-notification-messages-00 Thread-Index: AdK+zm092Hw1yBzwQsyVPV6ryE0CZg== Date: Wed, 26 Apr 2017 20:49:07 +0000 Message-ID: <26cf356e41884742bd64aca47d42061d@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.229] Content-Type: multipart/alternative; boundary="_000_26cf356e41884742bd64aca47d42061dXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] draft-voit-netconf-notification-messages-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:49:10 -0000 --_000_26cf356e41884742bd64aca47d42061dXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The just posted draft-voit-netconf-notification-messages-00 replaces dra= ft-voit-netmod-yang-notifications2-00 previously posted to NETMOD. This new= draft proposes transport independent headers for event notifications and Y= ANG datastore update records. Also included is the bundling of multiple no= tifications into a transportable unit. - Eric Voit, Andy Bierman, Alexander Clemm, Tim Jenkins --_000_26cf356e41884742bd64aca47d42061dXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The just posted  draft-voit-netconf-= notification-messages-00  replaces  draft-voit-netmo= d-yang-notifications2-00  previously posted to NETMOD.  This new draft proposes transport indep= endent headers for event notifications and YANG datastore update records.&n= bsp; Also included is the bundling of multiple notifications into a transpo= rtable unit.

 

- Eric Voit,  Andy Bierman,  Alexander Cle= mm,  Tim Jenkins

 

--_000_26cf356e41884742bd64aca47d42061dXCHRTP013ciscocom_--