Re: [netconf] Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23

"Carlos Pignataro (cpignata)" <> Wed, 10 April 2019 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B00161203C4; Wed, 10 Apr 2019 08:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yJwmtkikcoX6; Wed, 10 Apr 2019 08:11:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 457311203BD; Wed, 10 Apr 2019 08:11:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=29408; q=dns/txt; s=iport; t=1554909090; x=1556118690; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D93N1h51gmURt9MoFHVTc8Sz52hZeGMxJW3ejVszI7Y=; b=ljnEAdEDmGsJ02q1L1ul1QfrtWgI4Bij3bf5tSllz1d1x/mO+3Li3KXZ XqhbW5JRHrSjiINQuk9d5NdE9hLWvLNRczfrprg/oXTSkSzC3Ed1Zi0Y4 Qn72bDKaW5smSQTDyGSvoV0K0tPIYb756mh8twGNyLz81CMeRxgPmt9PC w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAABbB65c/4ENJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYEPWCqBaxQTCoQElRolmkEOAQGEbAIXhVQiOBIBAQMBAQk?= =?us-ascii?q?BAgECbSiFSwMDI08FAhACAQgVEBMHAwICAjAUEQIEDgUagj1LgRJkrHOBL4o?= =?us-ascii?q?rgTCLRxeBQD+BEScME4JMPoRDgwsxgiYDjRWEL4dfjAViCQKLYkGHYhqCBpJ?= =?us-ascii?q?ejHCPcYJzAhEVgTA2ISiBLnAVZQGCQT6QDkExj02BIAEB?=
X-IronPort-AV: E=Sophos;i="5.60,332,1549929600"; d="scan'208,217";a="260709870"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Apr 2019 15:11:13 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x3AFBDiQ006893 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Apr 2019 15:11:13 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Apr 2019 11:11:12 -0400
Received: from ([]) by ([]) with mapi id 15.00.1473.003; Wed, 10 Apr 2019 11:11:12 -0400
From: "Carlos Pignataro (cpignata)" <>
To: "Eric Voit (evoit)" <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23
Thread-Index: AQHU7xeskVwDPMWz+0mc9NXGW1eimKY1xCMA
Date: Wed, 10 Apr 2019 15:11:12 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.104.8)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C156DC6548644D1FB5EAEE574A35EA2Fciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2019 15:11:33 -0000

Hi, Eric,

On Apr 9, 2019, at 5:03 PM, Eric Voit (evoit) <<>> wrote:

Hi Carlos,

Thanks for the review.  Some thoughts in-line…

Thanks for the follow-up.

From: Carlos Pignataro, April 5, 2019 10:58 PM

Reviewer: Carlos Pignataro
Review result: Has Nits


I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included in
AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Summary: Almost Ready

This is a comprehensive very well written document.

From an operational point of view, as per the ops-dir review, I have no
concerns or comments. Might be nice to collect some of the operational points
in an Operations Consideration section, particularly given the document
structure of Section 5.x, "ZZZ Considerations".

In "implementation considerations" there are a couple which are really operational considerations.  For example the first and third bullets might qualify as operational.  The hard part is that the operational considerations to expose will vary by the subset of feature which are selected.  So I can imagine that much text could be written on best operational practices.  I am hoping that such documents could follow this one based on specific deployment contexts.

Sorry I was not explicit. While many of these considerations have operational implications, I meant things like Appendix A of RFC 5706, more deployment than implementation.

I do have one important question for consideration, which is: what is *really*
the relationship of this (+ draft-ietf-netconf-netconf-event-notifications
potentially) with RFC 5277? A Normative reference, this doc has no metadata
regarding Updating, Obsoleting, etc. Yet lots of it is indeed a superset of it.

We went around and around in the WG on this for a bit.  The initial decision was that we were going to obsolete RFC-5277. However the problem was that RFC-5277 Section 4 has a <notification> element defined which we are not replacing yet. This <notification> is used in several important places.  Examples include RFC-8040 section 6.4 and RFC-7950 Section 7.16.2.

Does this describe an Update of specific sections then? Or would want to bring in the notification and do a full bis?

At this point, my comment is that the relationship is not explicit.

So we didn't want to recommend an obsolete without a replacement of that <notification>.  The good news is that we are working on a replacement for this notification.  See: draft-ietf-netconf-notification-messages     But this still has a while to go before it is ready.  As a result we are left with Section 1.4 of draft-ietf-netconf-subscribed-notifications which describes the relationship with RFC-5277.

This is still somewhat confusing. Section 1.4 says:

   This document is intended to provide a superset of the subscription
   capabilities initially defined within [RFC5277].

But if it is really a superset, is it obsoleting it? S1.4 further goes:

   Especially when
   extending an existing [RFC5277] implementation, it is important to
   understand what has been reused and what has been replaced.

Similarly, reuse+replace means obsolete? Or update? :-)

I recommend the authors+ADs consider whether there is any more formal
relationship with RFC 5277 that would require meta-tagging the RFC.

I think that this is fully appropriate as we finish draft-ietf-netconf-notification-messages

I do not think you need to wait for draft-ietf-netconf-notification-messages (and delay draft-ietf-netconf-subscribed-notifications) in order to have an appropriate meta-reference. Perhaps draft-ietf-netconf-notification-messages will update something (draft-ietf-netconf-subscribed-notifications?)





Carlos Pignataro.