Hi Clyde,
Trimming down to just the active discussion points.
> 12. S3, P8: I'm having trouble understanding the pseudocode. What
> happens if S and/or F are not present? Can S or F ever not be
> present? - looking at the tree diagram, it seems like they might
> always be set to something in the model.
>
> [clyde] S or F might not be present.
In the YANG module, facility-list is keyed by [facility severity], which
means the values are always present, right?
[clyde] There are two paths specifying a facility-filter in which case S or F
are present, or specifying a pattern-match in which case they might not be
present if facility-filter is not specified.
<KENT> if this is what you're trying to say, then your pseudocode isn't right.
Regardless if you agree with me or not, you need to somehow make this section
clearer.
> 14. S3.1: is /syslog/actions/remote/destination/tls/ missing an
> 'address' leaf?
>
> [clyde] not as far as I know
>
Looking at the tree-diagram, the 'tls' case doesn't seem to have the
address or port fields. FWIW, the ietf-tls-client module doesn't
provide these fields so that consuming modules can configure a normal
client versus a client listening for call-home connections...
+--:(tcp)
| +--rw tcp
| +--rw address? inet:host
| +--rw port? inet:port-number
+--:(udp)
+--rw udp
+--rw address? inet:host
+--rw port? inet:port-number
+--:(tls)
+--rw tls
<address/port missing here, right?>
+--rw server-auth
<more ietf-tls-client grouping here>
[clyde] Here is what the tree looks like in the latest draft…
| +--:(tls)
| +--rw tls
| +--rw server-auth
| | +--rw trusted-ca-certs? ->
/ks:keystore/trusted-certificates/name
| | +--rw trusted-server-certs? ->
/ks:keystore/trusted-certificates/name
| +--rw client-auth
| | +--rw (auth-type)?
| | +--:(certificate)
| | +--rw certificate? ->
/ks:keystore/keys/key/certificates/certificate/name
| +--rw hello-params {tls-client-hello-params-config}?
| | +--rw tls-versions
| | | +--rw tls-version* identityref
| | +--rw cipher-suites
| | +--rw cipher-suite* identityref
| +--rw address? inet:host
| +--rw port? inet:port-number
Address and port are there. Please clarify on what you think is missing.
This is what it looks like in the model:
case tls {
container tls {
description
"This container describes the TLS transport options.";
reference
"RFC 5425: Transport Layer Security (TLS) Transport
Mapping for Syslog ";
uses tlsc:tls-client-grouping;
leaf address {
type inet:host;
description
"The leaf uniquely specifies the address of
the remote host. One of the following must be
specified: an ipv4 address, an ipv6 address,
or a host name.";
}
leaf port {
type inet:port-number;
default 6514;
description
"TCP port 6514 has been allocated as the default
port for syslog over TLS.";
}
}
}
<KENT> Sorry, it didn't see them way down at the bottom. In all my drafts, I
have these leafs before the tls-client-grouping. Can you please switch the
order around?
> 19. S4.1, in the 'severity-filter' grouping, why does leaf 'severity'
> have values set for enums 'none' and 'all'? When would these values
> be used, as opposed to the enum's name string? If you do need values,
> then shouldn't 'none' be 2147483647 (so nothing can be greater than it)
> and 'all' be -2147483648 (so everything is greater than it)?
>
> [clyde] ‘none’ and ‘all’ are set to values that are not defined in
> RFC 5424. These values were previously suggested by Martin Björklund
Fine, but let's re-evaluate the values now. Image having a variable x
and stepping through the selector list:
if x >= facility-list/severity then foo.
Now imagine it read:
if x >= 'all' then foo.
What integer value for 'all' would always ensure True? MIN-INT
Likewise, you can see that MAX-INT is the best value for 'none'.
[clyde] I will be change these to:
'none' 2147483647 (so nothing can be greater than it)
'all' -2147483648 (so everything is greater than it)?
<KENT> I think so, but we should get Martin's confirmation.
K.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
