WEBVTT

1
00:00.000 --> 00:03.600
So friends, let's walk through the answers. So the first question you were

2
00:03.600 --> 00:05.600
asked was what types of

3
00:05.600 --> 00:09.740
data formats are available when using this protocol? So you may remember at the

4
00:09.740 --> 00:10.720
beginning of this

5
00:10.720 --> 00:15.490
skill, I happen to mention that Resconv does support JSON, but it also has the

6
00:15.490 --> 00:16.720
ability to give us

7
00:16.720 --> 00:22.410
the same data back formatted utilizing XML and it's these two data formats that

8
00:22.410 --> 00:23.360
Resconv is going to

9
00:23.360 --> 00:26.840
use. So pretty much pick your preference, you have both available. My own

10
00:26.840 --> 00:28.000
preference is to work

11
00:28.000 --> 00:32.320
with JSON wherever I can. Now next question, how secure is the Resconv
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:28.000 --> 00:32.320
with JSON wherever I can. Now next question, how secure is the Resconv

12
00:32.320 --> 00:33.280
connection to the devices

13
00:33.280 --> 00:37.900
where the answer is very secure? It has full encryption and that is because it

14
00:37.900 --> 00:38.720
's going to be

15
00:38.720 --> 00:45.520
transported over 80 DPS, which if you remember is over the default port of 443.

16
00:45.520 --> 00:46.560
So no problems with

17
00:46.560 --> 00:50.730
insecurity there. The next question is do we have any available tools to

18
00:50.730 --> 00:52.000
simplify the process of

19
00:52.000 --> 00:56.500
working with the large Yang and data models? So we know we can go to GitHub or

20
00:56.500 --> 00:57.440
we can go and just

21
00:57.440 --> 01:01.760
scroll through these large data models, but this is not exactly the easiest way
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:57.440 --> 01:01.760
scroll through these large data models, but this is not exactly the easiest way

22
01:01.760 --> 01:03.360
to ingest this data.

23
01:03.360 --> 01:06.920
For example, one particular tool we could use is the one that we saw within

24
01:06.920 --> 01:07.920
this particular skill

25
01:07.920 --> 01:14.200
and this is to use Py Yang. For example, if we say Py Yang -f3 and then specify

26
01:14.200 --> 01:15.120
the name of the Yang

27
01:15.120 --> 01:19.190
model we want to actually be targeting, then essentially we can get the output

28
01:19.190 --> 01:20.160
of the model

29
01:20.160 --> 01:23.940
formatted in an i3 like structure whereby we can easily see or rather more

30
01:23.940 --> 01:24.960
easily see, not quite

31
01:24.960 --> 01:30.080
easily, definitely not, but more easily see the relationship between all of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:24.960 --> 01:30.080
easily, definitely not, but more easily see the relationship between all of the

32
01:30.080 --> 01:30.960
nodes within

33
01:30.960 --> 01:34.730
the Yang model. So there are more than one tool to do this particular process,

34
01:34.730 --> 01:35.440
but in my opinion,

35
01:35.440 --> 01:38.660
Py Yang is one of the best of them and this is the one we used in this

36
01:38.660 --> 01:39.920
particular skill.

37
01:39.920 --> 01:43.520
Now, last one does Resconv allow for configuration changes to be made? Well,

38
01:43.520 --> 01:44.720
the fri encounter to that

39
01:44.720 --> 01:49.990
is yes it does, but more crucially if so, what would that process look like?

40
01:49.990 --> 01:50.560
Well, for a start,

41
01:50.560 --> 01:53.760
we're going to have to have some particular data. We're going to have to know

42
01:53.760 --> 01:54.800
which URL we're going

43
01:54.800 --> 01:58.310
to be targeting to specify the resource we want to modify. We also want to

44
01:58.310 --> 01:59.360
ensure that we've got a

45
01:59.360 --> 02:02.820
content type header, specify the type of payload we're going to be sending. So
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
01:59.360 --> 02:02.820
content type header, specify the type of payload we're going to be sending. So

46
02:02.820 --> 02:03.600
if we're going to be

47
02:03.600 --> 02:08.590
sending JSON like data, we want to specify this in the content type header.

48
02:08.590 --> 02:09.760
Whereas, if for example,

49
02:09.760 --> 02:13.730
we were sending over an XML based payload, we would also want to specify this

50
02:13.730 --> 02:15.040
in the content type.

51
02:15.040 --> 02:18.480
Very crucially low, we would have to take a look at the HTTP methods we were

52
02:18.480 --> 02:19.520
using, for example,

53
02:19.520 --> 02:23.120
to make a configuration change. We would not use a get request. We would be

54
02:23.120 --> 02:24.240
using things like a

55
02:24.240 --> 02:29.310
post request or maybe a put request. And very, very importantly, we would have

56
02:29.310 --> 02:30.000
to ensure that the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
02:30.000 --> 02:33.780
configuration change we were trying to make at either config we are sending

58
02:33.780 --> 02:34.720
over to the device

59
02:34.720 --> 02:39.200
is actually modeled according to the correct young structure. Now, as we saw,

60
02:39.200 --> 02:39.840
we had a little bit

61
02:39.840 --> 02:43.740
of a cheat code shortcut to get this structure. We can configure the thing we

62
02:43.740 --> 02:44.720
want on the device

63
02:44.720 --> 02:49.010
itself first and then use a get request to retrieve that information and then

64
02:49.010 --> 02:50.320
use as a template for

65
02:50.320 --> 02:54.680
our future payloads. So that is us for our validation challenge on using rest

66
02:54.680 --> 02:56.400
conn to manage and validate

67
02:56.400 --> 02:59.830
our configuration changes. I hope it's been informative for you and I'd like to

68
02:59.830 --> 03:00.400
thank you for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
02:59.830 --> 03:00.400
thank you for