On Thu, Oct 4, 2018 at 6:44 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> Robert Wilton <rwil...@cisco.com> 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 <p...@juniper.net> wrote: > > >>>> Bal?zs Lengyel writes: > > >>>>> https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > >>>> [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. > > I agree, this is why I prefer this format for general diffs. > > If the filter input is a complex XPath expression, the result could be a node-set that has data from all over the tree. Reproducing the "path from root" is an implementation detail that is probably complex whether it is a reconstructed XPath expression or a reconstructed subtree. <tangent> I don't like using identityrefs because the conformance for them is so poorly defined in YANG. e.g. identity compare-format; identity yang-patch { base compare-format; } identity my-yang-patch1 { base compare-format; } identity my-yang-patch2 { base yang-patch; } .... leaf filter-format { type identityref { base compare-format; } } It is IMPOSSIBLE in machine-readable YANG to say that identity "yang-patch" is mandatory to support for leaf "filter-format". In plain YANG any of these identities is valid. It is IMPOSSIBLE to say in machine-readable YANG that a client that understands "yang-patch" will work with a server that supports only "my-yang-patch2". Of course there is no way to discover which identities are supported on a server for a given identityref leaf. </tangent> > /martin > Andy > > > > > 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 > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >>> . > > >>> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod