Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Ladislav Lhotka]

Robert Varga  writes:

> On 27/02/18 08:02, Ladislav Lhotka wrote:
>> The initial virtual interim decided to use Martin's combined proposal
>> and most of my subsequent objections were rejected on the basis of that
>> decision. That's why I hate discussing complicated things in virtual
>> interims - it it a safe and fast way to reach wrong decisions.
>
> Well said, I could not agree more. The standardization is taking *way*
> too long because the WG is ignoring the KISS principle and does not
> define simple (yet powerful) composable constructs.

In fact, it is just the good old Occam's Razor: Entities should not be
multiplied unnecessarily. Simplicity of concepts is especially important
here because the majority of YANG modules will be written (hopefully) by
people having only a casual experience with YANG.

Anyway, it doesn't help us in the current state of affairs. It looks
like we are stuck and no compromise is in sight.

Lada

>
> Regards,
> Robert
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Ladislav Lhotka]

Christian Hopps  writes:

> Ladislav Lhotka  writes:
>
>> On Tue, 2018-02-27 at 09:31 +0100, Juergen Schoenwaelder wrote:
>>> On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
>>> > Hi,
>>> >
>>> > Christian Hopps  wrote:
>>> > >
>>> > > Hi Rob,
>>> > >
>>> > > You do realize that no-one trying to actually deploy and run networks
>>> > > cares about live-discovery of different schema per datastore for the
>>> > > same mount point right? Like 99.999% of the clients know where things
>>> > > are supposed to reside and expect them to be there.
>>> >
>>> > But then why advertise anything at all?   We can do a *much* simpler
>>> > solution by just having the mountpoint extension, and nothing else.
>>> > Clients will know what to find anyway.
>>> >
>>>
>>> So it this a possible way out of the current situation? We publish a
>>> trimmed down document that just defines the mount point extension and
>>> we do an update of this document that adds all the details needed to
>>> obtain the schema information?
>>
>> I would say so. It would be immediately usable for the inline case.
>
> This still requires that we pull the routing NI work from the RFC ED
> queue, change normative text (the document specifically states that
> use-schema MUST be present, although it does mention that that may be
> relaxed in the future) as well as the examples listing the
> schema/modules, this is going to require at least another run through
> WGLC. It's slightly less obnoxious than the original proposal as its
> simply removing stuff and losing functionality vs. changing
> functionality.

As I already said, a reasonable alternative for me would be to proceed
with -08 and then do the YLbis and other changes as independent
work. This way, we could also hope in some feedback from NI/LNE
implementation.

Lada

>
> Thanks,
> Chris.
>
>> Lada
>>
>>>
>>> /js
>>>
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Christian Hopps]

Ladislav Lhotka  writes:


On Tue, 2018-02-27 at 09:31 +0100, Juergen Schoenwaelder wrote:

On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
> Hi,
>
> Christian Hopps  wrote:
> >
> > Hi Rob,
> >
> > You do realize that no-one trying to actually deploy and run networks
> > cares about live-discovery of different schema per datastore for the
> > same mount point right? Like 99.999% of the clients know where things
> > are supposed to reside and expect them to be there.
>
> But then why advertise anything at all?   We can do a *much* simpler
> solution by just having the mountpoint extension, and nothing else.
> Clients will know what to find anyway.
>

So it this a possible way out of the current situation? We publish a
trimmed down document that just defines the mount point extension and
we do an update of this document that adds all the details needed to
obtain the schema information?


I would say so. It would be immediately usable for the inline case.


This still requires that we pull the routing NI work from the RFC ED queue, 
change normative text (the document specifically states that use-schema MUST be 
present, although it does mention that that may be relaxed in the future) as 
well as the examples listing the schema/modules, this is going to require at 
least another run through WGLC. It's slightly less obnoxious than the original 
proposal as its simply removing stuff and losing functionality vs. changing 
functionality.

Thanks,
Chris.


Lada



/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Kent Watsen]

So it this a possible way out of the current situation? We publish a
trimmed down document that just defines the mount point extension and
we do an update of this document that adds all the details needed to
obtain the schema information?

/js

+1

This was something I suggested a while back.  Though I didn’t detail this 
specific proposal, rather something along the lines of removing unnecessary 
parts, in order to reduce the debt carried forward as much as possible.

Kent   // contributor
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Christian Hopps  wrote:
> > > 
> > > Hi Rob,
> > > 
> > > You do realize that no-one trying to actually deploy and run networks
> > > cares about live-discovery of different schema per datastore for the
> > > same mount point right? Like 99.999% of the clients know where things
> > > are supposed to reside and expect them to be there.
> > 
> > But then why advertise anything at all?   We can do a *much* simpler
> > solution by just having the mountpoint extension, and nothing else.
> > Clients will know what to find anyway.
> >
> 
> So it this a possible way out of the current situation? We publish a
> trimmed down document that just defines the mount point extension and
> we do an update of this document that adds all the details needed to
> obtain the schema information?

Not optimal, but I can accept this as a way to move forward.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Ladislav Lhotka]

On Tue, 2018-02-27 at 09:31 +0100, Juergen Schoenwaelder wrote:
> On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Christian Hopps  wrote:
> > > 
> > > Hi Rob,
> > > 
> > > You do realize that no-one trying to actually deploy and run networks
> > > cares about live-discovery of different schema per datastore for the
> > > same mount point right? Like 99.999% of the clients know where things
> > > are supposed to reside and expect them to be there.
> > 
> > But then why advertise anything at all?   We can do a *much* simpler
> > solution by just having the mountpoint extension, and nothing else.
> > Clients will know what to find anyway.
> > 
> 
> So it this a possible way out of the current situation? We publish a
> trimmed down document that just defines the mount point extension and
> we do an update of this document that adds all the details needed to
> obtain the schema information?

I would say so. It would be immediately usable for the inline case.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Juergen Schoenwaelder]

On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Christian Hopps  wrote:
> > 
> > Hi Rob,
> > 
> > You do realize that no-one trying to actually deploy and run networks
> > cares about live-discovery of different schema per datastore for the
> > same mount point right? Like 99.999% of the clients know where things
> > are supposed to reside and expect them to be there.
> 
> But then why advertise anything at all?   We can do a *much* simpler
> solution by just having the mountpoint extension, and nothing else.
> Clients will know what to find anyway.
>

So it this a possible way out of the current situation? We publish a
trimmed down document that just defines the mount point extension and
we do an update of this document that adds all the details needed to
obtain the schema information?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Ladislav Lhotka]

Christian Hopps  writes:

> Martin Bjorklund  writes:
>
>> Hi,
>>
>> Christian Hopps  wrote:
>>>
>>> Hi Rob,
>>>
>>> You do realize that no-one trying to actually deploy and run networks
>>> cares about live-discovery of different schema per datastore for the
>>> same mount point right? Like 99.999% of the clients know where things
>>> are supposed to reside and expect them to be there.
>>
>> But then why advertise anything at all?   We can do a *much* simpler
>> solution by just having the mountpoint extension, and nothing else.
>> Clients will know what to find anyway.
>
> That was the idea Lou and I brought up over 2 *years* ago, yes. :)

We can and should still do that for the inline case, even after
publishing -08.

>
> But good points were made for something more general and powerful, and
> we all agreed with those, so..

This is not true, I have never agreed to mixing up inline and use-schema
cases. Both are useful but they should be separate.

The initial virtual interim decided to use Martin's combined proposal
and most of my subsequent objections were rejected on the basis of that
decision. That's why I hate discussing complicated things in virtual
interims - it it a safe and fast way to reach wrong decisions.

Lada

>
>> My experience, which may differ from yours, is that correct knowledge
>> about the devices' datamodels and revisions is crucial for correct
>> implementation of automation of network services.  The application
>> programmer can program the intent for some set of data models, and
>> then the orchestrator can automatically decide what to do for a given
>> device depending on which data models it advertises.
>
> and that's why we have a module list present in the work now ready to 
> publish. It's enough for now. Perfect is killing good enough here.
>
> Thanks,
> Chris.
>
>>
>>
>>
>> /martin
>>
>>
>>
>>
>> At most (although
>>> still not common) they may want to know what modules are supported
>>> under a mount point. What your talking about is a severe edge case
>>> that apparently has achieved extreme importance in a very small group
>>> of people's views.
>>>
>>> Thanks,
>>> Chris.
>>>
>>> Robert Wilton  writes:
>>>
>>> > Hi Chris,
>>> >
>>> > I've got no desire or intent to try and slow down the NI and LNE
>>> > drafts, or any
>>> > that depend on them. I actually agree that this is critically
>>> > important that
>>> > IETF gets modules standardized/finished so that everyone can use them.
>>> >
>>> > However, ...
>>> >
>>> > YLbis has quite a different structure to YL. The main part of this
>>> > change was
>>> > to support NMDA, the other part of this change was to better support
>>> > things like
>>> > SM, or YANG packages.
>>> >
>>> > I don't think that there is a clean, backwards compatible, way to go
>>> > from the
>>> > YANG module in SM -08 to one that is going to work well with YLbis and
>>> > other
>>> > YLbis extensions/augmentations that seem to be coming down the
>>> > line. Given what
>>> > we know now, I believe that the correct medium/long term structure for
>>> > the SM
>>> > YANG module, taking YLbis into account, is the one proposed in pre09,
>>> > because it
>>> > directly augments the YLbis structure, and hence any future
>>> > augmentations to
>>> > YLbis should automatically extend to SM mounted schema as well.
>>> >
>>> > I think that the likely future technical issues with the -08 module
>>> > will be:
>>> > - supporting NMDA in a clean consistent way
>>> > - adding in support for SemVer
>>> > - additional capability reporting as an augmentation to YANG library
>>> >
>>> > So, if -08 proceeds as is, then it seems to me like one of three
>>> > things will
>>> > need to happen:
>>> > 1) Their will need to be a non backwards compatible update to the SM
>>> > model that
>>> > is the same/similar to pre09.
>>> > 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
>>> > explicitly
>>> > mounted schema.
>>> > 3) We accrue technical debt, implementations need to support two YL
>>> > module
>>> > structures, the one in SM and the one in YLbis, and future extensions
>>> > need to
>>> > augment both the SM structure and YLbis structure.
>>> >
>>> > I don't like the idea of (2) or (3), but I don't know if others will
>>> > find (1)
>>> > acceptable.
>>> >
>>> > But I do agree that we are just going round in circles on this:
>>> > - Using the pre09 structure is not acceptable to some folks
>>> > - Publishing a draft with both -08 and pre09 structure is liked by even
>>> > - less
>>> > folks.
>>> >
>>> > Perhaps publishing -08 is the only option. My hope is that the WG will
>>> > support
>>> > somebody subsequently doing solution (1), otherwise it seems like a
>>> > missed
>>> > opportunity to get this right.
>>> >
>>> > Thanks,
>>> > Rob
>>> >
>>> >
>>> > On 24/02/2018 13:54, Christian Hopps wrote:
>>> >> My position,
>>> >>
>>> >> It may be the case that there's even a better 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Christian Hopps]

