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

[Mahesh Jethanandani <[e-mail]>]

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]