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

Reply via email to