Martin Bjorklund  writes:


Hi,

Christian Hopps  wrote:


Hi Rob,

You do realize that no-one trying to actually deploy and run networks
cares about live-discovery of different schema per datastore for the
same mount point right? Like 99.999% of the clients know where things
are supposed to reside and expect them to be there.


But then why advertise anything at all?   We can do a *much* simpler
solution by just having the mountpoint extension, and nothing else.
Clients will know what to find anyway.


That was the idea Lou and I brought up over 2 *years* ago, yes. :)

But good points were made for something more general and powerful, and we all 
agreed with those, so..


My experience, which may differ from yours, is that correct knowledge
about the devices' datamodels and revisions is crucial for correct
implementation of automation of network services.  The application
programmer can program the intent for some set of data models, and
then the orchestrator can automatically decide what to do for a given
device depending on which data models it advertises.


and that's why we have a module list present in the work now ready to publish. 
It's enough for now. Perfect is killing good enough here.

Thanks,
Chris.





/martin




At most (although

still not common) they may want to know what modules are supported
under a mount point. What your talking about is a severe edge case
that apparently has achieved extreme importance in a very small group
of people's views.

Thanks,
Chris.

Robert Wilton  writes:

> Hi Chris,
>
> I've got no desire or intent to try and slow down the NI and LNE
> drafts, or any
> that depend on them. I actually agree that this is critically
> important that
> IETF gets modules standardized/finished so that everyone can use them.
>
> However, ...
>
> YLbis has quite a different structure to YL. The main part of this
> change was
> to support NMDA, the other part of this change was to better support
> things like
> SM, or YANG packages.
>
> I don't think that there is a clean, backwards compatible, way to go
> from the
> YANG module in SM -08 to one that is going to work well with YLbis and
> other
> YLbis extensions/augmentations that seem to be coming down the
> line. Given what
> we know now, I believe that the correct medium/long term structure for
> the SM
> YANG module, taking YLbis into account, is the one proposed in pre09,
> because it
> directly augments the YLbis structure, and hence any future
> augmentations to
> YLbis should automatically extend to SM mounted schema as well.
>
> I think that the likely future technical issues with the -08 module
> will be:
> - supporting NMDA in a clean consistent way
> - adding in support for SemVer
> - additional capability reporting as an augmentation to YANG library
>
> So, if -08 proceeds as is, then it seems to me like one of three
> things will
> need to happen:
> 1) Their will need to be a non backwards compatible update to the SM
> model that
> is the same/similar to pre09.
> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
> explicitly
> mounted schema.
> 3) We accrue technical debt, implementations need to support two YL
> module
> structures, the one in SM and the one in YLbis, and future extensions
> need to
> augment both the SM structure and YLbis structure.
>
> I don't like the idea of (2) or (3), but I don't know if others will
> find (1)
> acceptable.
>
> But I do agree that we are just going round in circles on this:
> - Using the pre09 structure is not acceptable to some folks
> - Publishing a draft with both -08 and pre09 structure is liked by even
> - less
> folks.
>
> Perhaps publishing -08 is the only option. My hope is that the WG will
> support
> somebody subsequently doing solution (1), otherwise it seems like a
> missed
> opportunity to get this right.
>
> Thanks,
> Rob
>
>
> On 24/02/2018 13:54, Christian Hopps wrote:
>> My position,
>>
>> It may be the case that there's even a better cleaner solution;
>> however, it's
>> simply too late for major modifications to this work that don't
>> actually
>> address functional failures. The draft as proposed works for the
>> people who
>> need to get work done.
>>
>> We have multiple pending RFCs - MISREF on this document. These RFCs
>> would have
>> to be pulled from the RFC EDITOR queue, and reworked to be compliant
>> again,
>> and this very well could lead to discovering issues with your new
>> proposal.
>> Any new issues discovered in either the pending RFCs *or* in the new
>> solution
>> would then need to be worked out and fixed. Please recall that this
>> actually
>> occurred on the first round (i.e., doing the examples led to
>> discovering
>> problems with the drafts), so it's not unreasonable at all to assume
>> this
>> would happen again.
>>
>> Look this just isn't a simple change your proposing. It involves a
>> large
>> upheaval, killing the pending RFC status on multiple 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Martin Bjorklund]

Hi,

Christian Hopps  wrote:
> 
> Hi Rob,
> 
> You do realize that no-one trying to actually deploy and run networks
> cares about live-discovery of different schema per datastore for the
> same mount point right? Like 99.999% of the clients know where things
> are supposed to reside and expect them to be there.

But then why advertise anything at all?   We can do a *much* simpler
solution by just having the mountpoint extension, and nothing else.
Clients will know what to find anyway.

My experience, which may differ from yours, is that correct knowledge
about the devices' datamodels and revisions is crucial for correct
implementation of automation of network services.  The application
programmer can program the intent for some set of data models, and
then the orchestrator can automatically decide what to do for a given
device depending on which data models it advertises.



/martin




At most (although
> still not common) they may want to know what modules are supported
> under a mount point. What your talking about is a severe edge case
> that apparently has achieved extreme importance in a very small group
> of people's views.
> 
> Thanks,
> Chris.
> 
> Robert Wilton  writes:
> 
> > Hi Chris,
> >
> > I've got no desire or intent to try and slow down the NI and LNE
> > drafts, or any
> > that depend on them. I actually agree that this is critically
> > important that
> > IETF gets modules standardized/finished so that everyone can use them.
> >
> > However, ...
> >
> > YLbis has quite a different structure to YL. The main part of this
> > change was
> > to support NMDA, the other part of this change was to better support
> > things like
> > SM, or YANG packages.
> >
> > I don't think that there is a clean, backwards compatible, way to go
> > from the
> > YANG module in SM -08 to one that is going to work well with YLbis and
> > other
> > YLbis extensions/augmentations that seem to be coming down the
> > line. Given what
> > we know now, I believe that the correct medium/long term structure for
> > the SM
> > YANG module, taking YLbis into account, is the one proposed in pre09,
> > because it
> > directly augments the YLbis structure, and hence any future
> > augmentations to
> > YLbis should automatically extend to SM mounted schema as well.
> >
> > I think that the likely future technical issues with the -08 module
> > will be:
> > - supporting NMDA in a clean consistent way
> > - adding in support for SemVer
> > - additional capability reporting as an augmentation to YANG library
> >
> > So, if -08 proceeds as is, then it seems to me like one of three
> > things will
> > need to happen:
> > 1) Their will need to be a non backwards compatible update to the SM
> > model that
> > is the same/similar to pre09.
> > 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
> > explicitly
> > mounted schema.
> > 3) We accrue technical debt, implementations need to support two YL
> > module
> > structures, the one in SM and the one in YLbis, and future extensions
> > need to
> > augment both the SM structure and YLbis structure.
> >
> > I don't like the idea of (2) or (3), but I don't know if others will
> > find (1)
> > acceptable.
> >
> > But I do agree that we are just going round in circles on this:
> > - Using the pre09 structure is not acceptable to some folks
> > - Publishing a draft with both -08 and pre09 structure is liked by even
> > - less
> > folks.
> >
> > Perhaps publishing -08 is the only option. My hope is that the WG will
> > support
> > somebody subsequently doing solution (1), otherwise it seems like a
> > missed
> > opportunity to get this right.
> >
> > Thanks,
> > Rob
> >
> >
> > On 24/02/2018 13:54, Christian Hopps wrote:
> >> My position,
> >>
> >> It may be the case that there's even a better cleaner solution;
> >> however, it's
> >> simply too late for major modifications to this work that don't
> >> actually
> >> address functional failures. The draft as proposed works for the
> >> people who
> >> need to get work done.
> >>
> >> We have multiple pending RFCs - MISREF on this document. These RFCs
> >> would have
> >> to be pulled from the RFC EDITOR queue, and reworked to be compliant
> >> again,
> >> and this very well could lead to discovering issues with your new
> >> proposal.
> >> Any new issues discovered in either the pending RFCs *or* in the new
> >> solution
> >> would then need to be worked out and fixed. Please recall that this
> >> actually
> >> occurred on the first round (i.e., doing the examples led to
> >> discovering
> >> problems with the drafts), so it's not unreasonable at all to assume
> >> this
> >> would happen again.
> >>
> >> Look this just isn't a simple change your proposing. It involves a
> >> large
> >> upheaval, killing the pending RFC status on multiple documents that
> >> the
> >> industry is waiting on. Please see this.
> >>
> >> Thanks,
> >> Chris.
> >>
> >>
> >> Martin Bjorklund  

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Ladislav Lhotka]

On Mon, 2018-02-26 at 14:16 +, Robert Wilton wrote:
> Hi Lada,
> 
> 
> On 26/02/2018 14:05, Ladislav Lhotka wrote:
> > Hi Rob,
> > 
> > Robert Wilton  writes:
> > 
> > > Hi Chris,
> > > 
> > > I've got no desire or intent to try and slow down the NI and LNE drafts,
> > > or any that depend on them.  I actually agree that this is critically
> > > important that IETF gets modules standardized/finished so that everyone
> > > can use them.
> > > 
> > > However, ...
> > > 
> > > YLbis has quite a different structure to YL.  The main part of this
> > > change was to support NMDA, the other part of this change was to better
> > > support things like SM, or YANG packages.
> > > 
> > > I don't think that there is a clean, backwards compatible, way to go
> > > from the YANG module in SM -08 to one that is going to work well with
> > > YLbis and other YLbis extensions/augmentations that seem to be coming
> > 
> > I don't think this is true - all YANG modules that work with -08 should
> > work with pre-09.
> 
> Sorry, I think that my point wasn't clear:
> 
> I don't think that you can go from the ietf-yang-schema-mount YANG 
> module defined in SM -08 to something like the ietf-yang-schema-mount 
> YANG module defined in pre09 in a backwards compatible way.  I.e. just 
> following the "Updating a Module" in RFC 7950 chapter 11.

OK, right, but in this case it is necessary to start from a clean slate - old
clients supporting only RFC 7895 cannot work with YLbis, even if the update
rules are followed.

Lada  

