Re: [Netconf] two-week review of drafts related to notifications and subscriptions

["Eric Voit (evoit)" <[e-mail]>]

Sounds good then.   I will split the tree into the sections per below in the next release in the coming in a week or two.  It is a straightforward change.

With luck we will be able to also have a cut at the NMDA model too, but I don't want to splice that model into the mainline text until we get agreement that there is functional equivalence between the NMDA and non-NMDA versions.

Eric

> From: Mahesh Jethanandani, November 16, 2017 12:01 AM
> 
> Eric,
> 
> I would agree with Martin. I find the tree a useful way to understand the
> model, but not when it is multiple pages long. The idea of breaking it up
> into smaller parts of the tree, and those individual parts explained, is
> helpful. If someone wants to do the comparison, they can generate the
> complete tree themselves.
> 
> Cheers.
>  
> > On Nov 16, 2017, at 5:53 AM, Eric Voit (evoit) <[e-mail]> wrote:
> >
> > Kent,
> > Mahesh,
> >
> > You also thought it might be good to partition the trees.   Are you also ok
> with the proposal below, and the identified downsides of such a
> partitioning of the tree within subscribed-notifications?    Specifically the
> implications of making it harder to find and compare augmentation points
> from yang-push?
> >
> > Eric
> >
> >> -----Original Message-----
> >> From: Martin Bjorklund [mailto:[e-mail]]
> >> Sent: Wednesday, November 15, 2017 2:39 PM
> >> To: Eric Voit (evoit) <[e-mail]>
> >> Cc: [e-mail]; [e-mail];
> [e-mail]
> >> Subject: Re: [Netconf] two-week review of drafts related to
> >> notifications and subscriptions
> >>
> >> "Eric Voit (evoit)" <[e-mail]> wrote:
> >>> Hi Martin,
> >>> Hi Kent,
> >>>
> >>> Ensuring comments are covered.  I do ask a question on potential
> >>> model partitioning across the document in the first set of
> >>> comments..,
> >>>
> >>>> From: Martin Bjorklund, October 23, 2017 8:41 AM
> >>>>
> >>>> Hi,
> >>>>
> >>>> Some comments inline.
> >>>>
> >>>> "Eric Voit (evoit)" <[e-mail]> wrote:
> >>>>> Hi Kent,
> >>>>>
> >>>>>> From: Kent Watsen, October 19, 2017 9:51 PM
> >>>>>>
> >>>>>>>> draft-ietf-netconf-subscribed-notifications-05
> >>>>>>>> ------------------------------------------------------
> >>>>>>
> >>>>>>>> very complicated (many details).
> >>>>>>>
> >>>>>>> If there anything you see as unnecessary, or perhaps should be
> >>>>>>> optional?
> >>>>>>
> >>>>>> The tree diagram is huge.  I understand that much of it is from
> >>>>>> grouping expansion, but still, there is a lot to consider (many
> >>>>>> details).  I'm just thinking that this is going to take time for
> >>>>>> folks to digest fully.
> >>>>>
> >>>>> We really made an attempt to simplify the tree by using a
> >>>>> filter-type object instead of the explicit subtyping.  But
> >>>>> experienced and capable reviewers argued that explicit subtyping
> >>>>> was better.  The result is that we returned to the larger
> >>>>> explicitly subtyping a couple weeks ago.  Overall, this added 25%
> >>>>> to the tree diagram size :-(.
> >>>>
> >>>> I don't think a big tree in itself necessarily means that the data
> >>>> model is bad.
> >>>> However, for readability purposes, you may want to split the big
> >>>> tree into smaller pieces.  See for example RFC 7404.
> >>>
> >>> I think you mean RFC 7407?
> >>
> >> Yes.
> >>
> >>> We can do this.  Before I make the change, I want to confirm that it
> >>> should be only done for individual RPCs and Notifications, and top
> >>> level containers in the data trees (e.g. streams and filters top
> >>> level container).
> >>
> >> I think that would be sufficient.
> >>
> >>> I would also like to confirm that you are ok with all the downsides
> >>> (1)-(4) listed below.
> >>>
> >>> (1) To what section of subscribed-notifications do you look to when
> >>> you are doing an augmentation in yang-push?  Having one tree to go
> >>> to in one full tree is easier than finding info across split trees.
> >>> I.e., a single tree is pretty useful for outside referencing on
> >>> augmentations.
> >>
> >> The purpose of the tree is to get an overview of the basic structure
> >> of the model.  It is not the normative reference that you need to
> >> fully understand everything - that would be the module itself.
> >>
> >>> (2) YANG Push does not have section partitions for existing
> >>> subscribed-notification RPCs and Notifications.  Therefore we
> >>> couldn't do the exact same segmentation of the tree structures
> >>> across the two documents.  (I.e. it won't be a 1:1 comparison when
> >>> looking between the drafts.)
> >>
> >> I haven't yet reviewed YANG Push, but I don't think this will be an issue.
> >>
> >>> (3) Segmentation lower that any top level container is not
> >>> recommended.
> >>
> >> By whom?
> >>
> >>> This is because augmentations occur at different levels of the tree.
> >>> Any other approach would mean tree information replicated in
> >>> different tree diagrams.
> >>
> >> I don't think that's a problem.
> >>
> >>> (4)  It will increase the size of an already big document.
> >>
> >> Probably not by much, and if it helps people to better understand
> >> this model, I think it is worth it.
> >>
> >>
> >> /martin
> >>
> >>
> >>> Based on this, I still think a single model is better.  But I am
> >>> happy to make the change if consensus is otherwise.
> >>>
> >>>>>>>>        flow difficult to read.
> >>>>>>>
> >>>>>>> Anything specific?  I am happy to re-order as suggested.
> >>>>>>
> >>>>>> Also, I'm suspecting that the update from Martin's comments will
> >>>>>> get much of this.  It just seemed that every time tried to chase
> >>>>>> some bit of information down, it wasn't stated quite right (e.g.,
> >>>>>> terminology, phasing, open-endedness, etc.).  All this got in the
> >>>>>> way of the readability.
> >>>>>
> >>>>> Hopefully I got the ones which don't resonate.  My natural
> >>>>> ecosystem is deeper in the router, and YANG means I need to use
> >> different terms.
> >>>>>
> >>>>>>>> * what is "promise theory based interaction model"?
> >>>>>>>> (reference?)
> >>>>>>> Yes, I will add the reference.  The best on-line one I know is:
> >>>>>>>
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-
> >> 3A__markburgess.
> >>>>>>> or
> >>>>>>> g_Pr
> >>>>>>>
> >> omiseMethod.pdf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >>>>>> ndb3voDTXcWzoCI
> >>>>>>>
> >>>>>>
> >>>>
> >>
> &r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=zDualRWvSwyZj
> >> 8MF
> >>>>>> PL_Xo
> >>>>>>>
> >>>>>>
> >>>>
> >>
> pkywEp9xEJgZXjyhdIBPog&s=Dcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2
> >> xpE
> >>>>>> Oc0o&e
> >>>>>>> =
> >>>>>>
> >>>>>> Oh my, that document is 38 pages, I was hoping for simple
> >>>>>> statement (e.g., the system takes defensive measures in order to
> >>>>>> ensure resources are available).  I think you have something like
> >>>>>> this in the yang-push draft.
> >>>>>
> >>>>> I can add a simple statement.  Something like "voluntary
> >>>>> cooperation between individual, autonomous agents who
> >> continuously
> >>>>> refine their changing intentions to one another in the form of
> >> promises".
> >>>>
> >>>> Does this really help people to understand this document?
> >>>
> >>> I didn't such a statement helped either, so all references in
> >>> subscribed-notifications have been removed.  As this is important in
> >>> yang-push, I tweaked the reference section 3.4 with the kind of info
> >>> I think Kent wanted in his simple statement.
> >>>
> >>>>>>>> * what is the relationship between streams here and in 5277?
> >>>>>>>
> >>>>>>> This document doesn't discuss the details of how streams are
> >>>>>>> generated within the publisher like 5277 does.  This detail is
> >>>>>>> not necessary for the external interface definition.
> >>>>>>>
> >>>>>>> That said, how to handle/encode names of the streams, the
> >>>>>>> managed objects, the ability to filter, etc. are identical.
> >>>>>>
> >>>>>> This document should explain the relationship though, right?
> >>>>>> (see
> >>>>>> above)
> >>>>>
> >>>>> Is this necessary in the normative part of the document?  When the
> >>>>> notification-messages draft is complete, it will be possible to
> >>>>> obsolete RFC-5277 at some later date.  How many linkages are
> >>>>> appropriate?
> >>>>>
> >>>>> What I did do in the new version (per Martin's request) is to
> >>>>> place in Appendix A: Relationship to RFC-5277.  What I believe we
> >>>>> should do is place statements identifying the re-used stream
> >> constructs.
> >>>>> Would that work?
> >>>>
> >>>> I think such a section is needed, and I think it shouldn't be an
> >>>> Appendix, but rather one of the first sections.  This is quite
> >>>> common in RFCs that updates/obsoletes older RFCs.
> >>>
> >>> Done.  See Section 1.4.  Relationship to RFC-5277
> >>>
> >>>>>>>> * streams here are identities, unlike "streamNameType"
> >>>>>>>> (aka xs:string) in 5077.  Is this an issue?
> >>>>>>>
> >>>>>>> Based on Martin's comments that he desires to retain the ability
> >>>>>>> for streams to be spun up possibly during run-time, we have
> >>>>>>> returned to using string for streams (as we did in earlier
> >>>>>>> versions of the draft).   Our switch to identities several
> >>>>>>> months ago was one attempt we made to simplify things, but
> >>>>>>> it didn't work out.    This is an issue and a resolution we
> >>>>>>> have long been anticipating.
> >>>>>>
> >>>>>> okay
> >>>>>>
> >>>>>>
> >>>>>>>> * use of "<edit-config> operations" for configured
> >>>>>>>> subscriptions is confusing.
> >>>>>>>
> >>>>>>> It is just a normal configuration.  I will happily delete the
> >>>>>>> example if you think it unnecessary or redundant.
> >>>>>>
> >>>>>> No, the examples are good.  It's literally the words
> >>>>>> "<edit-config> operations"
> >>>>>> are problematic.  Use some other phrasing that is not
> >>>>>> NETCONF-specific.
> >>>>>
> >>>>> I will just use 'configuration operations'
> >>>>>
> >>>>>>>> * the example in s5.1 seems to be more about how to create a
> >>>>>>>> configured subscription than establishing a subscription
> >>>>>>>> connection
> >>>>>>>
> >>>>>>> Exactly.  How to establish the subscription connection is
> >>>>>>> transport specific, and therefore in the netconf-notif draft.
> >>>>>>> Specifically in Section 3.4.3
> >>>>>>
> >>>>>> But the section is called "Establishing a Configured Subscription".
> >>>>>> I think this actually goes to your use of the word "establish",
> >>>>>> perhaps "create" is a better word - "Creating a Configured
> >>>>>> Subscription" ?
> >>>>>
> >>>>> Will do.  No reason to reuse the establish if it confuses people.
> >>>>>
> >>>>>>>> * Section 7 says "This notification message MAY be encoded as
> >>>>>>>> one-way notification element of [RFC5277], Section 4."  If this
> >>>>>>>> is a MAY, how does the client know what it received?
> >>>>>>>> And how does the publisher know what format to send?
> >>>>>>>
> >>>>>>> I was trying to lay the groundwork for a future support of
> >>>>>>> notification-messages in a way that this document wouldn't have
> >>>>>>> to be updated.  I have given up on that.  Support is now a
> >> MUST.
> >>>>>>> And this will need to be revised in the future when we get
> >>>>>>> notification-messages to an RFC state.
> >>>>>>
> >>>>>> okay
> >>>>>>
> >>>>>>
> >>>>>>>> * xpath-filter is not a feature-based option?
> >>>>>>>
> >>>>>>> Not feature based.  Of course if the syntax is not supported on
> >>>>>>> a filter, the subscription will be rejected with the error
> >>>>>>> "filter-type-unsupported ".
> >>>>>>>
> >>>>>>> At this point, I don't recall anyone suggesting xpath should not
> >>>>>>> be a mandatory for event filtering though.
> >>>>>>
> >>>>>> well, it's not mandatory for NETCONF-based filtering.  So, a
> >>>>>> system that doesn't support XPath filtering in NETCONF would
> have
> >>>>>> to support XPath filtering here?
> >>>>>
> >>>>> Hmm.  I had been hoping to have at least one (xpath) as mandatory.
> >>>>> But maybe that is unrealistic.
> >>>>>
> >>>>> What I am thinking is that maybe both filters should be optional
> >>>>> features.  And then specific transport drafts (like NETCONF) can
> >>>>> identify them as mandatory. At least when that transport is used.
> >>>>>
> >>>>>>>> * I see top-level /subscription-config and /subscriptions - is
> >>>>>>>> this NMDA compliant?
> >>>>>>>
> >>>>>>> As this pre-dates NMDA, we are awaiting the "you MUST make
> the
> >>>>>>> conversion" directive.  And if this comes, we will gladly do that.
> >>>>>>
> >>>>>>
> >> https://mailarchive.ietf.org/arch/msg/netmod/rqrXUqs8YMIfcrKZnSI
> >>>>>> oH
> >>>>>> 4g
> >>>>>> A-8M
> >>>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#sect
> >>>>>> io
> >>>>>> n-
> >>>>>> 4.23.3
> >>>>>
> >>>>> Yep.  We do fall in the SHOULD category :-)
> >>>>>
> >>>>> But seriously, we can convert.
> >>>>
> >>>> Before doing anything, make sure the "subscription-id" issue is
> >>>> resolved first.  If Rob's proposal is adopted, we will still need
> >>>> two lists, one config and one operational, even in the
> >>>> NMDA-compliant version.  Some changes might be needed in the
> >> naming
> >>>> of top-level containers though.
> >>>
> >>> Based on the comments received on the subscription-id datatype.
> >>> Rough consensus is integer.  We will covert to NMDA after all other
> >>> issues are closed in set of drafts going to WGLC.
> >>>
> >>> Eric
> >>>
> >>>>> The question is how to do this without losing our place in the
> >>>>> review queue.  We had expected to be through WGLC *long* before
> >>>>> NMDA was formalized.  And we are very concerned this policy
> change
> >>>>> could result in further delay.  So the current plan we have is to
> >>>>> get agreement on the contents of the model.  And then agreement
> >>>>> that we have converted what is an acceptable model into an
> >>>>> equivalent NMDA version.
> >>>>
> >>>>
> >>>> /martin
> >>>
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>>
> >
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> 
> Mahesh Jethanandani
> [e-mail]