Subject: Opsdir last call review of draft-ietf-netconf-subscribed-notifications-23

From: Carlos Pignataro via Datatracker <[email-masked]>
Date: Fri, 05 Apr 2019 19:57:59 -0700

Reviewer: Carlos Pignataro
Review result: Has Nits

Hi,

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".

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.

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

Thanks,

Carlos Pignataro.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 9 Apr 2019 21:03:24 +0000

Hi Carlos,

Thanks for the review.  Some thoughts in-line...

> From: Carlos Pignataro, April 5, 2019 10:58 PM
> 
> 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
> 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

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.
 
> 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.

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.

> 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

Thanks!
Eric

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 10 Apr 2019 15:11:12 +0000

Hi, Eric,

On Apr 9, 2019, at 5:03 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Thanks for the review.  Some thoughts in-line…

Thanks for the follow-up.

Hi,

Summary: Almost Ready

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.

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.

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 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?)

Thanks,

Carlos.

Thanks!
Eric

Thanks,

Carlos Pignataro.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 11 Apr 2019 20:35:31 +0000

Hi Carlos,

From: Carlos Pignataro, April 10, 2019 11:11 AM

Hi, Eric,

Hi Carlos,

Hi,

Summary: Almost Ready

<eric> Hi Carlos,
Per our call, I refined the section definition to “Implementation and Deployment Considerations”.   I do agree that a number of the elements from RFC-5706 Appendix A are covered elsewhere across specific sections of the document.

<eric> The WG talked about this several times.  (In fact the adopted draft was originally draft-ietf-netconf-rfc5277bis.)    But where we ended up was that we were not ready to assert obsolescence until we had the new <notification> element nailed down.   So progressing the current set of drafts in IESG review gave us a good step in that direction.  And when we have structured this document so that when we do complete draft-ietf-netconf-notification-messages, things should integrate cleanly.  The hard question will be how to handle the meta-references properly.  I believe this is best attempted when an full set of documents which is able to obsolete RFC-5277 is available.

But if it is really a superset, is it obsoleting it?

<eric> The subscription capabilities are a superset.  I.e., the control plane can do everything in RFC-5277.  However the <notification> element work was deferred.

S1.4 further goes:

   Especially when

<eric> For the reasons above, not obsolete.  Perhaps ‘update’ might apply.  But honestly I don’t know the meta-reference convention when two documents (draft-ietf-netconf-subscribed-notifications & draft-ietf-netconf-netconf-event-notifications) improve upon the majority of what is in another document (RFC-5277).  For that reason, doing nothing in meta-referencing until a full functional replacement was available seemed like the best path.

Thanks,
Eric

Thanks,

Carlos.

Thanks!
Eric

Thanks,

Carlos Pignataro.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 12 Apr 2019 15:01:53 +0000

Hi, Eric,

Thanks for the quick response, and for considering these comments!

A top-post response to acknowledge that your approach on both issues below seems great to me. Thank you!

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Apr 11, 2019, at 4:35 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Hi, Eric,

Hi Carlos,

Hi,

Summary: Almost Ready

<eric> Hi Carlos,

S1.4 further goes:

   Especially when

Thanks,
Eric

Thanks,

Carlos.

Thanks!
Eric

Thanks,

Carlos Pignataro.