> 
> In terms of the actual modules that are being mounted, I agree, all 
> modules will work in both.
> 
> 
> > 
> > > down the line.  Given what we know now, I believe that the correct
> > > medium/long term structure for the SM YANG module, taking YLbis into
> > > account, is the one proposed in pre09, because it directly augments the
> > > YLbis structure, and hence any future augmentations to YLbis should
> > > automatically extend to SM mounted schema as well.
> > > 
> > > I think that the likely future technical issues with the -08 module will
> > > be:
> > > - supporting NMDA in a clean consistent way
> > > - adding in support for SemVer
> > > - additional capability reporting as an augmentation to YANG library
> > > 
> > > So, if -08 proceeds as is, then it seems to me like one of three things
> > > will need to happen:
> > > 1) Their will need to be a non backwards compatible update to the SM
> > > model that is the same/similar to pre09.
> > > 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
> > > explicitly mounted schema.
> > 
> > An acceptable compromise for me would be to publish -08 and accept both
> > 1 and 2 above. The benefits of doing so would be
> > 
> > - LNE/NI work won't be blocked
> > 
> > - some experience may be gained from the implementers that can improve
> >the ultimate YLbis-based solution
> > 
> > - there will be more time to reconsider the design and presentation of
> >the two concepts (inline and use-schema).
> > 
> > > 3) We accrue technical debt, implementations need to support two YL
> > > module structures, the one in SM and the one in YLbis, and future
> > > extensions need to augment both the SM structure and YLbis structure.
> > 
> > If we eventually do the right thing, then SM in the -08 form will be
> > abandoned along with the old YL.
> > 
> > Lada
> 
> Thanks,
> Rob
> 
> 
> > 
> > > I don't like the idea of (2) or (3), but I don't know if others will
> > > find (1) acceptable.
> > > 
> > > But I do agree that we are just going round in circles on this:
> > > - Using the pre09 structure is not acceptable to some folks
> > > - Publishing a draft with both -08 and pre09 structure is liked by even
> > > less folks.
> > > 
> > > Perhaps publishing -08 is the only option.  My hope is that the WG will
> > > support somebody subsequently doing solution (1), otherwise it seems
> > > like a missed opportunity to get this right.
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > On 24/02/2018 13:54, Christian Hopps wrote:
> > > > My position,
> > > > 
> > > > It may be the case that there's even a better cleaner solution;
> > > > however, it's simply too late for major modifications to this work
> > > > that don't actually address functional failures.  The draft as
> > > > proposed works for the people who need to get work done.
> > > > 
> > > > We have multiple pending RFCs - MISREF on this document. These RFCs
> > > > would have to be pulled from the RFC EDITOR queue, and reworked to be
> > > > compliant again, and this very well could lead to discovering issues
> > > > with your new proposal. Any new issues discovered in either the
> > > > pending RFCs *or* in the new solution would then need to be worked out
> > > > and fixed. Please recall that this actually occurred on the first
> > > > round (i.e., doing the examples led to discovering problems with the
> > > > drafts), so it's not unreasonable at all to assume this would 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Robert Wilton]

Hi Lada,


On 26/02/2018 14:05, Ladislav Lhotka wrote:

Hi Rob,

Robert Wilton  writes:


Hi Chris,

I've got no desire or intent to try and slow down the NI and LNE drafts,
or any that depend on them.  I actually agree that this is critically
important that IETF gets modules standardized/finished so that everyone
can use them.

However, ...

YLbis has quite a different structure to YL.  The main part of this
change was to support NMDA, the other part of this change was to better
support things like SM, or YANG packages.

I don't think that there is a clean, backwards compatible, way to go
from the YANG module in SM -08 to one that is going to work well with
YLbis and other YLbis extensions/augmentations that seem to be coming

I don't think this is true - all YANG modules that work with -08 should
work with pre-09.

Sorry, I think that my point wasn't clear:

I don't think that you can go from the ietf-yang-schema-mount YANG 
module defined in SM -08 to something like the ietf-yang-schema-mount 
YANG module defined in pre09 in a backwards compatible way.  I.e. just 
following the "Updating a Module" in RFC 7950 chapter 11.


In terms of the actual modules that are being mounted, I agree, all 
modules will work in both.






down the line.  Given what we know now, I believe that the correct
medium/long term structure for the SM YANG module, taking YLbis into
account, is the one proposed in pre09, because it directly augments the
YLbis structure, and hence any future augmentations to YLbis should
automatically extend to SM mounted schema as well.

I think that the likely future technical issues with the -08 module will be:
- supporting NMDA in a clean consistent way
- adding in support for SemVer
- additional capability reporting as an augmentation to YANG library

So, if -08 proceeds as is, then it seems to me like one of three things
will need to happen:
1) Their will need to be a non backwards compatible update to the SM
model that is the same/similar to pre09.
2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
explicitly mounted schema.

An acceptable compromise for me would be to publish -08 and accept both
1 and 2 above. The benefits of doing so would be

- LNE/NI work won't be blocked

- some experience may be gained from the implementers that can improve
   the ultimate YLbis-based solution

- there will be more time to reconsider the design and presentation of
   the two concepts (inline and use-schema).


3) We accrue technical debt, implementations need to support two YL
module structures, the one in SM and the one in YLbis, and future
extensions need to augment both the SM structure and YLbis structure.

If we eventually do the right thing, then SM in the -08 form will be
abandoned along with the old YL.

Lada

Thanks,
Rob





I don't like the idea of (2) or (3), but I don't know if others will
find (1) acceptable.

But I do agree that we are just going round in circles on this:
- Using the pre09 structure is not acceptable to some folks
- Publishing a draft with both -08 and pre09 structure is liked by even
less folks.

Perhaps publishing -08 is the only option.  My hope is that the WG will
support somebody subsequently doing solution (1), otherwise it seems
like a missed opportunity to get this right.

Thanks,
Rob


On 24/02/2018 13:54, Christian Hopps wrote:

My position,

It may be the case that there's even a better cleaner solution;
however, it's simply too late for major modifications to this work
that don't actually address functional failures.  The draft as
proposed works for the people who need to get work done.

We have multiple pending RFCs - MISREF on this document. These RFCs
would have to be pulled from the RFC EDITOR queue, and reworked to be
compliant again, and this very well could lead to discovering issues
with your new proposal. Any new issues discovered in either the
pending RFCs *or* in the new solution would then need to be worked out
and fixed. Please recall that this actually occurred on the first
round (i.e., doing the examples led to discovering problems with the
drafts), so it's not unreasonable at all to assume this would happen
again.

Look this just isn't a simple change your proposing. It involves a
large upheaval, killing the pending RFC status on multiple documents
that the industry is waiting on. Please see this.

Thanks,
Chris.


Martin Bjorklund  writes:


Hi,

Robert Wilton  wrote:

Hi Lou,

I think that this solution is inferior to the model presented in
pre-09.

I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Ladislav Lhotka]

Hi Rob,

Robert Wilton  writes:

> Hi Chris,
>
> I've got no desire or intent to try and slow down the NI and LNE drafts, 
> or any that depend on them.  I actually agree that this is critically 
> important that IETF gets modules standardized/finished so that everyone 
> can use them.
>
> However, ...
>
> YLbis has quite a different structure to YL.  The main part of this 
> change was to support NMDA, the other part of this change was to better 
> support things like SM, or YANG packages.
>
> I don't think that there is a clean, backwards compatible, way to go 
> from the YANG module in SM -08 to one that is going to work well with 
> YLbis and other YLbis extensions/augmentations that seem to be coming

I don't think this is true - all YANG modules that work with -08 should
work with pre-09.

> down the line.  Given what we know now, I believe that the correct 
> medium/long term structure for the SM YANG module, taking YLbis into 
> account, is the one proposed in pre09, because it directly augments the 
> YLbis structure, and hence any future augmentations to YLbis should 
> automatically extend to SM mounted schema as well.
>
> I think that the likely future technical issues with the -08 module will be:
> - supporting NMDA in a clean consistent way
> - adding in support for SemVer
> - additional capability reporting as an augmentation to YANG library
>
> So, if -08 proceeds as is, then it seems to me like one of three things 
> will need to happen:
> 1) Their will need to be a non backwards compatible update to the SM 
> model that is the same/similar to pre09.
> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for 
> explicitly mounted schema.

An acceptable compromise for me would be to publish -08 and accept both
1 and 2 above. The benefits of doing so would be

- LNE/NI work won't be blocked

- some experience may be gained from the implementers that can improve
  the ultimate YLbis-based solution

- there will be more time to reconsider the design and presentation of
  the two concepts (inline and use-schema).

> 3) We accrue technical debt, implementations need to support two YL 
> module structures, the one in SM and the one in YLbis, and future 
> extensions need to augment both the SM structure and YLbis structure.

If we eventually do the right thing, then SM in the -08 form will be
abandoned along with the old YL.

Lada

>
> I don't like the idea of (2) or (3), but I don't know if others will 
> find (1) acceptable.
>
> But I do agree that we are just going round in circles on this:
> - Using the pre09 structure is not acceptable to some folks
> - Publishing a draft with both -08 and pre09 structure is liked by even 
> less folks.
>
> Perhaps publishing -08 is the only option.  My hope is that the WG will 
> support somebody subsequently doing solution (1), otherwise it seems 
> like a missed opportunity to get this right.
>
> Thanks,
> Rob
>
>
> On 24/02/2018 13:54, Christian Hopps wrote:
>> My position,
>>
>> It may be the case that there's even a better cleaner solution; 
>> however, it's simply too late for major modifications to this work 
>> that don't actually address functional failures.  The draft as 
>> proposed works for the people who need to get work done.
>>
>> We have multiple pending RFCs - MISREF on this document. These RFCs 
>> would have to be pulled from the RFC EDITOR queue, and reworked to be 
>> compliant again, and this very well could lead to discovering issues 
>> with your new proposal. Any new issues discovered in either the 
>> pending RFCs *or* in the new solution would then need to be worked out 
>> and fixed. Please recall that this actually occurred on the first 
>> round (i.e., doing the examples led to discovering problems with the 
>> drafts), so it's not unreasonable at all to assume this would happen 
>> again.
>>
>> Look this just isn't a simple change your proposing. It involves a 
>> large upheaval, killing the pending RFC status on multiple documents 
>> that the industry is waiting on. Please see this.
>>
>> Thanks,
>> Chris.
>>
>>
>> Martin Bjorklund  writes:
>>
>>> Hi,
>>>
>>> Robert Wilton  wrote:
 Hi Lou,

 I think that this solution is inferior to the model presented in
 pre-09.
>>>
>>> I agree.  Servers that are NMDA-compliant, or implements YANG Library
>>> bis will have to present schemas in two different structures,
>>> depending on where the schema is used, and clients will have to code
>>> for both.  With the solution in pre-09, there is just one structure.
>>> A single structure also has other benefits (apart from being simpler),
>>> e.g., if we augment it with the meta data that has been discussed
>>> recently, we can augment a single structure.
>>
>>> /martin
>>>
>>>
>>>
 I would prefer that we publish pre09 instead, potentially including
 the -08 model in the appendix if that helps progress the document in a
 more expedient fashion.

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Robert Wilton]

Hi Chris,

The future issues that I'm predicting is not tied to per datastore 
schema, but because the SM YANG module is tied to a version of YL that 
is being deprecated and replaced by a similar but different structure in 
YLbis.


If all mounted modules are also available at top level modules, and 
hence will be reported in YLbis regardless, then I agree that it 
probably doesn't matter so much.


