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

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

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