Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Kent Watsen <[e-mail]>]

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.