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

[Warren Kumari <[e-mail]>]

[ - some lists ]

Thank you Carlos for the OpsDir review, and to the authors for addressing
the comments - I think that this has noticeably improved the document.

W

On Fri, Apr 12, 2019 at 11:02 AM Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> 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]
>
> *“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]> 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]> 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.
>
>
>
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf