Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

Alexander Clemm <alexander.clemm@huawei.com> Wed, 10 October 2018 22:06 UTC

Return-Path: <alexander.clemm@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B165128CFD for <netmod@ietfa.amsl.com>; Wed, 10 Oct 2018 15:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzO6Ru48SR6i for <netmod@ietfa.amsl.com>; Wed, 10 Oct 2018 15:06:50 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1965128D68 for <netmod@ietf.org>; Wed, 10 Oct 2018 15:06:49 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 35604392F72D6; Wed, 10 Oct 2018 23:06:44 +0100 (IST)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 10 Oct 2018 23:06:46 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML703-CHM.china.huawei.com ([169.254.5.166]) with mapi id 14.03.0415.000; Wed, 10 Oct 2018 15:06:41 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Kent Watsen <kwatsen@juniper.net>, Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
Thread-Index: AQHUWyQUI2nNckn+1ky1f4oa9l5TQKUPVRSAgAAnqICAAARaAIAABz8AgABBFoCAAAiTAIAAGC0AgAAFdICAAAvggIAAw7yAgAUeeMCAAckwAIABa8oQ
Date: Wed, 10 Oct 2018 22:06:41 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6E244@sjceml521-mbx.china.huawei.com>
References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <ccc83277-cfa7-f363-1beb-78e801f8b675@cisco.com> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <CABCOCHTu5ju8Qv548g+mDNioBAAuxRywZknoNO9mbUOY3MaoGw@mail.gmail.com> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> <87sh1kde7u.fsf@nic.cz> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D575@sjceml521-mbx.china.huawei.com> <E522A8A5-F717-43B1-BBE1-922A9690E825@juniper.net>
In-Reply-To: <E522A8A5-F717-43B1-BBE1-922A9690E825@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.35.95]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/st_EW-XfW6gUEhq_5c4U3iAXCkE>
Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Oct 2018 22:06:52 -0000

Which format to make mandatory sounds like something we can discuss in Bangkok.  The reason YANG-patch was chosen is reuse, although it is certainly conceivable to develop another format.  (Per discussion on the list we will put the hooks in place to allow for other options.)  Either way, this seems to be one of the technical details that need to be decided, not something that would make or break support as a whole?  
--- Alex

