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

[Kent Watsen <[e-mail]>]

Hi Clyde,

In my drafts that depend on more than one work in progress, I typically assign each of them a value (e.g., XXXX, YYYY, ZZZZ) and then have RFC Editor instructions mapping each to a specific value.

Kent // contributor

--

Tom,

The agreement was that I should use “xxxx” until the two unapproved RFCs that the model depends on are assigned numbers.

     RFC xxxx: Keystore Management
     RFC xxxx: Transport Layer Security (TLS) Client";

Imported are:

  import ietf-tls-client {
    prefix tlsc;
  }

  import ietf-keystore {
    prefix ks;
  }


Have numbers been assigned?

Thanks,

Clyde

On 8/9/17, 4:32 AM, "t.petch" <[e-mail]> wrote:

    Clyde
    
    You use xxxx as a placeholder for three different RFC and two of these
    do not appear AFAICT in the list of References.
    
    This might be a challenge for the RFC Editor.
    
    Tom Petch
    
    
    ----- Original Message -----
    From: "Clyde Wildes (cwildes)" <[e-mail]>
    Sent: Wednesday, July 19, 2017 6:48 PM
    
    
    > Hi Alex,
    >
    > Answers inline as [clyde]…
    >
    > On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
    <[e-mail] on behalf of [e-mail]> wrote:
    >
    >     I am considering to implement the data model in this draft.
    (dependent on business priorities of course)
    >     I have reviewed this draft and found the following issues.
    >
    >     * I see pattern-match is specified to use POSIX 1003.2 regular
    expressions. This is presumably for compatibility with existing
    implementations; however it is inconsistent with most of YANG (which is
    specified to use XPath regular expressions) - unless these are the same.
    >
    > [clyde] I believe that my answer in the other thread explains why we
    used Posix 1003.2 – it is commonly used.
    >
    >     * pattern-match is inside the facility-filter container; common
    sense says this is wrong as pattern-match has nothing to do with
    facilities.
    >
    > [clyde] I will move pattern-match up one level in the next version of
    the draft. Thanks for catching this!
    >
    >     * The advanced-compare container groups together two nodes that
    share a common "when" and "if-feature" statement, but don't seem to have
    any semantic relation to each other. Are there general guidelines on
    when to use a container?
    >
    > [clyde] The confusion may come as a result of the when clause
    appearing before the if-feature clause which is set by the IETF
    statement order recommendation.
    >
    > The when construct was suggested by Martin Björklund as a way of
    solving the case that advanced-compare does not apply for the ‘all’ and
    ‘none’ case.
    >
    > The if-feature applies to the entire container – it is either
    supported or not.
    >
    >     * The advanced-compare container has a description starting with
    "This leaf ..." even though it is not a leaf.
    >
    > [clyde] This will be fixed in the next draft.
    >
    >     * The examples are missing <facility-filter> nodes.
    >
    > [clyde] This will be fixed in the next draft.
    >
    >     * Perhaps there should be more consistent terminology for
    receivers of syslog messages; both "collectors" and "actions" are used
    in the draft. RFC 5424 uses "collector" for the ultimate recipient of a
    log message - which might not be applicable, because the sending system
    has no idea whether the receiving system is a collector or a relay.
    >
    > [clyde] The definition of “collector” in RFC 5424 is: A "collector"
    gathers syslog content for further analysis.
    >
    > actions relate to the “further analysis” taken by the “collector”.
    >
    > “Collectors” appears in the model under the remote action and I
    believe the usage is correct:
    >       container remote {
    >         if-feature remote-action;
    >         description
    >           "This container describes the configuration parameters for
    >            forwarding syslog messages to remote relays or
    collectors.";
    >
    > I will revise the description of these terms in the next draft.
    >
    > Thanks,
    >
    > Clyde
    >
    >     ________________________________________
    >     From: netmod <[e-mail]> on behalf of Kent Watsen
    <[e-mail]>
    >     Sent: Saturday, 8 July 2017 6:34 a.m.