Subject: Re: [Last-Call] Last Call: <draft-ietf-netmod-nmda-diff-09.txt> (Comparison of NMDA datastores) to Proposed Standard

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Jun 2021 13:48:27 -0700

Hi,

I tried to get a couple companies interested in this draft but it did not
really work for them.
There is low demand for an NMDA diff but high demand for a more general
"YANG data compare" operation.

The main issues raised were:

1) can only compare 2 datastores
    Want to compare a datastore to a backup (or more generally a URI, ala
copy-config)

2) The output is only YANG Patch
    Want a "config" container that can be used with the "edit-config"
operation.
    NETCONF clients cannot use the YANG patch format to edit a datastore
with the differences

3) Not interested in the complex filtering and "origin" attributes
    Not applicable to the use-case.

The main use-case:

  1) make a backup of a server (or already have a common baseline shared
across servers)
  2) make config changes to the server and test them out
  3) get a diff that can be used as a "patch" to the backup
  4) apply the patch to different servers (that are running a compatible
config as the backup or baseline)

I realize there are no standard "backup" and "restore" operations so I am
not suggesting
that the draft be redone to support this use-case.

Andy

On Fri, Jun 18, 2021 at 6:36 AM The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the Network Modeling WG (netmod) to
> consider the following document: - 'Comparison of NMDA datastores'
>   <draft-ietf-netmod-nmda-diff-09.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-07-02. Exceptionally, comments
> may
> be sent to [email-masked] instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document defines an RPC operation to compare management
>    datastores that comply with the NMDA architecture.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/
>
>
> The following IPR Declarations may be related to this I-D:
>
>    https://datatracker.ietf.org/ipr/3084/
>
>
>
>
>
>
>

---

From: "Cumming, James (Nokia - US)" <[email-masked]>
Date: Thu, 24 Jun 2021 19:13:12 +0000

Hi,

I have the same feedback as Andy on this one.

Thanks

James

From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Date: Friday, June 18, 2021 at 16:48
To: Last Call <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>, Joel Jaeggli <[email-masked]>, NetMod WG <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-nmda-diff-09.txt> (Comparison of NMDA datastores) to Proposed Standard
Hi,

I tried to get a couple companies interested in this draft but it did not really work for them.
There is low demand for an NMDA diff but high demand for a more general "YANG data compare" operation.

1) can only compare 2 datastores
    Want to compare a datastore to a backup (or more generally a URI, ala copy-config)

2) The output is only YANG Patch
    Want a "config" container that can be used with the "edit-config" operation.
    NETCONF clients cannot use the YANG patch format to edit a datastore with the differences

The main use-case:

  1) make a backup of a server (or already have a common baseline shared across servers)
  2) make config changes to the server and test them out
  3) get a diff that can be used as a "patch" to the backup
  4) apply the patch to different servers (that are running a compatible config as the backup or baseline)

I realize there are no standard "backup" and "restore" operations so I am not suggesting
that the draft be redone to support this use-case.

Andy

On Fri, Jun 18, 2021 at 6:36 AM The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2021-07-02. Exceptionally, comments may
be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract