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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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, [e-mail]<mailto:[e-mail]>

“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) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Carlos,

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


Hi, Eric,

On Apr 9, 2019, at 5:03 PM, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> 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

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

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.

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


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?

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

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?


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

<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


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

Thanks,

Carlos.



Thanks!
Eric


Thanks,

Carlos Pignataro.