Hi,
So here is the implementation ...
$ apt-get install yangcli
$ yangcli --server=lightside-instruments.com --ncport=10830 --user=user
--password=ietf111 --display-mode=xml --run-command="xget /geo-location"
--batch-mode
...
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<geo-location xmlns="http://example.com/ns/geo-location";>
<latitude>59.9145666710000000</latitude>
<longitude>10.7492606760000000</longitude>
</geo-location>
</data>
</rpc-reply>
The implementation
https://github.com/vlvassilev/yuma123/tree/master/example-modules/geo-location
The target system is this
https://www.hackster.io/lightside-instruments/network-programmability-kit-for-ultra96-07435c
hosted at Bitraf - makerspace in Oslo.
/Vladimir
On 20/05/2021 11.33, Vladimir Vassilev wrote:
On 20/05/2021 10.43, Christian Hopps wrote:
Murray Kucherawy via Datatracker <[email protected]> writes:
I support Lars' and Francesca's DISCUSS positions.
The shepherd writeup says: "There are no known implementations known
to the
Shepherd. No vendors have indicated their plan to implement the
specification.
It was originally forwarded to support DT's Terra Stream project."
I'm
tempted to ask why this is slotted for Standards Track publication.
It's a grouping, it's meant to be incorporated into other YANG
modules rather than have each module come up with their own version
of a geo-location object.
So, it's wont be "implemented" directly by any vendor until it is
published and can start to be used in other module definitions. There
definitely is interest in this use in the netmod WG.
Hi,
I intend to use the grouping in our implementation. We can do that at
the upcoming Hackathon event and validate the module with some running
code.
/Vladimir
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
