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

From: Phil Shafer <[email-masked]>
Date: Wed, 3 Oct 2018 10:19:22 -0400

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.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Oct 2018 12:14:17 +0200 (CEST)

> 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.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Oct 2018 13:36:13 +0100

> suited for this purpose imo.
+1

I would like something closer to edit-config to be available via 
RESTCONF as well.

Thanks,
Rob

>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Oct 2018 14:51:48 +0200

> I would like something closer to edit-config to be available via 

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.

That being said, I support specifying format/media-type and having potentially
multiple options.

Lada

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Oct 2018 14:17:44 +0100

On 04/10/2018 13:51, Ladislav Lhotka wrote:
> 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.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Oct 2018 15:44:48 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> 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.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 Oct 2018 08:04:44 -0700

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Oct 2018 19:10:41 +0200

> 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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Oct 2018 17:41:22 +0000

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 <[email-masked]> on behalf of Ladislav Lhotka <[email-masked]>
Organization: CZ.NIC
Date: Thursday, October 4, 2018 at 1:11 PM
To: Robert Wilton <[email-masked]>, "[email-masked]" <[email-masked]>
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:
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=gQWJtjc_2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e=

Lada

> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> > > > .
> > > > 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Oct 2018 21:07:54 +0200

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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 Oct 2018 12:27:25 -0700

> formats is super flexible but defeats the purpose of a standard,
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.

Andy

> > 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
> >
> >
> > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.i
> etf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=DwI
> CAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJ
> UvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarB
> rQ5fD0vTt8k_I2KDEN97c&s=gQWJtjc_2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e=
> > > > YANG Patch is IMO better because it clearly separates the target for
> the
> > > > edits
> > > > from the new content.
> it
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
> f.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh
> 0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv
> jISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=
> RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> > > > > > .
> > > > > >
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
> f.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh
> 0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv
> jISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=
> RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
> f.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh
> 0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv
> jISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=
> RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> >

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Oct 2018 20:09:55 +0000

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?

Kent // contributor

On 10/4/18, 3:27 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> 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?

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:
> From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
> Organization: CZ.NIC
> To: Robert Wilton <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> > > > > Phil Shafer <[email-masked]<mailto:[email-masked]>> wrote:
> > > > > > Bal?zs Lengyel writes:
> > > > > [email-masked]<mailto:[email-masked]>
> > > > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=O7d-b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&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://www.jacobs-university.de/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=O7d-b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=zh7qEPSmwviaSqZBqG1GcqItXwI9pwyqIFVW6xC8rK8&e=>>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=O7d-b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Oct 2018 22:21:49 +0200

> opposed to a data-tree operation that only shows one of the

Because this is yet a third format. There is a certain benefit if a
diff format can also be used to patch. If we create a new diff format,
guess what will come up next...

/js

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 4 Oct 2018 20:59:15 +0000

On 2018-10-04, 4:22 PM, "netmod on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

    Because this is yet a third format. There is a certain benefit if a
    diff format can also be used to patch. If we create a new diff format,
    guess what will come up next...
<RR> And there are ways to get the missing values (from source datastore).
    
    /js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 Oct 2018 14:04:56 -0700

> opposed to a data-tree operation that only shows one of the

The yang-patch edit list could be augmented with an 'old-value' node.
This seems reasonable to provide for leafs.

Andy

>
>
> On 10/4/18, 3:27 PM, "Andy Bierman" <[email-masked]> wrote:
>
>
>
> > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.
> ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=DwICAg&c=
> HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
> 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> 7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=gQWJtjc_
> 2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e=
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> 7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-
> zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> > > > > > .
> > > > > >
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> 7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-
> zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> 7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-
> zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> >
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=O7d-b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=>
>
> --
> <https://maps.google.com/?q=Campus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=gmail&source=g>
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=O7d-b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=zh7qEPSmwviaSqZBqG1GcqItXwI9pwyqIFVW6xC8rK8&e=>
> >
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=O7d-b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 05 Oct 2018 09:44:33 +0200

+1

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 05 Oct 2018 09:50:29 +0200

> opposed to a data-tree operation that only shows one of the

Such a format can be developed independently, I would support it.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 05 Oct 2018 10:13:55 +0200

> format? Does the mandatory to implement format depend on the protocol

This looks nice in theory but let me remind you about the case of
choosing a mandatory-to-implement encoding for RESTCONF.

The protocols are intended to work with devices of vastly differing
capabilities and quite often there is no one-size-fits-all choice.

If a device based on a restricted platform cannot implement YANG Patch
but does JSON Patch [RFC 6902] instead, it is perfectly fine with me - and
certainly more useful than providing no diff at all.

Lada

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 8 Oct 2018 21:05:09 +0000

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

