Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

"Joe Clarke (jclarke)" <jclarke@cisco.com> Wed, 02 October 2019 16:53 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4851202DD for <netconf@ietfa.amsl.com>; Wed, 2 Oct 2019 09:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=epjC+FQL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YB6VY9Y2
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 S56GcfpSHMFM for <netconf@ietfa.amsl.com>; Wed, 2 Oct 2019 09:53:00 -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 E371A12016E for <netconf@ietf.org>; Wed, 2 Oct 2019 09:52:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55889; q=dns/txt; s=iport; t=1570035179; x=1571244779; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=v7gp487f08xRKGHSl1GwEsIkhHjPLNYe1wdTFa5WIQY=; b=epjC+FQL0mf9AnLqZuvY0k3SXaXbrT9PyIKoeHyW6xenBs1UQHTbRr6M li0L2VkN/55Y4Vfp3zvFJ7jMUsExUGaDLdcqZEw/f1WP2qfNn7vqRnnCP 8LBzLzGmXRGFhwI/hLIp//1GYpbTKVhH0nqp/l4idzuJRsl8rlnH+A1Ot s=;
IronPort-PHdr: =?us-ascii?q?9a23=3ATcM/KRXxFaVMstRmZL1Bx0HqpvzV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank4F8BLTlxo13q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAAA21ZRd/49dJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBUwQBAQEBAQsBgRsvUANtViAECyoKhBiDRwOEVIVqgly?= =?us-ascii?q?JZ44QgS6BJANQBAkBAQEMAQEYAQwIAgEBg3tFAheCJiM0CQ4CAwkBAQQBAQE?= =?us-ascii?q?CAQUEbYUtDIVLAQEBBAEBEBEdAQEsBAUCAQ8CAQgRBAEBDhMBBgMCAgIfBgs?= =?us-ascii?q?UCQgCBA4FIoMAAYEdTQMdAQIMpVMCgTiIYXWBMoJ9AQEFgTgCg00NC4IXAwa?= =?us-ascii?q?BNAGFFYQvgkkYgUA/gREnH4JMPoIaRwEBAgGBSEMJAoJVMoImjQwmgX83hTC?= =?us-ascii?q?JK44rQQqCIoYkZIoIhAYbgjiHToQqiSqBX49jhmGCDIsog1oCBAIEBQIOAQE?= =?us-ascii?q?FgVI5gVhwFTsqAYJBUBAUgU8MF4NQhRSFP3QBAYEnjngBgSIBAQ?=
X-IronPort-AV: E=Sophos;i="5.67,249,1566864000"; d="scan'208,217";a="419935008"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Oct 2019 16:52:57 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x92Gqu33002619 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Oct 2019 16:52:57 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 2 Oct 2019 11:52:56 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 2 Oct 2019 11:52:55 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 2 Oct 2019 11:52:55 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gtxxxokuphvSL+J/hT8gGSWJ+yoWtIsLhRLfdM6MoEyXU1KwGaYioqc5aImzyVJGP8UDNFnXky+lDriyrcTHLIV8pShmgrXQlByUAVsrmHFJemwYn9pz5OGJql0FCM0uXsEL5N4EHhxnd12+0qtsqr8z0EAF+scYxV2JTy/e1hz9TKq37t0JXJq4OD5OHHIJsqDrqrTezO1GIDW5ZYOMcqX9MSRUOKUHaYxmmeYdyqURxgQd9C6L+17ED1GFqhlHiCGl3AmvUobUD3RXUeoSZib/pktZSiAkH/Fi4mbxNyZ3jjH4Xc5QB4WEZHjI+3JRFXAbo5xQw6Sir80oHSjL0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v7gp487f08xRKGHSl1GwEsIkhHjPLNYe1wdTFa5WIQY=; b=BGqY7J0Hn4U7XEwYU7/8wU0UlMff178zV+9STSccLQsJ+P/nY0LCYlIamrcTKA/WEyGq2Cup6S3OnVfQ/ypFrF87HnehfWhx0dQK3mVlVa8RSnAPLtVcmkfbU+IU0JGsUL7a4LRE/EdlADWV6GSlAbh6f0VzhgzY5atGBPHK6AwQ6SBhlJZVv6WW2SDXFTFiPFVxM874E7evNuufwomydWdMDVQYgIybu27hdxms0x0sCyxVJgEtMAhySHeOuBtKuLaYucDo8nmH/0+j/tmrHeRtkcEuGnkMq4COFnXG2topMF1FBaZaRIebFMDWeYyfi/Csxb6O1k5TrrObJ05/3Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v7gp487f08xRKGHSl1GwEsIkhHjPLNYe1wdTFa5WIQY=; b=YB6VY9Y2pH+/quGZiOgEhU9PmPwEuQl8V/zOBYXvO1FtiBu9DWKdAJSZwfo+v0WPxYtybS615yYDllfD4xxIySpy8ZMMYAhobw9iw4Si4vDW6wWrakuo0Lh2c6Q+6/yZSDXheKNUvkhJu+8/SZEwpwHqQMJbnVk21xlmA6nW1GE=
Received: from DM6PR11MB3418.namprd11.prod.outlook.com (20.177.219.223) by DM6PR11MB3337.namprd11.prod.outlook.com (20.176.122.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Wed, 2 Oct 2019 16:52:54 +0000
Received: from DM6PR11MB3418.namprd11.prod.outlook.com ([fe80::3848:4383:2407:7fdf]) by DM6PR11MB3418.namprd11.prod.outlook.com ([fe80::3848:4383:2407:7fdf%5]) with mapi id 15.20.2305.022; Wed, 2 Oct 2019 16:52:54 +0000
From: "Joe Clarke (jclarke)" <jclarke@cisco.com>
To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel=40ericsson.com@dmarc.ietf.org>
CC: "Eric Voit (evoit)" <evoit@cisco.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Alexander Clemm <ludwig@clemm.org>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities
Thread-Index: AQHVaCiuj3L8+VDGQ0WrhdW5flWlRKc7MLcAgAA5KYCABClNAIAAc7oAgAQJhYCAA6LrAA==
Date: Wed, 2 Oct 2019 16:52:54 +0000
Message-ID: <B7C05E21-3B4B-481D-949F-45FD6B2D1103@cisco.com>
References: <D3B39347-DFB7-4BEE-8B22-0EE07AEB1F5A@gmail.com> <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> <BN7PR11MB262749DCC86F32F725D1C67AA1840@BN7PR11MB2627.namprd11.prod.outlook.com> <VI1PR0701MB22864F116F517E960EC32A0AF0810@VI1PR0701MB2286.eurprd07.prod.outlook.com> <BN7PR11MB262715BE5A88B587E409D3CFA1810@BN7PR11MB2627.namprd11.prod.outlook.com> <VI1PR0701MB228602575125FC02EF920CDFF0820@VI1PR0701MB2286.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR0701MB228602575125FC02EF920CDFF0820@VI1PR0701MB2286.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jclarke@cisco.com;
x-originating-ip: [173.38.117.78]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a08ce805-a0e3-490d-5b6f-08d74758f85d
x-ms-traffictypediagnostic: DM6PR11MB3337:
x-ms-exchange-purlcount: 2
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR11MB333786E76343D200ACDD379AB89C0@DM6PR11MB3337.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0178184651
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(396003)(39860400002)(366004)(199004)(189003)(51914003)(11346002)(6306002)(186003)(6512007)(316002)(66066001)(486006)(26005)(54896002)(15650500001)(6246003)(6436002)(66574012)(229853002)(2906002)(6486002)(25786009)(236005)(446003)(53546011)(966005)(478600001)(76176011)(2616005)(102836004)(6506007)(476003)(5660300002)(66446008)(76116006)(14444005)(36756003)(7736002)(91956017)(14454004)(99286004)(64756008)(66556008)(71190400001)(66476007)(66946007)(71200400001)(606006)(3846002)(6116002)(4326008)(81156014)(8676002)(33656002)(81166006)(86362001)(54906003)(8936002)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3337; H:DM6PR11MB3418.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OyFnGh6JqrrG5JrWt11vfoageppymh18lq+52V0lnXSZMTG1OI9zKxmUgavL/nysIoP6029bnl5AayFoCqg15h25D0/RrL1iNqLHtsqUbMKNinNEg+2WRM4HUWFVTCvj7a+9nnVWnNH/SmEUrbAWyR98VIUfajHVLbVrfar8lvKr8WxTnRYLgmhbyWx1Lvt4/1lubrA5qobJqHpQVcphTRquJyMJ51WieLl4my3EPH8Xj7+xBKdVjOujk5z1CqAbtpJR6R5QMBbJib7N+18eR1wZwbEQFqcpTEXStq9bEC1cU3Ijo1dMKjbphjGJCH2pnuVssGsBYCFJ1nlYd2whB9Klo6MJSFk50H9LRtVtrcSjo6PWJQXB8Emsy6pVCoKphGhczDw+4Nm3m6q6ZdQpKpNMlhjtv3Y+x+QfohS1SVT43O74r4dfpzStfxbrGSFHJ6IRuhbozJTG6vF82vSI/A==
Content-Type: multipart/alternative; boundary="_000_B7C05E213B4B481D949F45FD6B2D1103ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a08ce805-a0e3-490d-5b6f-08d74758f85d
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2019 16:52:54.4287 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DSCQX4XswccIXuH5ZANegJQrziy7TtzCEALlAY5C8U9ODOmgW266/hwSr3kxNgmzI7/nqFjhneJDggfz5WugEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3337
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/43oKmG5IeG4Gsi-ejGVWJlO_GnM>
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Oct 2019 16:53:05 -0000


On Sep 30, 2019, at 05:20, Balázs Lengyel <balazs.lengyel=40ericsson.com@dmarc.ietf.org<mailto:balazs.lengyel=40ericsson.com@dmarc.ietf.org>> wrote:

Hello,
Here is a preliminary next version (not submitted yet). See also below.

I have reviewed this version and looked at others’ comments.  I think this document is ready (based on the addressing of others’ comments), and I support its goals.  This will make the consumption of telemetry much easier for operators.

Joe

Regards Balazs

From: Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>>
Sent: 2019. szeptember 27., péntek 21:42
To: Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>>; Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>; Alexander Clemm <ludwig@clemm.org<mailto:ludwig@clemm.org>>; Benoit Claise (bclaise) <bclaise@cisco.com<mailto:bclaise@cisco.com>>
Cc: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Hi Balazs,

Some more thoughts in-line.   I cut out those I think closed.

From: Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>>
Sent: Friday, September 27, 2019 8:48 AM
To: Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>>; Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>; Alexander Clemm <ludwig@clemm.org<mailto:ludwig@clemm.org>>; Benoit Claise (bclaise) <bclaise@cisco.com<mailto:bclaise@cisco.com>>
Cc: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Thanks for the comments. See answers below.
I hope the group will be ok with using the term publisher instead of server. IMHO it is clearer as the client server relationship can be reversed e.g. for https notification transport.
Balazs

From: Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>>
Sent: 2019. szeptember 24., kedd 23:15
To: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>; Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>>; Alexander Clemm <ludwig@clemm.org<mailto:ludwig@clemm.org>>; Benoit Claise (bclaise) <bclaise@cisco.com<mailto:bclaise@cisco.com>>
Cc: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: RE: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

Here are some comments...

On-change Notification Capability: Is this different from support for RFC-8641 feature "on-change"?  If they are the same, it might be possible to remove the term.  Especially as this term is used inconsistently.
BALAZS: In RFC 8641 on-change is not defined as a capability. It is used for many more things (e.g. On-change subscription,  trigger condition, type of push updates, a feature.) In this draft the on change capability is just the servers capability to send on-change notification globally, for a specific datastore or a specific data node. Description will be reworded.
<Eric> It will be good to see the reword.   I still am not clear how this different from the RFC-8641 feature "on-change", along with this feature being associated with specific nodes.
BALAZS2:
On-change Notification Capability: The capability of the server to
   send on-change notifications for a specific datastore or a specific
   data node.


Section 3

Paragraph 2, bullet 2: Instead of  "amount of notifications the server can send out", do you mean "the minimum periodicity of updates which a server can send out for an object"
BALAZS: That too, but also the max-objects-per-update. I was told not to repeat information in the main text and in the YANG module, so I tried to find a wording that covers both. Also  its not always the minimum times. Some servers support  a specific set of times, not a anything over a minimum.
<Eric> Ok, so this bullet is a bucket of various types of information.  Which is fine with me.


Paragraph 2, bullets 3 & 4: I don't think these should be indented as bullets are they are more about proper behavior of a correctly populated model.
BALAZS: I don’t really understand this comment.  Please explain.
<Eric> Looking at the text, bullets 3 is written to say how capabilities value can be set (i.e., how) rather than that they can be set for different levels (i.e., what).  Getting consistency so that the bullets are all 'how' or all 'what' items would help readability.
BALAZS2: OK, I get it. You are right, to be corrected.


Paragraph 3, bullets 2: why isn't SHALL instead MUST?   Also, shouldn't this point out that both NETCONF and RESTCONF MUST be supported if on-change is advertised, and this draft is supported?
BALAZS: As I understand RFC 2119 MUST and SHALL both mean the same, but I will change to MUST. No I do not want to mandate implementing both Netconf AND Restconf. IMO a server with just Netconf would work just fine; or maybe I misunderstand your comment?
<Eric> The second part of my comment was about ensuring that IF this model was available, and the publisher supports both RFC-8640 & draft-ietf-netconf-restconf-notif, then this specification MUST be able to push changes over both NETCONF and RESTCONF.    Thinking more, this is actually a generic question which is likely already answered: how do you know which models are supported for which transports.   As advertisement is by transport, I withdraw this question.
BALAZS2: Some implementations have a yang extension statement to specify whether  a model is visible on specific interfaces

Section 4

I suspect that you will need to do a security analysis per YANG object.   This has been done the other YANG push family.
BALAZS: The full module is readOnly and not sensitive or private in any manner.  The security text for the readOnly parts of YangPush is the exact same text: not very informative, but gives you the illusion of security awareness.
<Eric> You can ignore my comment.  In doing RFC-8639, I needed to put in read/write analysis for each object.  And this did sometime include the risks of internally setting values which were read-only from the model.  Perhaps this will not be required during later draft reviews in the publication process.

I suspect that manipulating the reporting intervals could have some security implications.   E.g., a hacker could push up the damping period or periodic interval to a level where the information they are changing then becomes invisible to a monitoring system.
BALAZS: The full YAM is read-only so manipulating the data is not a concern.
<Eric> Per my previous point, if the IETF process says you don't need to highlight such possibilities, then I am good.
BALAZS2:
In rfc8639 the text says for readOnly data nodes something like:
If access control is not properly configured, can expose
      system internals to those who should not have access to this
      information.
That is true for any bit of data, so I do not understand what information does it add. It does not hurt, so I will add the same sentence to my draft.

If you have something else in mind please describe the attack method that I should mention.
</Eric>

Thanks,
Eric


From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> On Behalf Of Mahesh Jethanandani
Sent: Tuesday, September 24, 2019 1:50 PM
To: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

We were supposed to have closed on the WGLC today. However, between the document becoming a WG item and it going into LC, we have not received too many comments on the draft. As such, we are extending the LC by another week. Please review the draft and provide any comments you might have.

Mahesh & Kent (as co-chairs)


On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:

Authors have published -04<https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04> version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC.

This therefore starts a two week LC, ending on September 24th. Please provide any technical comments you might have on the document. If you believe the document is not ready for LC, please state your reasons.

We will issue a IPR poll separately.

Mahesh & Kent (as co-chairs)




<draft-ietf-netconf-notification-capabilities-05b.txt>_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf