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

"Eric Voit (evoit)" <evoit@cisco.com> 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)" <evoit@cisco.com> 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=zDualRWvSwyZj8MF
> > > > PL_Xo
> > > > >
> > > >
> > pkywEp9xEJgZXjyhdIBPog&s=Dcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2xpE
> > > > 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/rqrXUqs8YMIfcrKZnSIoH
> > > > 4g
> > > > A-8M
> > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#sectio
> > > > 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
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 