But if there are YANG modules that are only available at mounted 
locations (and not at the top level) then they would not be listed in 
the top level YANG library and I think that you will hit the issues that 
I describe below.  E.g. you wouldn't be able to retrieve the SemVer 
information for those mounted modules, etc.


Thanks,
Rob


On 26/02/2018 11:52, Christian Hopps wrote:


Hi Rob,

You do realize that no-one trying to actually deploy and run networks 
cares about live-discovery of different schema per datastore for the 
same mount point right? Like 99.999% of the clients know where things 
are supposed to reside and expect them to be there. At most (although 
still not common) they may want to know what modules are supported 
under a mount point. What your talking about is a severe edge case 
that apparently has achieved extreme importance in a very small group 
of people's views.


Thanks,
Chris.

Robert Wilton  writes:


Hi Chris,

I've got no desire or intent to try and slow down the NI and LNE 
drafts, or any
that depend on them. I actually agree that this is critically 
important that

IETF gets modules standardized/finished so that everyone can use them.

However, ...

YLbis has quite a different structure to YL. The main part of this 
change was
to support NMDA, the other part of this change was to better support 
things like

SM, or YANG packages.

I don't think that there is a clean, backwards compatible, way to go 
from the
YANG module in SM -08 to one that is going to work well with YLbis 
and other
YLbis extensions/augmentations that seem to be coming down the line. 
Given what
we know now, I believe that the correct medium/long term structure 
for the SM
YANG module, taking YLbis into account, is the one proposed in pre09, 
because it
directly augments the YLbis structure, and hence any future 
augmentations to

YLbis should automatically extend to SM mounted schema as well.

I think that the likely future technical issues with the -08 module 
will be:

- supporting NMDA in a clean consistent way
- adding in support for SemVer
- additional capability reporting as an augmentation to YANG library

So, if -08 proceeds as is, then it seems to me like one of three 
things will

need to happen:
1) Their will need to be a non backwards compatible update to the SM 
model that

is the same/similar to pre09.
2) YLbis and SM diverge, stuff that augments YLbis doesn't work for 
explicitly

mounted schema.
3) We accrue technical debt, implementations need to support two YL 
module
structures, the one in SM and the one in YLbis, and future extensions 
need to

augment both the SM structure and YLbis structure.

I don't like the idea of (2) or (3), but I don't know if others will 
find (1)

acceptable.

But I do agree that we are just going round in circles on this:
- Using the pre09 structure is not acceptable to some folks
- Publishing a draft with both -08 and pre09 structure is liked by 
even less

folks.

Perhaps publishing -08 is the only option. My hope is that the WG 
will support
somebody subsequently doing solution (1), otherwise it seems like a 
missed

opportunity to get this right.

Thanks,
Rob


On 24/02/2018 13:54, Christian Hopps wrote:

My position,

It may be the case that there's even a better cleaner solution; 
however, it's
simply too late for major modifications to this work that don't 
actually
address functional failures. The draft as proposed works for the 
people who

need to get work done.

We have multiple pending RFCs - MISREF on this document. These RFCs 
would have
to be pulled from the RFC EDITOR queue, and reworked to be compliant 
again,
and this very well could lead to discovering issues with your new 
proposal.
Any new issues discovered in either the pending RFCs *or* in the new 
solution
would then need to be worked out and fixed. Please recall that this 
actually
occurred on the first round (i.e., doing the examples led to 
discovering
problems with the drafts), so it's not unreasonable at all to assume 
this

would happen again.

Look this just isn't a simple change your proposing. It involves a 
large

upheaval, killing the pending RFC status on multiple documents that the
industry is waiting on. Please see this.

Thanks,
Chris.


Martin Bjorklund  writes:


Hi,

Robert Wilton  wrote:

Hi Lou,

I think that this solution is inferior to the model presented in
pre-09.


I agree. Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Christian Hopps]

Hi Rob,

You do realize that no-one trying to actually deploy and run networks cares 
about live-discovery of different schema per datastore for the same mount point 
right? Like 99.999% of the clients know where things are supposed to reside and 
expect them to be there. At most (although still not common) they may want to 
know what modules are supported under a mount point. What your talking about is 
a severe edge case that apparently has achieved extreme importance in a very 
small group of people's views.

Thanks,
Chris.

Robert Wilton  writes:


Hi Chris,

I've got no desire or intent to try and slow down the NI and LNE drafts, or any
that depend on them. I actually agree that this is critically important that
IETF gets modules standardized/finished so that everyone can use them.

However, ...

YLbis has quite a different structure to YL. The main part of this change was
to support NMDA, the other part of this change was to better support things like
SM, or YANG packages.

I don't think that there is a clean, backwards compatible, way to go from the
YANG module in SM -08 to one that is going to work well with YLbis and other
YLbis extensions/augmentations that seem to be coming down the line. Given what
we know now, I believe that the correct medium/long term structure for the SM
YANG module, taking YLbis into account, is the one proposed in pre09, because it
directly augments the YLbis structure, and hence any future augmentations to
YLbis should automatically extend to SM mounted schema as well.

I think that the likely future technical issues with the -08 module will be:
- supporting NMDA in a clean consistent way
- adding in support for SemVer
- additional capability reporting as an augmentation to YANG library

So, if -08 proceeds as is, then it seems to me like one of three things will
need to happen:
1) Their will need to be a non backwards compatible update to the SM model that
is the same/similar to pre09.
2) YLbis and SM diverge, stuff that augments YLbis doesn't work for explicitly
mounted schema.
3) We accrue technical debt, implementations need to support two YL module
structures, the one in SM and the one in YLbis, and future extensions need to
augment both the SM structure and YLbis structure.

I don't like the idea of (2) or (3), but I don't know if others will find (1)
acceptable.

But I do agree that we are just going round in circles on this:
- Using the pre09 structure is not acceptable to some folks
- Publishing a draft with both -08 and pre09 structure is liked by even less
folks.

Perhaps publishing -08 is the only option. My hope is that the WG will support
somebody subsequently doing solution (1), otherwise it seems like a missed
opportunity to get this right.

Thanks,
Rob


On 24/02/2018 13:54, Christian Hopps wrote:

My position,

It may be the case that there's even a better cleaner solution; however, it's
simply too late for major modifications to this work that don't actually
address functional failures. The draft as proposed works for the people who
need to get work done.

We have multiple pending RFCs - MISREF on this document. These RFCs would have
to be pulled from the RFC EDITOR queue, and reworked to be compliant again,
and this very well could lead to discovering issues with your new proposal.
Any new issues discovered in either the pending RFCs *or* in the new solution
would then need to be worked out and fixed. Please recall that this actually
occurred on the first round (i.e., doing the examples led to discovering
problems with the drafts), so it's not unreasonable at all to assume this
would happen again.

Look this just isn't a simple change your proposing. It involves a large
upheaval, killing the pending RFC status on multiple documents that the
industry is waiting on. Please see this.

Thanks,
Chris.


Martin Bjorklund  writes:


Hi,

Robert Wilton  wrote:

Hi Lou,

I think that this solution is inferior to the model presented in
pre-09.


I agree. Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both. With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can augment a single structure.



/martin




I would prefer that we publish pre09 instead, potentially including
the -08 model in the appendix if that helps progress the document in a
more expedient fashion.

Thanks,
Rob


On 22/02/2018 16:18, Lou Berger wrote:
> Hi,
>
> (I have a bunch of different roles WRT this work. This mail is being
> sent as an individual - as chair, I fully support the previous chair
> statements on this draft.)
>
> Chris and I have come up with a proposal on how to provide full NMDA
> as part the existing schema-mount module. 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Robert Wilton]

Hi Chris,

I've got no desire or intent to try and slow down the NI and LNE drafts, 
or any that depend on them.  I actually agree that this is critically 
important that IETF gets modules standardized/finished so that everyone 
can use them.


However, ...

YLbis has quite a different structure to YL.  The main part of this 
change was to support NMDA, the other part of this change was to better 
support things like SM, or YANG packages.


I don't think that there is a clean, backwards compatible, way to go 
from the YANG module in SM -08 to one that is going to work well with 
YLbis and other YLbis extensions/augmentations that seem to be coming 
down the line.  Given what we know now, I believe that the correct 
medium/long term structure for the SM YANG module, taking YLbis into 
account, is the one proposed in pre09, because it directly augments the 
YLbis structure, and hence any future augmentations to YLbis should 
automatically extend to SM mounted schema as well.


I think that the likely future technical issues with the -08 module will be:
- supporting NMDA in a clean consistent way
- adding in support for SemVer
- additional capability reporting as an augmentation to YANG library

So, if -08 proceeds as is, then it seems to me like one of three things 
will need to happen:
1) Their will need to be a non backwards compatible update to the SM 
model that is the same/similar to pre09.
2) YLbis and SM diverge, stuff that augments YLbis doesn't work for 
explicitly mounted schema.
3) We accrue technical debt, implementations need to support two YL 
module structures, the one in SM and the one in YLbis, and future 
extensions need to augment both the SM structure and YLbis structure.


I don't like the idea of (2) or (3), but I don't know if others will 
find (1) acceptable.


But I do agree that we are just going round in circles on this:
- Using the pre09 structure is not acceptable to some folks
- Publishing a draft with both -08 and pre09 structure is liked by even 
less folks.


Perhaps publishing -08 is the only option.  My hope is that the WG will 
support somebody subsequently doing solution (1), otherwise it seems 
like a missed opportunity to get this right.


Thanks,
Rob


On 24/02/2018 13:54, Christian Hopps wrote:

My position,

It may be the case that there's even a better cleaner solution; 
however, it's simply too late for major modifications to this work 
that don't actually address functional failures.  The draft as 
proposed works for the people who need to get work done.


We have multiple pending RFCs - MISREF on this document. These RFCs 
would have to be pulled from the RFC EDITOR queue, and reworked to be 
compliant again, and this very well could lead to discovering issues 
with your new proposal. Any new issues discovered in either the 
pending RFCs *or* in the new solution would then need to be worked out 
and fixed. Please recall that this actually occurred on the first 
round (i.e., doing the examples led to discovering problems with the 
drafts), so it's not unreasonable at all to assume this would happen 
again.


Look this just isn't a simple change your proposing. It involves a 
large upheaval, killing the pending RFC status on multiple documents 
that the industry is waiting on. Please see this.


Thanks,
Chris.


Martin Bjorklund  writes:


Hi,

Robert Wilton  wrote:

Hi Lou,

I think that this solution is inferior to the model presented in
pre-09.


I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can augment a single structure.



/martin




I would prefer that we publish pre09 instead, potentially including
the -08 model in the appendix if that helps progress the document in a
more expedient fashion.

Thanks,
Rob


