Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 3

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 18 Dec 2006 00:08:04 +0900

Hi,
    The following starts the discussion on the points
raised in Dbh re-Review of -mib-11, part 3.

     Cheers

     Glenn

+-----------------------------------------------------+
3.1 The idnits checker reports the use of the old copyright and
     disclaimer boilerplates rather than the new copyright and
     disclaimer boilerplates. These need to be updated.

Response.
     Same as 2.7.
     Updated the boilerplate for the Copyright notice.
     http://tools.ietf.org/tools/idnits/
     shows zero errors now.

3.2 syslogEntityOperationsReference uses a lower case "should".
     Is it nto important for interoperability that this be done?
     If so, then this should be a "SHOULD". If not for
     interoperability, why are we saying it "should" be done?

Response.
     Changed should to SHOULD.

3.3 I still have difficulty understanding why default parameters
     are listed in the MIB module. What is the use case that
     requires these objects in the MIB module?

     Who decides what the default values should be? Since they are
     read-write objects, I assume the purpose is to allow an NMS to
     set the default values they want the sender to use. What happens
     if there are multiple NMSs talking to the same sender? Then who
     decides? If each NMS gets to decide, than you need a table in
     which each row is "owned" by a particular NMS. I still don't
     see why this would be needed however.

     If the sender decides, and the objects exist only so the
     receivers can check and see what the sender will use for
     defaults, then why are the objects read-write? Once an NMS
     checks the defaults, what are they supposed to do with this
     information?

     I question whether this deserves to be in the MIB module at
     all, but if it kept, then at least the MIB module should
     include a description of why it is there and how it should
     be used.

Response.
     OK. I understand that there is a problem when several NMSs
     are talking to the system.  I will make this read-only.
     These default values are set by some means at start up.
     In general the default values will be used ( IPv4, UDP,
     port 512 etc.) by syslog entities.
     In these cases it is not necessary to specify the (default)
     values for each row (representing a syslog entity) in the
     syslogEntityControlTable. The values will be specified when
     they are different from the defaults.

     Does that help ?

3.4 RFCPROT is a reference in syslogDefaultTransportDomain; it
     probably shoul dbe shown as [RFCPROT] or the RFC editor may
     overlook it.

Response.
     Done.

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "David Harrington" <[email-masked]>
Date: Sun, 17 Dec 2006 13:27:55 -0500

Hi Glenn,

>      they are different from the defaults.

Only to a degree. I think this reinforces some of my concerns (and
Tom's).
Why does this need to be made accessible in the MIB module?
If it is read-write, you have the problem of multiple NMSs.

If it is read-only, then no NMS can modify it.
So all it does is reflect what default values are used.
But if the table represents different engines (not different
applications using a common engine), then those engines should
probably operate on different ports, So it becomes a per-engine
(per-entity) issue, not a global default issue. So it doesn't make
sense as a scalar value, if it must be applied on a per-row basis.

If the idea is to recommend what defaults should be used
(IPv4,UDP,512), those can be specified as DEFVALS in the per-row
managed objects (TransportDomain and syslogService) that can override
such DEFVALs. 

You say that if the entity uses the defaults, it is not necessary to
specify the values for each row. But the objects are defined a part of
the row, and they are listed as mandatory-to-implement objects in the
syslogEntityControlGroup. Why would we want to require implementers to
implement these objects and then tell them they do not need to use
them?  (and when we go down that path, then I have some problems with
"If no value is specified,...").

Different engines may have different ideas of what to use for defaults
for severity and facility as well, so would it not make sense to have
these defaults also specified on a per-row basis? If the engine and
application are combined into a single entity, then surely that
application has some idea of its own facility? But if I have a login
facility and a ntp facility, why would I want the ability to use SNMP
to set a default facility equal to uucp? 

It does not make sense to me to define these global defaults in a MIB
module that supports multiple entities; or maybe I do not understand
the use case, because you have lumped all sender/receiver/relay
together as entities, and this is really only useful in certain
situations. Are these designed to allow a receiver/collector to
calculate and store a PRI for messages received from non-standard
senders? Are these designed to allow a relay to calculate the PRI for
messages received from non-standard senders, and to convert the
message into a standard message format? Or are these designed for a
standard sender to calculate the PRI for applications that don't
specify their facility and severity when asking the sender to send a
message? What are these defaults for?

These defaults might make sense if the MIB represented one
sender/engine and the table represented different applications
(facilities) that utilized the message-sending capaibilities of the
engine. Even there I would think the applications(facility) would be
expected to identify its own facility category to a
standards-compliant sender. If it is not a standards-compliant sender,
then it is not our business to figure out how the application should
talk to the sender, because that is not an on-the-wire issue. How a
standards-compliant sender should deal with a  non-standards-compliant
facility that doesn't provide the facility and severity (e.g. refusing
the request or substituting default values) is an implementation
detail, not a standard detail.

Note that I don't think there really is a non-standards-compliant
application here, because we don't standardize implementation
interfaces between an application and its sender/engine, but it seems
pretty certain that if a sender needs to calculate a PRI, then it will
need a facility and severity, and any application working with a
standards-compliant sender would be expected to provide that info, so
an application that doesn't provide them might be called
non-standards-compliant, but that would really be stretching. It would
probbaly b emore accurate to call the application
non-standards-supporting.

I do not understand the purpose of these defaults; I do not understand
who uses them for what, and without understanding what the use case
is, I **CANNOT** understand the implications of their designs, and why
an implemneter is required to support them, or how an implementer is
expected to utilize them. 

How can we possibly declare these to be part of an industry-wide
standard?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 18 Dec 2006 10:38:22 +0100

Just one comment...

>      port 512 etc.) by syslog entities.

514 is the IANA assigned port for UPD syslog.

Rainer

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 18 Dec 2006 18:56:59 +0900

> 514 is the IANA assigned port for UPD syslog.
Ooops. That was port 514/UDP. Thanks for pointing that out.

Glenn