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.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15
This is a notice to start a three week NETMOD WG last call for the
document:
A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-15
Note: Three weeks is more than needed, especially given this
draft has been through Last Call before, but we understand
folks are busy these days.
Please indicate your support or concerns by Friday, July 28, 2017.
We are particularly interested in statements of the form:
* I have reviewed this draft and found no issues.
* I have reviewed this draft and found the following issues: ...
As well as:
* I have implemented the data model in this draft.
* I am implementing the data model in this draft.
* I am considering to implement the data model in this draft.
* I am not considering to implement the data model in this draft.
Thank you,
NETMOD WG Chairs
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
