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)" <cwil...@cisco.com>
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"
<netmod-boun...@ietf.org on behalf of alex.campb...@aviatnet.com> 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 <netmod-boun...@ietf.org> on behalf of Kent Watsen
<kwat...@juniper.net>
>     Sent: Saturday, 8 July 2017 6:34 a.m.

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to