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 <m...@tail-f.com> wrote:
>>
>>> Lou Berger <lber...@labn.net> 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
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