> From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
> Sent: Friday, October 05, 2018 12:50 AM
> To: Kent Watsen <[email-masked]>; Andy Bierman
> <[email-masked]>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> university.de>; [email-masked]
> > 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?
> 
> > On 10/4/18, 3:27 PM, "Andy Bierman"
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder
> <[email-masked]<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
> > 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.
> >
> > 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
> >
> >
> >> 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
> >>
> >>
> >> From: netmod
> >> <[email-masked]<mailto:[email-masked]>> on behalf
> >> of Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
> >> Organization: CZ.NIC
> >> To: Robert Wilton <[email-masked]<mailto:[email-masked]>>,
> >> "[email-masked]<mailto:[email-masked]>"
> >> <[email-masked]<mailto:[email-masked]>>
> >> > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tool
> >> > > > > > > s.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00
> >> > > > > > > &d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r
> >> > > > > > >
> =9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9O
> >> > > > > > >
> l3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=gQWJtjc_2EF3QgRvABgZK
> >> > > > > > > sjqzuIw9yUq_xee6aFJOcw&e=
> >> > > > > 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.
> >> > 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
> >> > > > >
> >> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf
> >> > > > >
> .org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0U
> >> > > > > jBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS
> >> > > > >
> laJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg
> >> > > > > 5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=
> >> > > > > .
> >> > > > >
> >> > > > 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
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
> >> lman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTX
> >>
> cWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3
> BO
> >> CbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-
> >> https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.proof
> >> 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=>
> >
> > --
> > Fax:   +49 421 200 3103         <https://www.jacobs-
> 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=>>
> >
> > https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.proofp
> > 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=>
> >

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Oct 2018 17:17:10 +0000

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 <[email-masked]>
Date: Monday, October 8, 2018 at 5:05 PM
To: Ladislav Lhotka <[email-masked]>, Kent Watsen <[email-masked]>, Andy Bierman <[email-masked]>, Juergen Schoenwaelder <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

--- Alex

> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=g0x_B-Xez7tD9hLX71D5vlcHdZohnTkiMVIKJhAHivk&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.proof&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=bzLaLoBCJ88laveupLqapYN4btjEBBvNENNy09Tsooc&e=
> > 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=DM1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=5RD96-TjymU1ZhmfZFtWEm4abkkdaxqrkCKzuv4PZRQ&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=g0x_B-Xez7tD9hLX71D5vlcHdZohnTkiMVIKJhAHivk&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.proofp&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=id5kdXDEb4afnobWT-fUq3YfsIkHooz5RtXYsoQRt1o&e=
> > oint.com/v2/url?u=https-
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=g0x_B-Xez7tD9hLX71D5vlcHdZohnTkiMVIKJhAHivk&e=
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DM1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=g0x_B-Xez7tD9hLX71D5vlcHdZohnTkiMVIKJhAHivk&e=

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 10 Oct 2018 22:06:41 +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

> From: Kent Watsen [mailto:[email-masked]]
> Sent: Tuesday, October 09, 2018 10:17 AM
> To: Alexander Clemm <[email-masked]>; Ladislav Lhotka
> <[email-masked]>; Andy Bierman <[email-masked]>; Juergen
> Schoenwaelder <[email-masked]>; [email-masked]
> 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.
> 
> To: Ladislav Lhotka <[email-masked]>, Kent Watsen <[email-masked]>,
> Andy Bierman <[email-masked]>, Juergen Schoenwaelder
> <[email-masked]>, "[email-masked]"
> <[email-masked]>
> 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
> 
> > > YANG-diff) that, in particular, provides an actual diff as opposed
> > > to a data-tree operation that only shows one of the two values?
> >
> > > format? Does the mandatory to implement format depend on the
> > > protocol that is being used?
> > >
> > > implement format. An open ended collection of implementation
> > > specific formats is super flexible but defeats the purpose of a
> > > standard, namely interoperability.
> > >
> > server supports.  yang-patch and edit-config both are viable.  Should
> > we document them both?
> > >>
> > 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
> > >>
> > >>
> > >> > > > > 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
> > >> > > >
> > >> > > YANG Patch is IMO better because it clearly separates the
> > >> > > target for the edits from the new content.
> > >> > 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
> > >> >
> > >> >
> > >> > > > .o
> > >> 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=
> > > 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=
> > > 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-
> > > 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
> > 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=

---

From: Kent Watsen <[email-masked]>
Date: Thu, 11 Oct 2018 01:39:39 +0000

Hi Alex, no objection.

My support withdraw appears to put me in the rough, which is fine from a process perspective.  But make no mistake, I think that it's bizaar for a "diff" to not show both values.  Andy's idea to augment in an 'old-value' node seems like a step in the right direction.

Kent // contributor

-----Original Message-----
From: Alexander Clemm <[email-masked]>
Date: Wednesday, October 10, 2018 at 6:06 PM
To: Kent Watsen <[email-masked]>, Ladislav Lhotka <[email-masked]>, Andy Bierman <[email-masked]>, Juergen Schoenwaelder <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

> > >> ai

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Oct 2018 19:20:00 -0700

On Wed, Oct 10, 2018 at 6:39 PM, Kent Watsen <[email-masked]> wrote:

