Subject: [netmod] IETF Syslog Model Flaw

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Thu, 13 Nov 2014 17:58:05 +0000

Hi,

While reviewing the latest draft of the IETF Syslog YANG model 
(http://www.ietf.org/id/draft-ietf-netmod-syslog-model-00.txt), I 
discovered a flaw in the remote-logging-action container that will have to 
be fixed in a future revision. The issue is that the 
remote-logging-destination list destination leaf name's IP protocol is 
ambiguous because it is not currently available in the model - an ipv4 
destination hostname can't be distinguished from an ipv6 destination 
hostname. This is problematic for some network element configuration which 
requires prior knowledge of the ip-version.

The fix is to add ip-version to the ietf-syslog.yang model inserting the 
following after line 321:

        leaf destination-ip-type {
          type inet:ip-version;
          mandatory true;
          description
            "The leaf uniquely specifies the ip protocol type
             for the remote host.";
        }

Example for an ipv4 host:

    <syslog xmlns="urn:ietf:params:xml:ns:yang:ietf-syslog" 
<http://cisco.com/ns/yang/syslog">>
      <remote-logging-action>
        <remote-logging-destination>
          <destination-ip-type>ipv4</destination-ip-type>
          <destination>hostname</destination>
          <logging-facility-all/>
            <severity>notice</severity>
          </logging-facility-all>
          <destination-facility>destination-facility</destination-facility>
          <source-interface>source-interface-name</source-interface>
          <vrf-name>vrfname</vrf-name>
        </remote-logging-destination>
      </remote-logging-action>
    </syslog>

Example for an ipv6 host:

    <syslog xmlns="urn:ietf:params:xml:ns:yang:ietf-syslog" 
<http://cisco.com/ns/yang/syslog">>
      <remote-logging-action>
        <remote-logging-destination>
          <destination-ip-type>ipv6</destination-ip-type>
          <destination>hostname</destination>
          <logging-facility-all/>
            <severity>notice</severity>
          </logging-facility-all>
          <destination-facility>destination-facility</destination-facility>
          <source-interface>source-interface-name</source-interface>
          <vrf-name>vrfname</vrf-name>
        </remote-logging-destination>
      </remote-logging-action>
    </syslog>

I will prepare an updated draft for re-submission.

Thanks,

Clyde

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Nov 2014 19:11:06 +0100

Speaking as technical contributor: Why is this needed? And even if
there is a reason why this is needed, why would it be mandatory?

/js

On Thu, Nov 13, 2014 at 05:58:05PM +0000, Clyde Wildes (cwildes) wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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: Thu, 13 Nov 2014 19:01:14 +0000

Juergen,

Thanks for your review.

One of the network element operating systems that I have been working with 
requires prior knowledge of ip-type in order to configure remote access. 
If you feel strongly about this we can leave the model alone and augment 
for the ip-type. Regarding mandatory: I agree that if we leave it in, it 
should not be mandatory.

Thanks,

Clyde

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Nov 2014 20:45:32 +0100

> for the ip-type. Regarding mandatory: I agree that if we leave it in, it 

If this is not a common requirement, then I would prefer to leave it
out. Things like rsyslogd etc. do not seem to require this.

That said, there should perhaps be a warning in the description clause
that relying on DNS name resolution may cause some log messages to be
lost. In order to reduce the likelihood of messages lost due to DNS
resolution time, it may be a good idea to configure an IP address
instead of a name.

/js