On 22/02/2018 16:18, Lou Berger wrote:
> Hi,
>
> (I have a bunch of different roles WRT this work. This mail is being
> sent as an individual - as chair, I fully support the previous chair
> statements on this draft.)
>
> Chris and I have come up with a proposal on how to provide full NMDA
> as part the existing schema-mount module. Our motivation was to
> enable full NMDA support with *minimal* change to the model and
> disruption to the LC'ed work. The key NMDA limitation, with -08, that
> we are aiming to address is the ability to support different mounted
> schema in different datastores for non-inline mount points. (See more
> detailed description below if interested full nuances of limitations
> of -08)
>
> What we came up with was to simply add a (leaf)list to identify in
> which datastores a
> schema-mount schema is valid/present. This is 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Christian Hopps]

Juergen Schoenwaelder  writes:


On Sat, Feb 24, 2018 at 11:37:11AM -0500, Christian Hopps wrote:


Juergen Schoenwaelder  writes:
> - For the pre 09 'camp', it seems integration with YLbis is the key
>   technical requirement that is driving them.
>
> What is the key technical critical issue for the other camp?

We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage 
VPNs, VMs, etc, that are literally only blocked on this work being published 
(as written). To change this document in the proposed fashion invalidates the 
pending RFCs which would then need to be pulled from the publication queue and 
reworked along with the new proposed changes. The industry is waiting on and 
needs these RFCs to get work done. I do not think it's reasonable to ask the 
industry to now wait even longer to go back and rewrite what is already good 
enough and ready for publication and use.



If the change to schema mount (i.e., how schema information is
exposed) invalidates the normative parts of documents that define data
models that may exist under a mount point, then I think we got the
coupling between documents wrong.


It invalidates the examples for sure. But normative vs informative isn't the 
point. Doing the examples last time exposed issues with the design. There's no 
reason to think that won't occur here. The point is that people are justifying 
the proposed change by saying it's quick and non-disruptive, and that's simply 
*not* the case.

We have finished this work, and important stuff that the industry requires is 
waiting (one wonders how much longer though)

It's time to publish the good work we've done.


Anyway, if we can't find a solution that can work for everybody
involved, then we may be left with the only alternative to escalate
this further. My guess is that we will only loose time and we will all
look stupid at the end, hence I was hoping we could avoid this.


If by escalation you mean protests to hold up the work the industry needs 
during the IESG/IETF LC versus just doing the new work separately?

 Yeah, that'll make us look *really* competent to the industry too. 


One hopes that we don't end up with that nonsense.

Thanks,
Chris.



/js


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Juergen Schoenwaelder]

On Sat, Feb 24, 2018 at 11:37:11AM -0500, Christian Hopps wrote:
> 
> Juergen Schoenwaelder  writes:
> > - For the pre 09 'camp', it seems integration with YLbis is the key
> >   technical requirement that is driving them.
> > 
> > What is the key technical critical issue for the other camp?
> 
> We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage 
> VPNs, VMs, etc, that are literally only blocked on this work being published 
> (as written). To change this document in the proposed fashion invalidates the 
> pending RFCs which would then need to be pulled from the publication queue 
> and reworked along with the new proposed changes. The industry is waiting on 
> and needs these RFCs to get work done. I do not think it's reasonable to ask 
> the industry to now wait even longer to go back and rewrite what is already 
> good enough and ready for publication and use.
>

If the change to schema mount (i.e., how schema information is
exposed) invalidates the normative parts of documents that define data
models that may exist under a mount point, then I think we got the
coupling between documents wrong.

Anyway, if we can't find a solution that can work for everybody
involved, then we may be left with the only alternative to escalate
this further. My guess is that we will only loose time and we will all
look stupid at the end, hence I was hoping we could avoid this.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Christian Hopps]

Juergen Schoenwaelder  writes:

- For the pre 09 'camp', it seems integration with YLbis is the key
  technical requirement that is driving them.

What is the key technical critical issue for the other camp?


We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage 
VPNs, VMs, etc, that are literally only blocked on this work being published 
(as written). To change this document in the proposed fashion invalidates the 
pending RFCs which would then need to be pulled from the publication queue and 
reworked along with the new proposed changes. The industry is waiting on and 
needs these RFCs to get work done. I do not think it's reasonable to ask the 
industry to now wait even longer to go back and rewrite what is already good 
enough and ready for publication and use.

Thanks,
Chris.



/js


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Christian Hopps]

My position,

It may be the case that there's even a better cleaner solution; however, it's 
simply too late for major modifications to this work that don't actually 
address functional failures.  The draft as proposed works for the people who 
need to get work done.

We have multiple pending RFCs - MISREF on this document. These RFCs would have 
to be pulled from the RFC EDITOR queue, and reworked to be compliant again, and 
this very well could lead to discovering issues with your new proposal. Any new 
issues discovered in either the pending RFCs *or* in the new solution would 
then need to be worked out and fixed. Please recall that this actually occurred 
on the first round (i.e., doing the examples led to discovering problems with 
the drafts), so it's not unreasonable at all to assume this would happen again.

Look this just isn't a simple change your proposing. It involves a large 
upheaval, killing the pending RFC status on multiple documents that the 
industry is waiting on. Please see this.

Thanks,
Chris.


Martin Bjorklund  writes:


Hi,

Robert Wilton  wrote:

Hi Lou,

I think that this solution is inferior to the model presented in
pre-09.


I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can augment a single structure.



/martin




I would prefer that we publish pre09 instead, potentially including
the -08 model in the appendix if that helps progress the document in a
more expedient fashion.

Thanks,
Rob


On 22/02/2018 16:18, Lou Berger wrote:
> Hi,
>
> (I have a bunch of different roles WRT this work. This mail is being
> sent as an individual - as chair, I fully support the previous chair
> statements on this draft.)
>
> Chris and I have come up with a proposal on how to provide full NMDA
> as part the existing schema-mount module. Our motivation was to
> enable full NMDA support with *minimal* change to the model and
> disruption to the LC'ed work. The key NMDA limitation, with -08, that
> we are aiming to address is the ability to support different mounted
> schema in different datastores for non-inline mount points. (See more
> detailed description below if interested full nuances of limitations
> of -08)
>
> What we came up with was to simply add a (leaf)list to identify in
> which datastores a
> schema-mount schema is valid/present. This is somewhat similar to
> YL-bis schema/module-set. Specifically we're proposing (see below for
> full tree below):
>
>  +--ro schema* [name]
>  +--ro name string
> ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>
> This approach has the advantages of supporting different mounted
> schema in different DSes, working with both NMDA and non-NMDA
> implementations, supporting all of the extensively discussed features
> of schema mount (including recursive mounts), and having minor/scoped
> impact on all dependent work. The main downside is that it isn't the
> most optimal/compact solution possible if we were to base this work on
> YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
> perspectives, but it is what was agreed to as sufficient by those who
> contribute to the WG discussion.
>
> In short, we see this as a solution to addresses the raised last call
> issue with the minimal impact on -08 and dependent work -- which is
> what is appropriate given where we are in the process.
>
> So our/my question really is:
>
>  Is this a solution that you/all can live with?
>
> Note: optimization, design preference and perfect alignment with use
> or YL-bis are not part of our question as we both don't think that is
> the right question given where we are in the WG process.
>
> Lou (with ideas developed with Chris, and chair hat off)
>
> ==
> Details -- for those who want
> ==
> As background, my understanding/view is that the -08 version of the
> both NMDA and non-NMDA supporting implementations, but there are
> limitations in its NMDA applicability. Used with Yang Library,
> [rfc7895], only non-NMDA implementations can be supported. When used
> with the revised Yang Library defined in
> [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
> supported with certain limitations. Specifically, this document
> requires use of the now deprecated module-list grouping, and the same
> schema represented in schema list of the Schema Mount module MUST be
> used in all datastores. Inline type mount points, which don't use the
> schema list, can support different schema in different data stores
> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
> YANG library under the inline mount point.
>
>  module: 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Juergen Schoenwaelder]

On Fri, Feb 23, 2018 at 09:36:50AM -0500, Lou Berger wrote:
> Rob,
> 
> I think we're going in circles here. We have one camp that wants to replace
> the current module with pre 09 and is unwilling to discuss compromise, and
> another camp that wants 08 published as is and has been waiting for the
> working group and authors to submit aversion to the IESG for publication
> based on the last call that completed in November.

It seems the group in favor of pre 09 is in favor of it because the
solution integrates with YLbis, i.e., _one_ way to represent schema
information.

> The mail I sent that started this thread was sent with the hope of finding a
> compromise. As you and Martin seem uninterested in discussing a compromise,
> I not sure if it's worth pursuing this thread. If I have misread your mails,
> and you are open to compromise then we should continue this thread.

I assume the group in favor of pre 09 finds it difficult to
'compromise' on something that does not provide the benefit of
integrating with YLbis.
 
> If not and there is no interest in finding a compromise in the working group
> and by the authors, I guess we're back to the plan of publishing 08 and
> looking forward to protests.

To investigate the possibility of a compromise, we need to understand
what both groups find unacceptable and where there is room for finding
common grounds.

- For the pre 09 'camp', it seems integration with YLbis is the key
  technical requirement that is driving them.

What is the key technical critical issue for the other camp?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Lou Berger]

Rob,

    My/our proposal doesn't seem to help unblock the current impasse,  
as such I'll drop it and move on.


Thanks,

Lou

On 2/23/2018 9:52 AM, Robert Wilton wrote:

Hi Lou,

As per my public emails on this WG alias, and also private emails, you
must know that both Martin, I, and others have been trying (for many
weeks) to reach a compromise.

I don't think that it is that I am unwilling to compromise, but more
that I perceive that a different compromise solution is the right one.
I.e. we publish a single draft that contains the model that you want now
for pre NMDA solutions, and also a model that we think will work well in
the post NMDA world that all of the IETF YANG models are moving to.

Thanks,
Rob


On 23/02/2018 14:36, Lou Berger wrote:

Rob,

I think we're going in circles here. We have one camp that wants to
replace the current module with pre 09 and is unwilling to discuss
compromise, and another camp that wants 08 published as is and has
been waiting for the working group and authors to submit aversion to
the IESG for publication based on the last call that completed in
November.

The mail I sent that started this thread was sent with the hope of
finding a compromise. As you and Martin seem uninterested in
discussing a compromise, I not sure if it's worth pursuing this
thread. If I have misread your mails, and you are open to compromise
then we should continue this thread.

If not and there is no interest in finding a compromise in the working
group and by the authors, I guess we're back to the plan of publishing
08 and looking forward to protests.

Lou



.





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Ladislav Lhotka]

Robert Wilton  writes:

> Hi Lou,
>
> I think that this solution is inferior to the model presented in
> pre-09.

If the choice is between pre-09 and Lou's new proposal, then I strongly
prefer pre-09.

That said, I must also add that I am still not happy with pre-09: I
believe the "schema-ref" choice is an unnecessary complication - the
"inline" mounts needn't interact at all with the YANG library of the
parent tree.

>
> I would prefer that we publish pre09 instead, potentially including the 
> -08 model in the appendix if that helps progress the document in a more 
> expedient fashion.

