MIME-Version: 1.0
References: 
 <176114237340.1133.4616423096347649354@dt-datatracker-675c8fd764-bsflw>
 <ZR1P278MB117066EF7A0C1FE1223CD43B89ADA@ZR1P278MB1170.CHEP278.PROD.OUTLOOK.COM>
In-Reply-To: 
 <ZR1P278MB117066EF7A0C1FE1223CD43B89ADA@ZR1P278MB1170.CHEP278.PROD.OUTLOOK.COM>
From: Per Andersson <per.ietf@ionio.se>
Date: Wed, 14 Jan 2026 17:36:53 +0100
Message-ID: 
 <CACvbXWEi53+b_PwaqcAJG8k8yDO4AO94m-eOLwwBcSECgtswow@mail.gmail.com>
To: Thomas.Graf@swisscom.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: PKYR6CHTRULVYGVPS5KIK6ROTPPDI2AD
CC: ops-dir@ietf.org, draft-ietf-netconf-notif-envelope.all@ietf.org,
 netconf@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BOPS-DIR=5DRe=3A_draft-ietf-netconf-notif-envelope-03_early_Opsd?=
	=?utf-8?q?ir_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ops-dir/LwH9tJkXlgpG0S2g2Rk00xdGkPc>

Hi Joe,

Does the updates address the comments you raised
in your opsdir review?


--
Per, as chair

On Mon, Dec 15, 2025 at 6:37=E2=80=AFAM <Thomas.Graf@swisscom.com> wrote:
>
> Dear Joe,
>
> On behalf of the authors. Apologies for late reply. Thanks a lot for the =
review and feedback.
>
> We have merged your input as following: https://author-tools.ietf.org/dif=
f?doc_1=3Ddraft-ietf-netconf-notif-envelope-03&url_2=3Dhttps://raw.githubus=
ercontent.com/network-analytics/draft-ahuang-netconf-notif-yang/refs/heads/=
master/draft-ietf-netconf-notif-envelope-04.txt
>
> See inline below some comments.
>
> Please let us know wherever we addressed your comments.
>
> Best wishes
> Thomas
>
> -----Original Message-----
> From: Joe Clarke via Datatracker <noreply@ietf.org>
> Sent: Wednesday, October 22, 2025 4:13 PM
> To: ops-dir@ietf.org
> Cc: draft-ietf-netconf-notif-envelope.all@ietf.org; netconf@ietf.org
> Subject: draft-ietf-netconf-notif-envelope-03 early Opsdir review
>
>
> Be aware: This is an external email.
>
>
>
> Document: draft-ietf-netconf-notif-envelope
> Title: Extensible YANG Model for YANG-Push Notifications
> Reviewer: Joe Clarke
> Review result: Has Issues
>
> I have been asked to review this document on behalf of the OPS directorat=
e.
> This document specifies a new envelope header for YANG notifications that=
 can be extended with richer metadata beyond eventTime and used in other en=
codings.
> The document is well-written and easy to follow.  As such, I found it eas=
y to spot what I feel are two points to discuss.  I hesitated to mark this =
"has issues".  I really wanted a DISCUSS-like option just so I could get so=
me authors' and WG members thoughts.
>
> 1. I appreciate your Operational Considerations concerning a mix of "new"=
 and "old" collectors.  However, since the knob to control this new envelop=
e is network element-wide, I feel something should be said in this section =
that separating collectors MUST be done at a network element level.  But th=
at begs the question, why?  Why can't this be controlled at a subscription =
level?  I'm sure it was considered, but I don't recall seeing text that exp=
lained why this was a sub-optimal choice.
>
> TG> Thats a long story which goes back to the origin of RFC 8639, backwar=
d compatibility to RFC 5277 (https://datatracker.ietf.org/doc/html/rfc8639#=
section-1.4) in terms of xml header, the motivation of this document and su=
bsequently many discussions on that subject in the working group on how to =
enable and disable. We added some editorial comment to reflect that discuss=
ion. Speaking as a YANG-Push implementor, having one schema language descri=
bing the notification header AND the subscribed content is simpler than hav=
ing two schemas, XST for the header and YANG for the subscribed content.
>
> 2. MINOR: As it stands, it makes sense that all subscriptions would be te=
rminated when toggling `enable-notification-envelope`, but would it possibl=
y less astonishing to operators that toggle this if implementors force all =
subscriptions to already be terminated for the config to be accepted?  Bari=
ng that, I would strongly recommend you add the text about subscriptions be=
ing terminated to the description of this boolean in the YANG module.  And =
also, see #1 as to why this can't be done more gracefully at a per-subscrip=
tion or per client level.
>
> Finally, one nit:
>
> Section 1.1: s/messsage/message/
>
>