Hi Lou,
On Fri, 2018-01-19 at 10:13 -0500, Lou Berger wrote:
> Martin,
>
> Managing transitions is always a challenge. Also coming up with a consensus
> solutions often involves compromise which will sometimes challenge
> enthusiasm for support of the solution. Unfortunately, schema mount hits
> both of these challenges.
Transition problems is what we would create by publishing the current revision
of SM now and another in a couple of months. It would most likely mean keeping
some annoying baggage like obsolete nodes that only confuse readers. We can and
should avoid this.
>
> > From the compromise standpoint, we've had parties basically negotiate over
>
> a period of 2 years on a solution that both accepted is workable. I know
> that the users of the draft explicitly decided that the documented solution
> was good enough for their needs and it was preferable to move forward then
> continue debating for their preferred changes.
>
> > From the transition standpoint we have a document that completed last call
>
> months ago with only minor issues being raised. It is true that the current
> document doesn't support different schemas in different data stores, in all
> but one case, and this limitation should certainly be documented. But from
For me, it is not so much about limitations but rather about architecture, i.e.
good design of metadata that describe the overall data model. If it is messy
with gaps covered by hand-waving statements, nobody will understand it.
Lada
> the process standpoint, it's rather hard to say that we should not move
> forward with a post last call document in deference to an alternative that
> has yet to be documented, debated, or whose impact can be fully analyzed.
>
> Lou
>
> On January 19, 2018 3:59:22 AM Martin Bjorklund <m...@tail-f.com> wrote:
> ...
> > Hi,
> >
> > joel jaeggli <joe...@bogus.com> wrote:
> > >
> > >
> > > On 1/18/18 11:15 AM, Martin Bjorklund wrote:
> > > > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > > > On Thu, 2018-01-18 at 14:39 +0100, 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?
> > > > >
> > > > > IMO such a document churn would be a serious mistake. In the
> > > > > documents
> > >
> > > that are
> > > > > currently on the table (at least NMDA, YLbis, SM) we are dealing with
> > >
> > > quite a
> > > > > few tricky and interrelated things, so it's important to come up with
> > > > > a
> > >
> > > coherent
> > > > > view into which all the components nicely fit. And I believe we are
> > > > > now
> > >
> > > quite
> > > > > close.
> > > > >
> > > > > Publishing an interim solution that is a priori known to be
> > > > > technically
> > >
> > > inferior
> > > > > would just confuse people. The fact that it can be hacked to support
> > > > > two or
> > > > > three particular data models (albeit important) doesn't warrant to do
> > > > > so.
> > > >
> > > > I strongly agree with this!
> > >
> > > Do we believe that documents using normative referencing to this draft
> > > e.g. in routing would require changes in order to accommodate an updated
> > > draft?
> > >
> > > If yes then we're doing ourselves a clear dis-service by essentially
> > > clearing the boards of the existing draft.
> >
> > As Lada wrote earlier, two of the three drafts need updated *examples*
> > in their appendicies. They do not need any changes to their normative
> > sections.
> >
> > > If that is the case we
> > > should consider publishing this one possibly with an appropriate
> > > applicability statement; the work on the new one can proceed so that at
> > > least they have a stable reference. This assumes not fundamental flaws
> > > that make the current one unusable.
> >
> > Since some time back, we require all drafts to be NMDA compliant. Why
> > should SM be different? Note that this solution does not *require*
> > NMDA.
> >
> > One reason for SM being late is that it has been difficult to find a
> > technical solution for which even the authors could agree. The
> > current draft is a compromise. By using YLbis we can solve some of
> > these issues, and since this is a central building block I think it
> > would be very unwise to publish it just to avoid updating two
> > examples.
> >
> >
> > /martin
> >
> >
> >
> > >
> > >
> > > > /martin
> > > >
> > > > > > 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.
> > > > >
> > > > > I agree, and will try to help.
> > > > >
> > > > > Thanks, Lada
> > > > >
> > > > > > /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
> > > > >
> > > > > --
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > >
> > >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