> -----Original Message-----
> From: Kent Watsen [mailto:kwatsen@juniper.net]
> Sent: Tuesday, October 09, 2018 10:17 AM
> To: Alexander Clemm <alexander.clemm@huawei.com>; Ladislav Lhotka
> <lhotka@nic.cz>; Andy Bierman <andy@yumaworks.com>; Juergen
> Schoenwaelder <j.schoenwaelder@jacobs-university.de>; netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
> 
> I agree that a mandatory to implement format is desirable.
> 
> I disagree that YANG-Patch is the right format, for reasons stated before.  I feel
> that a compromise of this sort for a mandatory-to-implement is wrong.
> 
> If this is what the WG wants, I withdraw my support.
> 
> Kent // contributor
> 
> 
> 
> -----Original Message-----
> From: Alexander Clemm <alexander.clemm@huawei.com>
> Date: Monday, October 8, 2018 at 5:05 PM
> To: Ladislav Lhotka <lhotka@nic.cz>, Kent Watsen <kwatsen@juniper.net>,
> Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org"
> <netmod@ietf.org>
> Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
> 
> I would second the request for one format (which is mandatory to support),
> which must be specified.  YANG-Patch is the logical candidate IMHO.
> 
> To allow selection of other formats using an input parameter makes sense, but
> adds some complexity from there:  How to know which formats are supported?
> (Add a list of supported formats somewhere?)   Or simply rely on augmentation
> for those implementations that want it?
> 
> --- Alex
> 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav
> > Lhotka
> > Sent: Friday, October 05, 2018 12:50 AM
> > To: Kent Watsen <kwatsen@juniper.net>; Andy Bierman
> > <andy@yumaworks.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> > university.de>; netmod@ietf.org
> > Subject: Re: [netmod] WG adoption poll for
> > draft-clemm-netmod-nmda-diff-00
> >
> > Kent Watsen <kwatsen@juniper.net> writes:
> >
> > > Sure, one mandatory to implement format, others nice to have.
> > > Interoperability good.  Agreed.
> > >
> > > But why YANG-patch and not something built for the purpose (e.g.,
> > > YANG-diff) that, in particular, provides an actual diff as opposed
> > > to a data-tree operation that only shows one of the two values?
> >
> > Such a format can be developed independently, I would support it.
> >
> > Lada
> >
> > >
> > > Kent // contributor
> > >
> > >
> > > On 10/4/18, 3:27 PM, "Andy Bierman"
> > <andy@yumaworks.com<mailto:andy@yumaworks.com>> wrote:
> > >
> > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder
> > <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-
> > university.de>> wrote:
> > > Folks, the more formats there are, the less interoperability we get.
> > > If there are multiple formats, is there a mandatory to implement
> > > format? Does the mandatory to implement format depend on the
> > > protocol that is being used?
> > >
> > > I prefer one format or if necessary I am fine with one mandatory to
> > > implement format. An open ended collection of implementation
> > > specific formats is super flexible but defeats the purpose of a
> > > standard, namely interoperability.
> > >
> > > I agree there needs to be 1 mandatory-to-implement format.
> > >
> > > IMO this needs to be YANG Patch because it is more precise then
> > > constructing an XML tree with operation attributes in it (e.g., how
> > > else do you represent a delete or a move?) Also, YANG Push is using
> > > YANG Patch format and common code for push and diff would be possible.
> > >
> > > I think other formats should be allowed.
> > > This is very tool-specific. I could see how somebody might want a
> > > textual patch of the XML representation to produce the new XML
> > representation.
> > >
> > >
> > > /js
> > >
> > > Andy
> > >
> > >
> > > On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote:
> > >> We agree that the diff-format should be client-selectable, modulo
> > >> what the
> > server supports.  yang-patch and edit-config both are viable.  Should
> > we document them both?
> > >>
> > >> That said, since neither edit-config nor yang-patch are diffing
> > >> formats, so
> > much as formats for converting one data tree to another, would it make
> > sense to define an actual diffing format?  I would think that a diff
> > would provide both values, not just a new value.
> > >>
> > >> Kent // contributor
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: netmod
> > >> <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> on behalf
> > >> of Ladislav Lhotka <lhotka@nic.cz<mailto:lhotka@nic.cz>>
> > >> Organization: CZ.NIC
> > >> Date: Thursday, October 4, 2018 at 1:11 PM
> > >> To: Robert Wilton <rwilton@cisco.com<mailto:rwilton@cisco.com>>,
> > >> "netmod@ietf.org<mailto:netmod@ietf.org>"
> > >> <netmod@ietf.org<mailto:netmod@ietf.org>>
> > >> Subject: Re: [netmod] WG adoption poll for
> > >> draft-clemm-netmod-nmda-diff-00
> > >>
> > >> On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote:
> > >> >
> > >> > On 04/10/2018 13:51, Ladislav Lhotka wrote:
> > >> > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote:
> > >> > > > On 04/10/2018 11:14, Martin Bjorklund wrote:
> > >> > > > > Phil Shafer <phil@juniper.net<mailto:phil@juniper.net>> wrote:
> > >> > > > > > Bal?zs Lengyel writes:
> > >> > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__to
> > >> > > > > > > ol
> > >> > > > > > > s.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D
> > >> > > > > > > 00
> > >> > > > > > > &d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r
> > >> > > > > > >
> > =9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9O
> > >> > > > > > >
> > l3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=gQWJtjc_2EF3QgRvABgZK
> > >> > > > > > > sjqzuIw9yUq_xee6aFJOcw&e=
> > >> > > > > > [I've moved to a "deep lurker" role here, but ...]
> > >> > > > > >
> > >> > > > > > Can we ensure this model contains a "format" leaf in the RPC's
> input
> > >> > > > > > so that future (and proprietary) formats can be supported?   That
> > >> > > > > > leaf can be an identityref that defaults to yang-patch.
> > >> > > > > I think this is a good idea.  I would prefer the
> > >> > > > > edit-config format over YANG patch for describing a diff.
> > >> > > > > The edit-config format is more suited for this purpose imo.
> > >> > > > +1
> > >> > > >
> > >> > > > I would like something closer to edit-config to be available
> > >> > > > via RESTCONF as well.
> > >> > > YANG Patch is IMO better because it clearly separates the
> > >> > > target for the edits from the new content.
> > >> > > In edit-config these two are mixed together.
> > >> > Yes, that is primarily why I prefer the edit-config.  I perceive
> > >> > that it is a denser and more efficient format.  I think that it
> > >> > is both easier to construct (when diffing two trees) and also
> > >> > more efficient to apply when generating an updated tree.
> > >>
> > >> Except for certain corner cases, for example if two trees differ
> > >> only in the value of a single leaf but this leaf happens to be a list key.
> > >>
> > >> Lada
> > >>
> > >> >
> > >> > Thanks,
> > >> > Rob
> > >> >
> > >> >
> > >> > > That being said, I support specifying format/media-type and
> > >> > > having potentially multiple options.
> > >> > >
> > >> > > Lada
> > >> > >
> > >> > > > Thanks,
> > >> > > > Rob
> > >> > > >
> > >> > > >
> > >> > > > > /martin
> > >> > > > >
> > >> > > > > _______________________________________________
> > >> > > > > netmod mailing list
> > >> > > > > netmod@ietf.org<mailto:netmod@ietf.org>
> > >> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ie
> > >> > > > > tf
> > >> > > > >
> > .org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0U
> > >> > > > > jBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS
> > >> > > > >
> > laJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg
> > >> > > > > 5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> > >> > > > > .
> > >> > > > >
> > >> > > > _______________________________________________
> > >> > > > netmod mailing list
> > >> > > > netmod@ietf.org<mailto:netmod@ietf.org>
> > >> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf
> > >> > > > .o
> > >> > > >
> > rg_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXe
> > >> > > > MK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZ
> > >> > > >
> > o&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi
> > >> > > > 1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> > >> --
> > >> Ladislav Lhotka
> > >> Head, CZ.NIC Labs
> > >> PGP Key ID: 0xB8F92B08A9F76C67
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org<mailto:netmod@ietf.org>
> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
> > >> ai
> > >> lman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTX
> > >>
> >
> cWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3
> > BO
> > >> CbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-
> > zi1OboCL4SX2huW9euHiVRSCor
> > >> 9n_APQ&e=
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org<mailto:netmod@ietf.org>
> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
> > >> ailman_listinfo_netmod&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3v
> > >>
> oDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jsw
> nM
> > >> 48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=g0x_B-
> Xez7tD9hLX71D5vlcHdZohn
> > >> TkiMVIKJhAHivk&e=<https://urldefense.proofpoint.com/v2/url?u=https-
> > >> 3A__urldefense.proof&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > >>
> TXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM
> 48
> > >> GwdI4tez-
> Jtf2ua2jvtLZVKfiwkbwbIrU&s=bzLaLoBCJ88laveupLqapYN4btjEBBv
> > >> NENNy09Tsooc&e=
> > >> point.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=D
> > >> wMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9E
> > >> PoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=O7d-
> > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6
> > >> W3qt4&s=5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=>
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-
> 2D&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=D
> M1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=5RD96-
> TjymU1ZhmfZFtWEm4abkkdaxqrkCKzuv4PZRQ&e=
> > university.de/<https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.jacobs-
> > 2Duniversity.de_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=O
> > 7d-
> >
> b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=zh7qEPSmwviaSqZBqG1Gc
> > qItXwI9pwyqIFVW6xC8rK8&e=>>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org<mailto:netmod@ietf.org>
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
> > > ilman_listinfo_netmod&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > >
> TXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM
> 48G
> > > wdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=g0x_B-
> Xez7tD9hLX71D5vlcHdZohnTkiM
> > > VIKJhAHivk&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__u
> > > rldefense.proofp&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWz
> > >
> oCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM48Gwd
> I4t
> > > ez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=id5kdXDEb4afnobWT-
> fUq3YfsIkHooz5RtXYso
> > > QRt1o&e=
> > > oint.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwM
> > > FaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoO
> > > H7Yhqn2gsBYaGTvjISlaJdcZo&m=O7d-
> > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt
> > > 4&s=5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
> > > ilman_listinfo_netmod&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > >
> TXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM
> 48G
> > > wdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=g0x_B-
> Xez7tD9hLX71D5vlcHdZohnTkiM
> > > VIKJhAHivk&e=
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_netmod&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcW
> >
> zoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM48Gw
> dI4te
> > z-Jtf2ua2jvtLZVKfiwkbwbIrU&s=g0x_B-
> Xez7tD9hLX71D5vlcHdZohnTkiMVIKJhAHi
> > vk&e=