Hey, Madison! Thanks for your attention to this. Comments inline.
2) We have updated Section 6 to reference the XML specification because it
contains XML (this reference has been added to the Normative References
section; see
https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/).
Also, we changed the comments to sentences so that the first line of the
sourcecode is the XML declaration.
NEW:
6. Usage Examples
The following examples are in XML [W3C.REC-xml11-20060816].
6.1. Syslog Configuration for Severity Critical
This example shows enabling console logging of syslogs of severity critical.
<?xml version="1.0" encoding="UTF-8"?>
<syslog xmlns="urn:ietf:params:xml:ns:yang:ietf-syslog">
[...]
6.2. Remote Syslog Configuration
This example shows enabling remote logging of syslogs to
UDP destination foo.example.com for facility auth and
severity error.
<?xml version="1.0" encoding="UTF-8"?>
<syslog xmlns="urn:ietf:params:xml:ns:yang:ietf-syslog">
[…]
where:
[W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Fifth Edition)", World Wide Web Consortium
Recommendation REC-xml-20081126, November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>.
[JMC] This looks fine to me.
>> 4) <!-- [rfced] What field is "[RFC5424] field" referring to in this
>> sentence?
>>
>> Original:
>> Within each action, a selector is used to filter syslog messages. A
>> selector consists of a list of one or more filters specified by
>> facility-severity pairs, and, if supported via the select-match
>> feature, an optional regular expression pattern match that is
>> performed on the [RFC5424] field.
>> -->
>> [JMC] In this case – and used in other places in the document – the field
>> is the message text. In RFC5424 parlance that is MSG (Section 6.4).
3) Thank you for the clarification. With this in mind, may we rephrase the
following text to improve clarity for the reader and avoid using "[RFC5424]" as
an adjective?
Perhaps:
Within each action, a selector is used to filter syslog messages. A
selector consists of a list of one or more filters specified by
facility-severity pairs, and, if supported via the select-match
feature, an optional regular expression pattern match that is
performed on the MSG field described in Section 6.4 of [RFC5424].
[JMC] Yes, this works and reads well.
>> 5) <!-- [rfced] This text has been changed from an artwork element
>> to a sourcecode element with type="pseudocode". Please let us
>> know if you prefer to change it to running text (within a <t>
>> element).
>> [JMC] Pseudocode works here.
>>
>>
>> Original:
>> A syslog message is processed if:
>>
>> There is an element of facility-list (F, S) where
>> the message facility matches F
>> and the message severity matches S
>> and/or the message text matches the regex pattern (if it
>> is present)
>>
>> Perhaps:
>> A syslog message is processed if there is an element of facility-list
>> (F, S) where the message facility matches F, the message severity
>> matches S, and/or the message text matches the regex pattern (if it
>> is present).
>> -->
>
> The updated text sounds better.
4) We have updated the text as requested and kept the alignment of the
pseudocode as shown in the original. Please let us know if this is the desired
output or if any further changes are needed.
[JMC] I think it looks okay. Thanks.
>> 7) <!-- [rfced] We have the following questions regarding the YANG module.
>>
>> a) What do the numbers in parentheses refer to in various descriptions?
>> They seem to refer to the numerical codes in Table 1 of RFC 5424;
>> should a sentence be added so that this is clear to readers?
>> [JMC] Yes, those are the encoded numeric values for the local facilities.
>> Maybe instead of parenthesizing these, each identity can have a second
>> sentence in the description:
>> OLD:
>> … (X).
>> NEW:
>> …. The RFC5424 numerical code is X.
>> [JMC] And alter the reference to point to Section 6.2.1 of 5424.
>>
>>
>> Original:
>> "The facility for local use 0 messages (16).";
>> -->
5) For the encoded numeric values, we have updated each instance using the
format shown below (adding "Section 6.2.1" to each reference clause and
specifying "numerical code" before the value that appears for simplicity and to
avoid using RFC 5424 as an adjective). Please let us know if any further
updates are needed.
[JMC] Looks good. Thanks!
Current (Example from YANG Module):
identity kern {
base syslog-facility;
description
"The facility for kernel messages (numerical code 0).";
reference
"RFC 5424: The Syslog Protocol, Section 6.2.1.";
>> 9) <!--[rfced] Security Considerations: This text does not
>> exactly match the text provided for security
>> considerations of documents that contain YANG modules:
>> https://wiki.ietf.org/group/ops/yang-security-guidelines
>> Should this document be updated to match those?
>> For example: usage of "all" vs. "some" and the additional sentences
>> in the 5th paragraph (which start with "Logging" and "If logging").
>>
>> Original:
>> There are a number of data nodes defined in this YANG module that are
>> writable/creatable/deletable (i.e., config true, which is the
>> default). These data nodes should be considered sensitive or
>> vulnerable in all network environments. Logging in particular is
>> used to assess the state of systems and can be used to indicate a
>> network compromise. If logging were to be disabled through malicious
>> means, attacks may not be readily detectable. Therefore write
>> operations (e.g., edit-config) to these data nodes without proper
>> protection can have a negative effect on network operations and on
>> network security.
>>
>> Corresponding text on
>> https://wiki.ietf.org/group/ops/yang-security-guidelines:
>>
>> There are a number of data nodes defined in this YANG module that are
>> writable/creatable/deletable (i.e., config true, which is the
>> default). These data nodes may be considered sensitive or vulnerable in
>> some network environments. Write operations (e.g., edit-config) to these
>> data nodes without proper protection can have a negative effect on network
>> operations. These are the subtrees and data nodes and their
>> sensitivity/vulnerability:
>> -->
>> [JMC] Your mods to Security Considerations are good. I think breaking out
>> the boilerplate text and the additional “logging” text into separate
>> paragraphs is a good choice. Virtually the entire module is read-write, but
>> the critical “top-level” nodes are “console”, “file”, and “remote” as each
>> of these can have actions that disable logging. The “remote” branch can
>> also be used as a means to exfiltrate data to a nefarious destination.
>
> The Security Considerations section template has been further updated by
> draft-ietf-netmod-rfc8407bis. In particular, the second paragraph has been
> updated. This will affect your next point #10.
>
> This is a reminder to myself to get the yang-security-guidelines page updated
> once rfc8407bis is approved.
6) Thank you for letting us know! We have updated the Security Considerations
to reflect what appears in draft-ietf-netmod-rfc8407bis. Please let us know if
the updates are correct.
[JMC] Some of the changes you mentioned last time for the template are not
reflected (e.g., changing “all” to “some”). That change would also be required
by 8407bis.
Joe
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
