Kent,

Comments inline as [clyde]…

On 8/14/17, 6:53 AM, "Kent Watsen" <[email protected]> wrote:

    
    
    >    5. S1 as a whole.  I'm a bit unclear what this section is doing.  It
    >    seems to be a general summary of Syslog (RFC5424).  Do we need this 
here?
    >
    > [clyde] Suggestions appreciated. I wanted to provide a high level overview
    > of the syslog process. I cleaned it up a little.
     
    Move Section 2 text to Section 1, replacing the text that's there?
    
[clyde] will do    
    
    >       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.   
    
    >    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.";
                }
              }
            }

   
    
    > 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)?

    
    >    20. S7: can you indent the two blocks of details so the whole thing
    >    reads better?
    >
    > [clyde] I searched for an example that shows how to do this in XML
    > and couldn’t find the keyword.
    
    Assuming xml2rfc XML, then you could convert the contents to a figure,
    or a list with style='empty'

[clyde] ok I will follow this advice    
 

Thanks again for all your review comments!

Clyde
      
    Thanks,
    Kent
    
    
    

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to