Re: [netmod] schema mount and YANG library

[Andy Bierman <[e-mail]>]

Hi,


On Mon, Jan 22, 2018 at 9:44 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> Thanks. The longer WG last call thread started with Rob's message in
> which he also asked about alignment with the YANG library update
> (posted November 2nd). So the document is in a limbo state since
> November 6th.
>
>

Can somebody please answer some simple questions:

Q1) why can't SM use augment to add objects to YLbis?

Q2)  why should readers/developers of YLbis need to know
about SM if their implementations do not support SM at all?

Q3) Is there a msg in the email archive that explains the reasons that
YLbis needs to be delayed? Where is the concrete proposal to add
specific objects to YLbis?


/js
>
>

Andy



> On Mon, Jan 22, 2018 at 04:58:15PM +0000, Acee Lindem (acee) wrote:
> > It was WG Last Call’ed: https://mailarchive.ietf.org/arch/msg/netmod/
> csUvs6408En0yY-vapyU3IFcJqQ
> >
> > And it was closed: https://mailarchive.ietf.org/
> arch/msg/netmod/gbXE4Le1I_3Y5oaNnpjYoZZZ4lw
> >
> > However, it may not have ever completed.
> >
> > Thanks,
> > Acee
> >
> > On 1/22/18, 11:45 AM, "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-
> university.de> wrote:
> >
> >     Acee,
> >
> >     the documents that have already finished WG Last Call have a
> normative
> >     reference on schema mount, which has not yet finished WG Last Call as
> >     far as I recall. I think the RFC editor does not publish a document
> >     with a missing normative reference. I continue to believe that the
> >     time difference between doing the right thing and doing something
> >     faster using definition we are in the process to deprecate is really
> >     small. But of course, I may be entirely wrong.
> >
> >     /js
> >
> >     On Mon, Jan 22, 2018 at 04:18:15PM +0000, Acee Lindem (acee) wrote:
> >     > Hi Lada,
> >     >
> >     > My primary concern is that the YANG Schema Mount delay will not
> only hold the NI/LNE but all the models that are dependent on them (e.g.,
> L2VPN and L3VPN). This is for a document that has already finished WG Last
> Call. Additionally, your estimate for the size of the change and time to
> reach standardization is based on there being immediate consensus on the
> changes. This is probably overly optimistic given there was discussion on
> the proposed YANG Library BIS changes. I’d vote to publish the existing
> draft.
> >     >
> >     > In any case, being able to see the proposed changes ASAP is
> critical.
> >     >
> >     > Thanks,
> >     > Acee
> >     >
> >     > On 1/22/18, 8:45 AM, "netmod on behalf of Ladislav Lhotka" <
> [e-mail] on behalf of [e-mail]> wrote:
> >     >
> >     >     Juergen Schoenwaelder <[e-mail]>
> writes:
> >     >
> >     >     > On Fri, Jan 19, 2018 at 06:05:15PM +0000, Robert Wilton
> wrote:
> >     >     >>
> >     >     >> Hence, for me, I see the choice as:
> >     >     >> 1) do we publish the existing model now (perhaps also mark
> the draft as
> >     >     >> experimental) followed by an updated draft with the NMDA
> compatible module?
> >     >     >> 2) do we publish both models in a single draft (e.g. with
> the existing model
> >     >     >> in an appendix)?
> >     >     >> 3) do we only publish a single version of the draft with an
> NMDA compliant
> >     >     >> solution.
> >     >     >>
> >     >     >
> >     >     > I think the situation is as follows (likely obvious but it
> may help to
> >     >     > make sure we are all on the same page):
> >     >     >
> >     >     > - the NI and LNE models have a normative reference to
> >     >     >   I-D.ietf-netmod-schema-mount (and this makes sense since
> there are
> >     >     >   MUST sentences in the I-D)
> >     >     >
> >     >     > - I-D.ietf-netmod-schema-mount (last updated in October) has
> normative
> >     >     >   references to RFC 7895 (old YANG library)
> >     >     >
> >     >     > - RFC 7895 does not work with NMDA, NMDA work on a YANG
> library update
> >     >     >   replacing RFC 7895
> >     >     >
> >     >     > So the YANG library update is gating the schema mount update
> which is
> >     >     > gating the publication of the NI and LNE models.
> >     >     >
> >     >     > A proper solution would be to prioritize work on the YANG
> library
> >     >     > update and the schema mount update. I assume that the next
> revision of
> >     >     > the YANG library update (say end of January) is ready for WG
> last call
> >     >     > and perhaps the schema mount authors can take an effort to
> get that
> >     >     > document there as well, say beginning of February.
> >     >
> >     >     I completely agree.
> >     >
> >     >     Lada
> >     >
> >     >     >
> >     >     > /js
> >     >     >
> >     >     > --
> >     >     > Juergen Schoenwaelder           Jacobs University Bremen
> gGmbH
> >     >     > Phone: [phone]         Campus Ring 1 | 28759 Bremen
> | Germany
> >     >     > Fax:   [phone]         <https://www.jacobs-
> university.de/>
> >     >     >
> >     >     > _______________________________________________
> >     >     > netmod mailing list
> >     >     > [e-mail]
> >     >     > https://www.ietf.org/mailman/listinfo/netmod
> >     >
> >     >     --
> >     >     Ladislav Lhotka
> >     >     Head, CZ.NIC Labs
> >     >     PGP Key ID: 0xB8F92B08A9F76C67
> >     >
> >     >     _______________________________________________
> >     >     netmod mailing list
> >     >     [e-mail]
> >     >     https://www.ietf.org/mailman/listinfo/netmod
> >     >
> >     >
> >
> >     --
> >     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >     Phone: [phone]         Campus Ring 1 | 28759 Bremen |
> Germany
> >     Fax:   [phone]         <https://www.jacobs-university.de/>
> >
> >
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>