Re: [netmod] schema mount and YANG library

[joel jaeggli <[e-mail]>]

On 1/18/18 05:39, Juergen Schoenwaelder wrote:
> Ignoring process issues (not sure there are any), does it make sense
> to publish a YANG module on the standards-track that is replaced by
> something different 3-6 months later?

Perhaps I apply a different discount rate on the future particularly
when timelines are involved. e.g. 3 months turns into a year and half
pretty quickly.

I think it's more a question of can we live with publishing the module
now as is? Or can  we not live with publishing it now?

> Note that the NMDA contributors, after getting the overall design
> done, move sequentially through the details of the documents; we first
> focused on the NMDA document, which is in the RFC editor queue now. We
> then focussed on the protocol extensions, which are now in WG last
> call. Currently we are focusing on getting the new yang library
> finalized. If no major isses pop up, the NMDA work may be complete by
> the London IETF. Hence the 3 months lower bound mentioned above.
> 
> /js
> 
> On Thu, Jan 18, 2018 at 07:58:07AM -0500, Lou Berger wrote:
>> Martin,
>>
>> I do agree with that at some point we will need to revisit scheme mount in
>> the context of YL-bis, as there are different possible solutions for
>> handling different datastores mounting  different schema. I think Rob laid
>> out the options pretty well here, ie doing it now or publishing as is and
>> immediately working on the document that covers both.
>>
>> As I mentioned before I think this is as much a process issue as anything
>> else - and have a planned call to discuss possible directions with chairs. I
>> hope we can have some propose next steps on this to the working group in
>> short order.
>>
>> Lou
>>
>>
>> On January 18, 2018 2:57:23 AM Martin Bjorklund <[e-mail]> wrote:
>>
>>> Lou Berger <[e-mail]> wrote:
>>>>
>>>>
>>>> On 1/17/2018 11:18 AM, Martin Bjorklund wrote:
>>>> ...
>>>>>>> My main concern is actually the YL version.  I strongly think SM need
>>>>>>> to use YL-bis rather that the old YL, so that it can support NMDA.
>>>>>>>
>>>>>> Right now to SM is independent of Yang Library version and can run
>>>>>> with either.
>>>>> No this is not correct.  SM uses a grouping from the old YANG
>>>>> library (for the "use-schema" case),
>>>> I thought YLbis was an updat e to UL (i.e., no name change) as such SM
>>>> can include either.
>>>
>>> The old "modules-state" structure is deprecated, and a new structure
>>> that allows multiple datastores is defined.  Note that YLbis can be
>>> used by both NMDA-capabale and non-NMDA-capabale servers.
>>>
>>>>>   and talks about mounting
>>>>> "modules-state" ("inline" case).
>>>> In informative descriptions only.  Certainly these can be changed to
>>>> allow for YL-bis if need be.
>>>>
>>>>>> I certainly would expect use of Yang Library bis and nmda
>>>>>> to have advantages.
>>>>>>
>>>>>>> The implementation effort for supporting the new YL in clients and
>>>>>>> servers is minimal, esp. when compared to the efforts involved in
>>>>>>> supporting SM.
>>>>>>>
>>>>>>> Adding an indirection is (for me) less important, but it has the
>>>>>>> benefit of solving the two issues (a) and (b) above, and I haven't
>>>>>>> seen any technical problem with it.
>>>>>>>
>>>>>> (A) has implementation implications and those participating in the
>>>>>> discussion at the time expressed as not being worth the cost.
>>>>>> I don't believe b was seen as a significant issue either.
>>>>>>
>>>>>>> Do you have any technical concerns with using an annotation as an
>>>>>>> indirection?
>>>>>>>
>>>>>> The technicsl issue I have with the approaches the same one that was
>>>>>> raised when debated previously, ie the implementation overhead of
>>>>>> requiring inline schemas to be available at the top level.
>>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
>>>>> we need to use the new YL-bis, so that we can support the NMDA.
>>>> Given that NMDA support is not yet fully defined, we're still in the
>>>> transition period where support for both NMDA and non-NMDA
>>>> implementations need to be considered.  Rob presented some options
>>>> earlier in the thread that I think captures this.
>>>
>>> Again, note that YLbis supports both NMDA and non-NMDA servers.
>>>
>>> Also note that YLbis is just a different read-only monitoring
>>> structure.  Given an implementation that supports the old YL, it is
>>> trivial to add support for YLbis (especially compared to the more than
>>> non-trivial amount of work required to support schema mount...).
>>>
>>>
>>> /martin
>>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>