> Hi Alex, no objection.
>
> My support withdraw appears to put me in the rough, which is fine from a
> process perspective.  But make no mistake, I think that it's bizaar for a
> "diff" to not show both values.  Andy's idea to augment in an 'old-value'
> node seems like a step in the right direction.
>
>
The requirements and use-cases have not really been discussed first.
If the use-case is for humans to compare the datastores (e.g., a
side-by-side diff like an I-D)
then the format would be very different than if the use-case was more
programmatic
(e.g., look for no diffs, look for an edit completed, patch a local copy).

Andy

> To: Kent Watsen <[email-masked]>, Ladislav Lhotka <[email-masked]>,
> Andy Bierman <[email-masked]>, Juergen Schoenwaelder <
> [email-masked]>, "[email-masked]" <[email-masked]>
> 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
>
> > > >> > > > > > Can we ensure this model contains a "format" leaf in the
> RPC's
> > input

---

From: Kent Watsen <[email-masked]>
Date: Thu, 11 Oct 2018 18:17:29 +0000

Yes, it would be good to be clear on the use cases.

It is not my intention for support human interaction, though that may occur.

The  primary question I’m hoping this work supports is “how do two datastores
differ?”, which I view as needing to return either, perhaps based on a client-
selectable parameter:

  1.  a list of xpaths where diffs occur or
  2.  a list of xpaths where diffs occur *and* both values for each diff

How the diff is consumed and, in particular, if it leads to an configuration
operation that intends to align one datastore to the other, is be a secondary
consideration IMO.

Kent // contributor

On 10/10/18, 10:20 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Oct 10, 2018 at 6:39 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alex, no objection.

The requirements and use-cases have not really been discussed first.
If the use-case is for humans to compare the datastores (e.g., a side-by-side diff like an I-D)
then the format would be very different than if the use-case was more programmatic
(e.g., look for no diffs, look for an edit completed, patch a local copy).

Kent // contributor

Andy

-----Original Message-----
From: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 10, 2018 at 6:06 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>, Andy Bierman <[email-masked]<mailto:[email-masked]>>, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

> From: Kent Watsen [mailto:[email-masked]<mailto:[email-masked]>]
> To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Ladislav Lhotka
> <[email-masked]<mailto:[email-masked]>>; Andy Bierman <[email-masked]<mailto:[email-masked]>>; Juergen
> Schoenwaelder <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> From: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
> To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>, Kent Watsen <[email-masked]<mailto:[email-masked]>>,
> Andy Bierman <[email-masked]<mailto:[email-masked]>>, Juergen Schoenwaelder
> <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
> > From: netmod [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ladislav
> > Lhotka
> > To: Kent Watsen <[email-masked]<mailto:[email-masked]>>; Andy Bierman
> > <[email-masked]<mailto:[email-masked]>>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> > university.de<https://urldefense.proofpoint.com/v2/url?u=http-3A__university.de&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=WubOcFQww-1iAABtXkAXkZWzgs4Pygw0Z3drQ_P_Ltc&s=efXeSwvoAZXTOmrl-VLlf_8pm6O3yRtlQAfosq0CDCo&e=>>; [email-masked]<mailto:[email-masked]>
> > Kent Watsen <[email-masked]<mailto:[email-masked]>> writes:
> >
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > >
> > <[email-masked]<mailto:[email-masked]><mailto:j.schoenwaelder@jacobs-<mailto:j.schoenwaelder@jacobs->
> > university.de<https://urldefense.proofpoint.com/v2/url?u=http-3A__university.de&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=WubOcFQww-1iAABtXkAXkZWzgs4Pygw0Z3drQ_P_Ltc&s=efXeSwvoAZXTOmrl-VLlf_8pm6O3yRtlQAfosq0CDCo&e=>>> wrote:
> > >> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> on behalf
> > >> of Ladislav Lhotka <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > >> Organization: CZ.NIC
> > >> To: Robert Wilton <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
> > >> "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>"
> > >> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > >> > > > > Phil Shafer <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > >> > > > > > Bal?zs Lengyel writes:
> > >> > > > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > >> > > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > >> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > >> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > >> point.com/v2/url?u=https-<https://urldefense.proofpoint.com/v2/url?u=http-3A__point.com_v2_url-3Fu-3Dhttps-2D&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=WubOcFQww-1iAABtXkAXkZWzgs4Pygw0Z3drQ_P_Ltc&s=bkWWv4kA2aWMp2Mzap7niqCham3thAr6OAl5kDbJgXU&e=>
> > university.de/<https://urldefense.proofpoint.com/v2/url?u=http-3A__university.de_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=WubOcFQww-1iAABtXkAXkZWzgs4Pygw0Z3drQ_P_Ltc&s=wYnMKkmNU8Ug9XjMX9sMGXDRNmBfOX7HJLV5MmZQXmg&e=><https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.jacobs-
> > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > oint.com/v2/url?u=https-<https://urldefense.proofpoint.com/v2/url?u=http-3A__oint.com_v2_url-3Fu-3Dhttps-2D&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=WubOcFQww-1iAABtXkAXkZWzgs4Pygw0Z3drQ_P_Ltc&s=Ivqu4FBUQWAj26-jxZHWSk3jAp9yr5PBXRpmf4P5ue8&e=>