Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Mon, 21 Jul 2014 21:38:29 +0000

Clyde,

Here are my initial comments:

1. leaf file-name {
        type string;
        mandatory true;
        description
          "This leaf specifies the name of the log file.";

      }

This file-name leaf doesn't reflect what is in the system. What is the reason that uri is not use?

2. In
leaf destination {
type string;
description
"The leaf uniquely specifies the address of the remote host. One
of the following must be specified: an ipv4 address, an ipv6
address, or a host name.";
}

type string for destination doesn't reflect the actual destination. Type union allows to model the type with host and ip-address.

3. In
leaf source-interface {
type string;
description
"This leaf sets the source interface for the remote
Syslog server. Either the interface name or the
interface IP address can be specified.";
}

it has a similar case to #2. String is too wide to reference an interface.

4.

<global-logging>
<facility>syslogtypes:kern</facility>
<severity>syslogtypes:critical</severity>
<facility>syslogtypes:auth</facility>
<severity>syslogtypes:error</severity>
</global-logging>

This xml example should be <logging-severity/>around the facility and severity as the following.

<global-logging>
 <logging-severity><facility>syslogtypes:kern</facility>
<severity>syslogtypes:critical</severity></logging-severity>
<logging-severity><facility>syslogtypes:auth</facility>
<severity>syslogtypes:error</severity></logging-severity>
</global-logging>

5.

choice logging-scope {
              description
                "This choice describes the option to specify all
                 facilities or a specific facility.";
              case all-facilities {
                description
                  "This case specifies all facilities.";
                leaf logging-severity {
                  type syslogtypes:Severity;
                  description
                    "This leaf specifies the severity of Syslog
                     messages for all facilities.";
                }
              }

This choice is repeated in multiple different place. For readability and maintainability, it would be a good case to use augment and add new case statement when needed.

Thanks,
Lisa

On 6/26/14 5:06 PM, "Clyde Wildes (cwildes)" <[email-masked]<mailto:[email-masked]>> wrote:

FYI and comments...

Here is an initial draft proposal for a YANG model for Syslog.

Thanks,

Clyde

On 6/26/14, 4:05 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
wrote:

A new version of I-D, draft-wildes-netmod-syslog-model-00.txt
has been successfully submitted by Kiran Koushik Agrahara and posted to
the
IETF repository.

Name: draft-wildes-netmod-syslog-model
Revision: 00
Title: SYSLOG YANG model
Document date: 2014-06-26
Group: Individual Submission
Pages: 19
URL:
http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-00.tx
t
Status:
https://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/
Htmlized:
http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-00

Abstract:
   This document describes a data model for Syslog
   protocol which is used to convey event notification messages.

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jul 2014 15:34:36 +0200

> type string for destination doesn't reflect the actual destination. Type union allows to model the type with host and ip-address.

This should probably be inet:host [RFC6991] or something like that.
And there should most likely be a port number. And the key should not
be the destination IP address.
 
> it has a similar case to #2. String is too wide to reference an interface.

Yes, I agree.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Tue, 22 Jul 2014 17:48:09 +0000

Lisa,

Thanks for your review comments.

My responses are inline…

From: "Lisa Huang (yihuan)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 21, 2014 at 5:38 PM
To: Clyde Wildes <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt

Clyde,

1. leaf file-name {
        type string;
        mandatory true;
        description

      }

[clyde] I will change the type to inet:uri in a later revision.

2. In
leaf destination {
type string;
description

[clyde] I will change the type to inet:host in a later revision.

3. In
leaf source-interface {
type string;
description

[clyde] I will change the type to if:interface-ref in a later revision.

4.

<global-logging>

<global-logging>

[clyde] I will update the example to reflect the latest model in a later revision.

5.

choice logging-scope {
              description

[clyde] I agree that this can be simplified and will do so in a later revision.

Thanks,
Clyde

Thanks,
Lisa

FYI and comments...

Thanks,

Clyde

Abstract:

The IETF Secretariat

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Tue, 22 Jul 2014 17:57:33 +0000

Jeurgen,

Thanks for your review.

I will adopt inet:host for the destination type in a later revision of the
model.

I will adopt a union of if:interface-ref and inet:ip-address for the
source-interface type in a later revision of the model.

Thanks,

Clyde

On 7/22/14, 9:34 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>> type string for destination doesn't reflect the actual destination.
>>Type union allows to model the type with host and ip-address.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jul 2014 20:30:22 +0200

> [clyde] I will change the type to inet:uri in a later revision.

I assume that the idea is to _append_ to a log file. How does an
append work for the various possible URI schemes?

/js

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Tue, 22 Jul 2014 20:55:54 +0000

Juergen,

I should have qualified my response to indicate that the only URI scheme
that will be supported for file-logging is ³file:². Other distribution
actions are supported by other leaves.

Regarding file append: some implementations support a maximum size feature
that indicates when the syslog file will wrap with new messages written
over the oldest entry. Other implementations support an archive feature
that indicates when the syslog file should be renamed and a new file
started (time based or size based), along with the maximum number of
archived files to save. We left these two features out of this model for
simplicity knowing that they could be added through augmentation if needed
for a particular implementation.

Thanks,

Clyde

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jul 2014 23:14:17 +0200

> actions are supported by other leaves.

OK. Although the value of using inet:uri may be limited if the only
URI scheme supported is file: - well maybe this is meant to cover
future extensions? But if the action is really 'file', then I am not
sure a URI is required.

/js

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 22 Jul 2014 21:27:33 +0000

Agree. If just for file, URI could bring mis-understanding.

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Tue, 22 Jul 2014 21:36:38 +0000

Juergen,

I think that there is benefit to use inet:uri even though it is will be
restricted to the “file:” scheme because it is more specific. From the RFC
6021 URI description "Objects using the uri type MUST be in US-ASCII
encoding, and MUST be normalized as described by RFC 3986…”.

Thanks,

Clyde

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2014 00:23:04 +0200

> encoding, and MUST be normalized as described by RFC 3986…”.

I see. The question, though, is whether the URI imposed encoding rules
are a feature given that NETCONF handles UTF-8 just fine. I guess I
would like URIs more for extensibility reasons (but then it was said
that this action is limited to local files).

/js

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 22 Jul 2014 22:40:31 +0000

If just meant to use file uri, Which way would makes more sense?

1. Using uri with pattern regex/description to limit to local file uri.
2. Using string with pattern regex/description to limit to local file uri.

If just file uri, would you recommend to use uri with patten to limit to
file uri or string 

On 7/22/14 6:23 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>> restricted to the ³file:² scheme because it is more specific. From the
>>RFC
>> encoding, and MUST be normalized as described by RFC 3986Š².
>> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2014 04:47:11 +0200

> If just file uri, would you recommend to use uri with patten to limit to

If it is a URI, you really want to use inet:uri since otherwise you
have to repeat text that is already in the inet:uri description.

While a pattern can be used to restrict the uri schemes, this is
probably not what I would do since this does not allow to ever support
additional schemes should that be necessary. I would probably instead
write in the description clause that only file: URI schemes must be
supported and I would perhaps detail which error is returned in case
of an attempt to configure a scheme not supported.

/js