I don't agree with including such an appendix, it would only confuse the
readers.

Lada

>
> Thanks,
> Rob
>
>
> On 22/02/2018 16:18, Lou Berger wrote:
>> Hi,
>>
>> (I have a bunch of different roles WRT this work.  This mail is being 
>> sent as an individual - as chair, I fully support the previous chair 
>> statements on this draft.)
>>
>> Chris and I have come up with a proposal on how to provide full NMDA 
>> as part the existing schema-mount module.  Our motivation was to 
>> enable full NMDA support with *minimal* change to the model and 
>> disruption to the LC'ed work.  The key NMDA limitation, with -08, that 
>> we are aiming to address is the ability to support different mounted 
>> schema in different datastores for non-inline mount points. (See more 
>> detailed description below if interested full nuances of limitations 
>> of -08)
>>
>> What we came up with was  to simply add a (leaf)list to identify in 
>> which datastores a
>> schema-mount schema is valid/present. This is somewhat similar to 
>> YL-bis schema/module-set. Specifically we're proposing (see below for 
>> full tree below):
>>
>>    +--ro schema* [name]
>>   +--ro name   string
>> ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}
>>
>> This approach has the advantages of supporting different mounted 
>> schema in different DSes, working with both NMDA and non-NMDA 
>> implementations, supporting all of the extensively discussed features 
>> of schema mount (including recursive mounts), and having minor/scoped 
>> impact on all dependent work.  The main downside is that it isn't the 
>> most optimal/compact solution possible if we were to base this work on 
>> YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all 
>> perspectives, but it is what was agreed to as sufficient by those who 
>> contribute to the WG discussion.
>>
>> In short, we see this as a solution to  addresses the raised last call 
>> issue with the minimal impact on -08 and dependent work -- which is 
>> what is appropriate given where we are in the process.
>>
>> So our/my question really is:
>>
>>     Is this a solution that you/all can live with?
>>
>> Note: optimization, design preference and perfect alignment with use 
>> or YL-bis are not part of our question as we both don't think that is 
>> the right question given where we are in the WG process.
>>
>> Lou (with ideas developed with Chris, and chair hat off)
>>
>> ==
>> Details -- for those who want
>> ==
>> As background, my understanding/view is that the -08 version of the 
>> both NMDA and non-NMDA supporting implementations, but there are 
>> limitations in its NMDA applicability. Used with Yang Library, 
>> [rfc7895], only non-NMDA implementations can be supported.  When used 
>> with the revised Yang Library defined in 
>> [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be 
>> supported with certain limitations. Specifically, this document 
>> requires use of the now deprecated module-list grouping, and the same 
>> schema represented in schema list of the Schema Mount module MUST be 
>> used in all datastores.  Inline type mount points, which don't use the 
>> schema list,  can support different schema in different data stores 
>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of 
>> YANG library under the inline mount point.
>>
>>     module: ietf-yang-schema-mount
>>     +--ro schema-mounts
>>    +--ro namespace* [prefix]
>>    |  +--ro prefix    yang:yang-identifier
>>    |  +--ro uri?  inet:uri
>>    +--ro mount-point* [module name]
>>    |  +--ro module    yang:yang-identifier
>>    |  +--ro name  yang:yang-identifier
>>    |  +--ro config?   boolean
>>    |  +--ro (schema-ref)?
>>    | +--:(inline)
>>    | |  +--ro inline?   empty
>>    | +--:(use-schema)
>>    |    +--ro use-schema* [name]
>>    |   +--ro name
>>    |   |   -> /schema-mounts/schema/name
>>    |   +--ro parent-reference*   yang:xpath1.0
>>    +--ro schema* [name]
>>   +--ro name   string
>> ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}
>>       +--ro module* [name 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Robert Wilton]

Hi Lou,

As per my public emails on this WG alias, and also private emails, you 
must know that both Martin, I, and others have been trying (for many 
weeks) to reach a compromise.


I don't think that it is that I am unwilling to compromise, but more 
that I perceive that a different compromise solution is the right one.  
I.e. we publish a single draft that contains the model that you want now 
for pre NMDA solutions, and also a model that we think will work well in 
the post NMDA world that all of the IETF YANG models are moving to.


Thanks,
Rob


On 23/02/2018 14:36, Lou Berger wrote:

Rob,

I think we're going in circles here. We have one camp that wants to 
replace the current module with pre 09 and is unwilling to discuss 
compromise, and another camp that wants 08 published as is and has 
been waiting for the working group and authors to submit aversion to 
the IESG for publication based on the last call that completed in 
November.


The mail I sent that started this thread was sent with the hope of 
finding a compromise. As you and Martin seem uninterested in 
discussing a compromise, I not sure if it's worth pursuing this 
thread. If I have misread your mails, and you are open to compromise 
then we should continue this thread.


If not and there is no interest in finding a compromise in the working 
group and by the authors, I guess we're back to the plan of publishing 
08 and looking forward to protests.


Lou



.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Lou Berger]

Rob,

I think we're going in circles here. We have one camp that wants to replace 
the current module with pre 09 and is unwilling to discuss compromise, and 
another camp that wants 08 published as is and has been waiting for the 
working group and authors to submit aversion to the IESG for publication 
based on the last call that completed in November.


The mail I sent that started this thread was sent with the hope of finding 
a compromise. As you and Martin seem uninterested in discussing a 
compromise, I not sure if it's worth pursuing this thread. If I have 
misread your mails, and you are open to compromise then we should continue 
this thread.


If not and there is no interest in finding a compromise in the working 
group and by the authors, I guess we're back to the plan of publishing 08 
and looking forward to protests.


Lou



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Robert Wilton]

Hi Lou,

I also don't agree that this is a rewrite of the draft.  My view is that 
it is really just an obvious simplification of the YANG module given the 
YLbis work.


For the use-schema version, the -08 version splits the *same* YANG 
library information into two separate places depending on whether it is 
mounted at the root, or below.  The PRE-09 version says that a root 
schema and a mounted schema are really the same thing and should be 
handled in exactly the same way.



On 23/02/2018 13:18, Lou Berger wrote:

Martin,


On 2/23/2018 7:55 AM, Martin Bjorklund wrote:

Hi,

Lou Berger  wrote:

Martin/Rob,

 Back when the topic was raised for the first time publicly
(Yokahama) and discussed in the WG [1] *any* solution would have been
workable.  At this point > 2 years later, do you really think it is
reasonable to do a rewrite of the solution ?

I don't agree that this is a rewrite of the solution.  I want to keep
the mountpoint statement.  I want to keep the two mechanisms inline
and use-schema.  The only change we're talking about is alinging the
read-only data that the server makes available with YLbis.
The requirement to use YL-bis is enough for me classifying the change 
as a rewrite.  The current draft is usable with both RFC7895 and 
YL-bis.  This is a pretty major change, particularly for anyone 
working on a client or server implementation now, or who wants to soon.
If semantic versioning, or other stuff (e.g. server/datastore 
capabilities) gets augmented into YLbis then that should just work with 
the pre-09 version, with no further changes.  This will not necessarily 
be the case with the -08 version because it will be using deprecated 
groupings, those deprecated groupings would need to be updated or it 
would force a new version of the SM YANG module.


To support pre NMDA implementations, I see that the solution should be 
the same as all other current YANG model drafts, i.e. if necessary, we 
publish a pre NMDA version of the YANG module in the appendix that works 
with existing implementations.  In this case I would use the model in 
the -08 version, put them both in different namespaces and label them 
clearly.





  This is
quite trivial.
From *your* perspective.  There are other's that disagree (See Dean's 
and Chris' mail - they don't want *any* changes and are perfectly 
happy with -08).



  We have documented this in the pre09 branch, and this
is imo ready to be published.
It would still need to go through normal working processing which 
would, hopefully, garner some review from some/any of the users or 
operator who contributed to the development of -08.   For example, in 
PRE09 I see some complexities in how mount points with different 
schema in different DS works that seem unnecessary, also the recursive 
case is not documented - even if I'm wrong and all that is needed is 
better understanding (by me) or clarification (in the doc),  it still 
would need to addressed as part of normal WG processing.
Please can you elaborate, or provide an example of the perceived 
different schema in different datastore complexity.


For the recursive mount case, Juergen has previously posted a useful 
diagram that shows how the -09 model fits with YLbis, that I think would 
be a useful addition.


Perhaps a second WG LC would be sufficient?



Lou




Are you really not
willing to live with a compromise that addresses the issue albeit in
way that you/some view as suboptimal?
I think that the YLbis based version is significantly simpler than what 
you/Chris proposed.  If we can't ship a YLbis version now then I prefer 
that the -08 version has no support for NMDA based servers and we 
immediately start SMbis using the YLbis version (i.e. not backwards 
compatible).


I also think that longer term schema mount will end up with a lot more 
usage, which is why I want the -09 model published.


Thanks,
Rob




Keep in mind that we had lots of discussions on what is
optimal/preferred and there are/were different view points on this,
compromises were made that increased complexity for others and these
were accepted in interest of progressing *any* deployable solution.

Yes.  I don't want to give up these compromises.  I know that others
want to, and/or explore other solutions.  That's *not* what I'm
proposing.


/martin




Lou

[1]
https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod 



On 2/23/2018 4:36 AM, Martin Bjorklund wrote:

Hi,

Robert Wilton  wrote:

Hi Lou,

I think that this solution is inferior to the model presented in
pre-09.

I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Lou Berger]

Martin,


On 2/23/2018 7:55 AM, Martin Bjorklund wrote:

Hi,

Lou Berger  wrote:

Martin/Rob,

     Back when the topic was raised for the first time publicly
(Yokahama) and discussed in the WG [1] *any* solution would have been
workable.  At this point > 2 years later, do you really think it is
reasonable to do a rewrite of the solution ?

I don't agree that this is a rewrite of the solution.  I want to keep
the mountpoint statement.  I want to keep the two mechanisms inline
and use-schema.  The only change we're talking about is alinging the
read-only data that the server makes available with YLbis.
The requirement to use YL-bis is enough for me classifying the change as 
a rewrite.  The current draft is usable with both RFC7895 and YL-bis.  
This is a pretty major change, particularly for anyone working on a 
client or server implementation now, or who wants to soon.



  This is
quite trivial.
From *your* perspective.  There are other's that disagree (See Dean's 
and Chris' mail - they don't want *any* changes and are perfectly happy 
with -08).



  We have documented this in the pre09 branch, and this
is imo ready to be published.
It would still need to go through normal working processing which would, 
hopefully, garner some review from some/any of the users or operator who 
contributed to the development of -08.   For example, in PRE09 I see 
some complexities in how mount points with different schema in different 
DS works that seem unnecessary,  also the recursive case is not 
documented - even if I'm wrong and all that is needed is better 
understanding (by me) or clarification (in the doc),  it still would 
need to addressed as part of normal WG processing.


Lou




Are you really not
willing to live with a compromise that addresses the issue albeit in
way that you/some view as suboptimal?

