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" <ie...@btconnect.com> 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)" <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