Keep in mind that we had lots of discussions on what is
optimal/preferred and there are/were different view points on this,
compromises were made that increased complexity for others and these
were accepted in interest of progressing *any* deployable solution.

Yes.  I don't want to give up these compromises.  I know that others
want to, and/or explore other solutions.  That's *not* what I'm
proposing.


/martin




Lou

[1]
https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod

On 2/23/2018 4:36 AM, Martin Bjorklund wrote:

Hi,

Robert Wilton  wrote:

Hi Lou,

I think that this solution is inferior to the model presented in
pre-09.

I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can augment a single structure.


/martin




I would prefer that we publish pre09 instead, potentially including
the -08 model in the appendix if that helps progress the document in a
more expedient fashion.

Thanks,
Rob


On 22/02/2018 16:18, Lou Berger wrote:

Hi,

(I have a bunch of different roles WRT this work.  This mail is being
sent as an individual - as chair, I fully support the previous chair
statements on this draft.)

Chris and I have come up with a proposal on how to provide full NMDA
as part the existing schema-mount module.  Our motivation was to
enable full NMDA support with *minimal* change to the model and
disruption to the LC'ed work.  The key NMDA limitation, with -08, that
we are aiming to address is the ability to support different mounted
schema in different datastores for non-inline mount points. (See more
detailed description below if interested full nuances of limitations
of -08)

What we came up with was  to simply add a (leaf)list to identify in
which datastores a
schema-mount schema is valid/present. This is somewhat similar to
YL-bis schema/module-set. Specifically we're proposing (see below for
full tree below):

     +--ro schema* [name]
    +--ro name   string
ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}

This approach has the advantages of supporting different mounted
schema in different DSes, working with both NMDA and non-NMDA
implementations, supporting all of the extensively discussed features
of schema mount (including recursive mounts), and having minor/scoped
impact on all dependent work.  The main downside is that it isn't the
most optimal/compact solution possible if we were to base this work on
YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all
perspectives, but it is what was agreed to as sufficient by those who
contribute to the WG discussion.

In short, we see this as a solution to  addresses the raised last call
issue with the minimal impact on -08 and dependent work -- which is
what is 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Martin Bjorklund]

Hi,

Lou Berger  wrote:
> Martin/Rob,
> 
>     Back when the topic was raised for the first time publicly
> (Yokahama) and discussed in the WG [1] *any* solution would have been
> workable.  At this point > 2 years later, do you really think it is
> reasonable to do a rewrite of the solution ?

I don't agree that this is a rewrite of the solution.  I want to keep
the mountpoint statement.  I want to keep the two mechanisms inline
and use-schema.  The only change we're talking about is alinging the
read-only data that the server makes available with YLbis.  This is
quite trivial.  We have documented this in the pre09 branch, and this
is imo ready to be published.

> Are you really not
> willing to live with a compromise that addresses the issue albeit in
> way that you/some view as suboptimal?
> 
> Keep in mind that we had lots of discussions on what is
> optimal/preferred and there are/were different view points on this,
> compromises were made that increased complexity for others and these
> were accepted in interest of progressing *any* deployable solution.

Yes.  I don't want to give up these compromises.  I know that others
want to, and/or explore other solutions.  That's *not* what I'm
proposing.


/martin



> 
> Lou
> 
> [1]
> https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod
> 
> On 2/23/2018 4:36 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > Robert Wilton  wrote:
> >> Hi Lou,
> >>
> >> I think that this solution is inferior to the model presented in
> >> pre-09.
> > I agree.  Servers that are NMDA-compliant, or implements YANG Library
> > bis will have to present schemas in two different structures,
> > depending on where the schema is used, and clients will have to code
> > for both.  With the solution in pre-09, there is just one structure.
> > A single structure also has other benefits (apart from being simpler),
> > e.g., if we augment it with the meta data that has been discussed
> > recently, we can augment a single structure.
> >
> >
> > /martin
> >
> >
> >
> >> I would prefer that we publish pre09 instead, potentially including
> >> the -08 model in the appendix if that helps progress the document in a
> >> more expedient fashion.
> >>
> >> Thanks,
> >> Rob
> >>
> >>
> >> On 22/02/2018 16:18, Lou Berger wrote:
> >>> Hi,
> >>>
> >>> (I have a bunch of different roles WRT this work.  This mail is being
> >>> sent as an individual - as chair, I fully support the previous chair
> >>> statements on this draft.)
> >>>
> >>> Chris and I have come up with a proposal on how to provide full NMDA
> >>> as part the existing schema-mount module.  Our motivation was to
> >>> enable full NMDA support with *minimal* change to the model and
> >>> disruption to the LC'ed work.  The key NMDA limitation, with -08, that
> >>> we are aiming to address is the ability to support different mounted
> >>> schema in different datastores for non-inline mount points. (See more
> >>> detailed description below if interested full nuances of limitations
> >>> of -08)
> >>>
> >>> What we came up with was  to simply add a (leaf)list to identify in
> >>> which datastores a
> >>> schema-mount schema is valid/present. This is somewhat similar to
> >>> YL-bis schema/module-set. Specifically we're proposing (see below for
> >>> full tree below):
> >>>
> >>>     +--ro schema* [name]
> >>>    +--ro name   string
> >>> ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}
> >>>
> >>> This approach has the advantages of supporting different mounted
> >>> schema in different DSes, working with both NMDA and non-NMDA
> >>> implementations, supporting all of the extensively discussed features
> >>> of schema mount (including recursive mounts), and having minor/scoped
> >>> impact on all dependent work.  The main downside is that it isn't the
> >>> most optimal/compact solution possible if we were to base this work on
> >>> YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all
> >>> perspectives, but it is what was agreed to as sufficient by those who
> >>> contribute to the WG discussion.
> >>>
> >>> In short, we see this as a solution to  addresses the raised last call
> >>> issue with the minimal impact on -08 and dependent work -- which is
> >>> what is appropriate given where we are in the process.
> >>>
> >>> So our/my question really is:
> >>>
> >>>      Is this a solution that you/all can live with?
> >>>
> >>> Note: optimization, design preference and perfect alignment with use
> >>> or YL-bis are not part of our question as we both don't think that is
> >>> the right question given where we are in the WG process.
> >>>
> >>> Lou (with ideas developed with Chris, and chair hat off)
> >>>
> >>> ==
> >>> Details -- for those who want
> >>> ==
> >>> As background, my understanding/view is that the -08 version of the
> >>> both NMDA and non-NMDA supporting implementations, but there are
> >>> limitations 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Lou Berger]

Martin/Rob,

    Back when the topic was raised for the first time publicly 
(Yokahama) and discussed in the WG [1] *any* solution would have been 
workable.  At this point > 2 years later, do you really think it is 
reasonable to do a rewrite of the solution ?  Are you really not willing 
to live with a compromise that addresses the issue albeit in way that 
you/some view as suboptimal?


Keep in mind that we had lots of discussions on what is 
optimal/preferred and there are/were different view points on this, 
compromises were made that increased complexity for others and these 
were accepted in interest of progressing *any* deployable solution.


Lou

[1] 
https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod


On 2/23/2018 4:36 AM, Martin Bjorklund wrote:

Hi,

Robert Wilton  wrote:

Hi Lou,

I think that this solution is inferior to the model presented in
pre-09.

I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can augment a single structure.


/martin




I would prefer that we publish pre09 instead, potentially including
the -08 model in the appendix if that helps progress the document in a
more expedient fashion.

Thanks,
Rob


On 22/02/2018 16:18, Lou Berger wrote:

Hi,

(I have a bunch of different roles WRT this work.  This mail is being
sent as an individual - as chair, I fully support the previous chair
statements on this draft.)

Chris and I have come up with a proposal on how to provide full NMDA
as part the existing schema-mount module.  Our motivation was to
enable full NMDA support with *minimal* change to the model and
disruption to the LC'ed work.  The key NMDA limitation, with -08, that
we are aiming to address is the ability to support different mounted
schema in different datastores for non-inline mount points. (See more
detailed description below if interested full nuances of limitations
of -08)

What we came up with was  to simply add a (leaf)list to identify in
which datastores a
schema-mount schema is valid/present. This is somewhat similar to
YL-bis schema/module-set. Specifically we're proposing (see below for
full tree below):

    +--ro schema* [name]
   +--ro name   string
ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}

This approach has the advantages of supporting different mounted
schema in different DSes, working with both NMDA and non-NMDA
implementations, supporting all of the extensively discussed features
of schema mount (including recursive mounts), and having minor/scoped
impact on all dependent work.  The main downside is that it isn't the
most optimal/compact solution possible if we were to base this work on
YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all
perspectives, but it is what was agreed to as sufficient by those who
contribute to the WG discussion.

In short, we see this as a solution to  addresses the raised last call
issue with the minimal impact on -08 and dependent work -- which is
what is appropriate given where we are in the process.

So our/my question really is:

     Is this a solution that you/all can live with?

Note: optimization, design preference and perfect alignment with use
or YL-bis are not part of our question as we both don't think that is
the right question given where we are in the WG process.

Lou (with ideas developed with Chris, and chair hat off)

==
Details -- for those who want
==
As background, my understanding/view is that the -08 version of the
both NMDA and non-NMDA supporting implementations, but there are
limitations in its NMDA applicability. Used with Yang Library,
[rfc7895], only non-NMDA implementations can be supported.  When used
with the revised Yang Library defined in
[I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be
supported with certain limitations. Specifically, this document
requires use of the now deprecated module-list grouping, and the same
schema represented in schema list of the Schema Mount module MUST be
used in all datastores.  Inline type mount points, which don't use the
schema list,  can support different schema in different data stores
not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
YANG library under the inline mount point.

     module: ietf-yang-schema-mount
     +--ro schema-mounts
    +--ro namespace* [prefix]
    |  +--ro prefix    yang:yang-identifier
    |  +--ro uri?  inet:uri
    +--ro mount-point* [module name]
    |  +--ro module    yang:yang-identifier
    |  +--ro name  yang:yang-identifier
 

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Martin Bjorklund]

Hi,

Robert Wilton  wrote:
> Hi Lou,
> 
> I think that this solution is inferior to the model presented in
> pre-09.

I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can augment a single structure.


/martin



> I would prefer that we publish pre09 instead, potentially including
> the -08 model in the appendix if that helps progress the document in a
> more expedient fashion.
> 
> Thanks,
> Rob
> 
> 
> On 22/02/2018 16:18, Lou Berger wrote:
> > Hi,
> >
> > (I have a bunch of different roles WRT this work.  This mail is being
> > sent as an individual - as chair, I fully support the previous chair
> > statements on this draft.)
> >
> > Chris and I have come up with a proposal on how to provide full NMDA
> > as part the existing schema-mount module.  Our motivation was to
> > enable full NMDA support with *minimal* change to the model and
> > disruption to the LC'ed work.  The key NMDA limitation, with -08, that
> > we are aiming to address is the ability to support different mounted
> > schema in different datastores for non-inline mount points. (See more
> > detailed description below if interested full nuances of limitations
> > of -08)
> >
> > What we came up with was  to simply add a (leaf)list to identify in
> > which datastores a
> > schema-mount schema is valid/present. This is somewhat similar to
> > YL-bis schema/module-set. Specifically we're proposing (see below for
> > full tree below):
> >
> >    +--ro schema* [name]
> >   +--ro name   string
> > ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}
> >
> > This approach has the advantages of supporting different mounted
> > schema in different DSes, working with both NMDA and non-NMDA
> > implementations, supporting all of the extensively discussed features
> > of schema mount (including recursive mounts), and having minor/scoped
> > impact on all dependent work.  The main downside is that it isn't the
> > most optimal/compact solution possible if we were to base this work on
> > YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all
> > perspectives, but it is what was agreed to as sufficient by those who
> > contribute to the WG discussion.
> >
> > In short, we see this as a solution to  addresses the raised last call
> > issue with the minimal impact on -08 and dependent work -- which is
> > what is appropriate given where we are in the process.
> >
> > So our/my question really is:
> >
> >     Is this a solution that you/all can live with?
> >
> > Note: optimization, design preference and perfect alignment with use
> > or YL-bis are not part of our question as we both don't think that is
> > the right question given where we are in the WG process.
> >
> > Lou (with ideas developed with Chris, and chair hat off)
> >
> > ==
> > Details -- for those who want
> > ==
> > As background, my understanding/view is that the -08 version of the
> > both NMDA and non-NMDA supporting implementations, but there are
> > limitations in its NMDA applicability. Used with Yang Library,
> > [rfc7895], only non-NMDA implementations can be supported.  When used
> > with the revised Yang Library defined in
> > [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be
> > supported with certain limitations. Specifically, this document
> > requires use of the now deprecated module-list grouping, and the same
> > schema represented in schema list of the Schema Mount module MUST be
> > used in all datastores.  Inline type mount points, which don't use the
> > schema list,  can support different schema in different data stores
> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
> > YANG library under the inline mount point.
> >
> >     module: ietf-yang-schema-mount
> >     +--ro schema-mounts
> >    +--ro namespace* [prefix]
> >    |  +--ro prefix    yang:yang-identifier
> >    |  +--ro uri?  inet:uri
> >    +--ro mount-point* [module name]
> >    |  +--ro module    yang:yang-identifier
> >    |  +--ro name  yang:yang-identifier
> >    |  +--ro config?   boolean
> >    |  +--ro (schema-ref)?
> >    | +--:(inline)
> >    | |  +--ro inline?   empty
> >    | +--:(use-schema)
> >    |    +--ro use-schema* [name]
> >    |   +--ro name
> >    |   |   -> /schema-mounts/schema/name
> >    |   +--ro parent-reference*   yang:xpath1.0
> >    +--ro schema* [name]
> >   +--ro name   string

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Robert Wilton]

Hi Lou,

I think that this solution is inferior to the model presented in pre-09.

I would prefer that we publish pre09 instead, potentially including the 
-08 model in the appendix if that helps progress the document in a more 
expedient fashion.


Thanks,
Rob


On 22/02/2018 16:18, Lou Berger wrote:

Hi,

(I have a bunch of different roles WRT this work.  This mail is being 
sent as an individual - as chair, I fully support the previous chair 
statements on this draft.)


Chris and I have come up with a proposal on how to provide full NMDA 
as part the existing schema-mount module.  Our motivation was to 
enable full NMDA support with *minimal* change to the model and 
disruption to the LC'ed work.  The key NMDA limitation, with -08, that 
we are aiming to address is the ability to support different mounted 
schema in different datastores for non-inline mount points. (See more 
detailed description below if interested full nuances of limitations 
of -08)


What we came up with was  to simply add a (leaf)list to identify in 
which datastores a
schema-mount schema is valid/present. This is somewhat similar to 
YL-bis schema/module-set. Specifically we're proposing (see below for 
full tree below):


   +--ro schema* [name]
  +--ro name   string
ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}

This approach has the advantages of supporting different mounted 
schema in different DSes, working with both NMDA and non-NMDA 
implementations, supporting all of the extensively discussed features 
of schema mount (including recursive mounts), and having minor/scoped 
impact on all dependent work.  The main downside is that it isn't the 
most optimal/compact solution possible if we were to base this work on 
YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all 
perspectives, but it is what was agreed to as sufficient by those who 
contribute to the WG discussion.


In short, we see this as a solution to  addresses the raised last call 
issue with the minimal impact on -08 and dependent work -- which is 
what is appropriate given where we are in the process.


So our/my question really is:

    Is this a solution that you/all can live with?

Note: optimization, design preference and perfect alignment with use 
or YL-bis are not part of our question as we both don't think that is 
the right question given where we are in the WG process.


Lou (with ideas developed with Chris, and chair hat off)

==
Details -- for those who want
==
As background, my understanding/view is that the -08 version of the 
both NMDA and non-NMDA supporting implementations, but there are 
limitations in its NMDA applicability. Used with Yang Library, 
[rfc7895], only non-NMDA implementations can be supported.  When used 
with the revised Yang Library defined in 
[I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be 
supported with certain limitations. Specifically, this document 
requires use of the now deprecated module-list grouping, and the same 
schema represented in schema list of the Schema Mount module MUST be 
used in all datastores.  Inline type mount points, which don't use the 
schema list,  can support different schema in different data stores 
not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of 
YANG library under the inline mount point.


    module: ietf-yang-schema-mount
    +--ro schema-mounts
   +--ro namespace* [prefix]
   |  +--ro prefix    yang:yang-identifier
   |  +--ro uri?  inet:uri
   +--ro mount-point* [module name]
   |  +--ro module    yang:yang-identifier
   |  +--ro name  yang:yang-identifier
   |  +--ro config?   boolean
   |  +--ro (schema-ref)?
   | +--:(inline)
   | |  +--ro inline?   empty
   | +--:(use-schema)
   |    +--ro use-schema* [name]
   |   +--ro name
   |   |   -> /schema-mounts/schema/name
   |   +--ro parent-reference*   yang:xpath1.0
   +--ro schema* [name]
  +--ro name   string
ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}
      +--ro module* [name revision]
  |  +--ro name    yang:yang-identifier
  |  +--ro revision    union
  |  +--ro schema? inet:uri
  |  +--ro namespace   inet:uri
  |  +--ro feature*    yang:yang-identifier
  |  +--ro deviation* [name revision]
  |  |  +--ro name    yang:yang-identifier
  |  |  +--ro revision    union
  |  +--ro conformance-type    enumeration
  |  +--ro submodule* [name revision]
  | +--ro name    yang:yang-identifier
  | +--ro revision    union
  | +--ro schema? inet:uri
 

[netmod] Proposal for minimalist full NMDA support in schema mount

[Lou Berger]

Hi,

(I have a bunch of different roles WRT this work.  This mail is being 
sent as an individual - as chair, I fully support the previous chair 
statements on this draft.)


Chris and I have come up with a proposal on how to provide full NMDA as 
part the existing schema-mount module.  Our motivation was to enable 
full NMDA support with *minimal* change to the model and disruption to 
the LC'ed work.  The key NMDA limitation, with -08, that we are aiming 
to address is the ability to support different mounted schema in 
different datastores for non-inline mount points. (See more detailed 
description below if interested full nuances of limitations of -08)


What we came up with was  to simply add a (leaf)list to identify in 
which datastores a
schema-mount schema is valid/present. This is somewhat similar to YL-bis 
schema/module-set. Specifically we're proposing (see below for full tree 
below):


   +--ro schema* [name]
  +--ro name   string
ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}

This approach has the advantages of supporting different mounted schema 
in different DSes, working with both NMDA and non-NMDA implementations, 
supporting all of the extensively discussed features of schema mount 
(including recursive mounts), and having minor/scoped impact on all 
dependent work.  The main downside is that it isn't the most 
optimal/compact solution possible if we were to base this work on 
YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all 
perspectives, but it is what was agreed to as sufficient by those who 
contribute to the WG discussion.


In short, we see this as a solution to  addresses the raised last call 
issue with the minimal impact on -08 and dependent work -- which is what 
is appropriate given where we are in the process.


So our/my question really is:

    Is this a solution that you/all can live with?

Note: optimization, design preference and perfect alignment with use or 
YL-bis are not part of our question as we both don't think that is the 
right question given where we are in the WG process.


Lou (with ideas developed with Chris, and chair hat off)

==
Details -- for those who want
==
As background, my understanding/view is that the -08 version of the both 
NMDA and non-NMDA supporting implementations, but there are limitations 
in its NMDA applicability. Used with Yang Library, [rfc7895], only 
non-NMDA implementations can be supported.  When used with the revised 
Yang Library defined in [I.D.ietf-netconf-rfc7895bis-],  NMDA 
implementations  can be supported with certain limitations. 
Specifically, this document requires use of the now deprecated 
module-list grouping, and the same schema represented in schema list of 
the Schema Mount module MUST be used in all datastores.  Inline type 
mount points, which don't use the schema list,  can support different 
schema in different data stores not by instantiating the 
[I.D.ietf-netconf-rfc7895bis-] version of YANG library under the inline 
mount point.


module: ietf-yang-schema-mount
+--ro schema-mounts
   +--ro namespace* [prefix]
   |  +--ro prefixyang:yang-identifier
   |  +--ro uri?  inet:uri
   +--ro mount-point* [module name]
   |  +--ro moduleyang:yang-identifier
   |  +--ro name  yang:yang-identifier
   |  +--ro config?   boolean
   |  +--ro (schema-ref)?
   | +--:(inline)
   | |  +--ro inline?   empty
   | +--:(use-schema)
   |+--ro use-schema* [name]
   |   +--ro name
   |   |   -> /schema-mounts/schema/name
   |   +--ro parent-reference*   yang:xpath1.0
   +--ro schema* [name]
  +--ro name   string
ADD  +--ro datastore*   ds:datastore-ref {revised-datastores}
  +--ro module* [name revision]
  |  +--ro nameyang:yang-identifier
  |  +--ro revisionunion
  |  +--ro schema? inet:uri
  |  +--ro namespace   inet:uri
  |  +--ro feature*yang:yang-identifier
  |  +--ro deviation* [name revision]
  |  |  +--ro nameyang:yang-identifier
  |  |  +--ro revisionunion
  |  +--ro conformance-typeenumeration
  |  +--ro submodule* [name revision]
  | +--ro nameyang:yang-identifier
  | +--ro revisionunion
  | +--ro schema? inet:uri
  +--ro mount-point* [module name]
 +--ro moduleyang:yang-identifier
 +--ro name  yang:yang-identifier
 +--ro config?   boolean
 +--ro (schema-ref)?
+--:(inline)
|  +--ro inline?