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

From: "David Harrington" <[email-masked]>
Date: Wed, 6 Dec 2006 17:50:33 -0500

Hi,

This is a check that my comments of 10/22 have been addressed in
mib-11. 

> 1) There are multiple pages that exceed the maximum allowed lines
per
> page. 
Fixed.

> 
> 2) The headers and footers do not appear to be standard. There
should
> an abbreviated title for easch page after the first.
Fixed.

> 
> 3) the terminology is not consistent with the other WG documents. 
Not fixed. Still a problem. The WG consensus was to use sender,
receiver, relay, and collector. Other document were required to change
to match this terminology. The MIB document uses entity, which is a
term not found in the protocol draft. 

I find this change in terminology makes it difficult to interpret some
objects in the mib module.

> 
> 4) "roles a syslog entity maybe in" would be better as "roles of a
> syslog entity" (although then entity should be changed according to
> #3.
See #3.

> 
> 5) I concur with Bert that the citations in section 2 seem
> inappropriate.
I suggest rewriting the introduction to use the same terminology as
the protocol draft. See #3.

> 
> 6) I find the references to SA-Li, RA-Rj confusing since these are
not
> used in the diagram.
Fixed, but replaced by "entity" which is a problem. See #3.

> 
> 7) "The MIB comprises of four groups" would be better as "The MIB
> contains four groups"
Fixed. However, "group" is a reserved keyword in SMIv2 referring to
compliance, so it should be replaced by "subtree" where that is its
meaning.

> 
> 8) Section 3 has a number of lists. You should decide if the list
> should contain sentences, or makes up one complete sentence. If it
is
> one sentence, then each listed clause should end with a comma, and
be
> consistent in style. If each item is a sentence, then the
introductory
> phrase needs to be a sentence. I recommend making each item a
> sentence, so we  can eliminate the "which" conrstructs.
Fixed.

> 
> 9) "asynchronously monitor" s/b "asynchronously report"
Fixed.

> 10) the name of SyslogMIB or syslogMIB should be consistent in the
> text. I recommend using SYSLOG-MIB, which is the correct name for
the
> MIB module.
Fixed.

> 11) in SyslogSeverity, I recommend removing the second sentnece in
the
> description "The syslog protocol uses the values 0 (emergency) to 7
> (debug)." since this is already spelled out in the SYNTAX clause,
and
> shows that 99 (other) is also used. Why do we need 99? Are other
> values valid?
Partially fixed. When is "other" used?

> 
> 12) SyslogService - can we make this just a service name. The port
> semantics are really ambiguous. How do distinguish a UDP port# from
a
> TCP port#?
Not fixed.

> 
> 13) For consistency with most other MIB modules being developed, I
> suggest defining a top-level breakdown of syslogNotifications (0),
> syslogObjects (1), and syslogConformance (2). Then put syslogSystem
> and syslogDevice under syslogObjects. See RFC4181 appendix D. 
Fixed.

> 
> 14) transportAddressType is designed to be used with specific types
of
> transportAddress. The syslogDefaultTransport object should probably
be
> syslogDefaultTransportType. A transportAddressType seems
inappropriate
> for use with syslogDefaultService, which does not necessarily
resolve
> to one of the enumerated options. We should have a
> syslogDefaultTransport that is a transport address. If we want a
> Default service, that should probably be a separate object.
Partially fixed. 
How will the syslog/TLS transport address be specified in this object?

> 
> 15) some objects are named xxxSeverity, but the description uses
> priority. We need to be consistent with the other documents about
what
> this is called.
Fixed.

> 
> 16) the syslogDefaultMaxMessageSize description really needs work -
> 480 is the minimum maximum size, not the recommended maximum size,
so
> it should not be the default. The maximum message size also may
depend
> on the transport protocol and the target system, so I'm not sure a
> default is a useful object. Who is the user of this default? The
local
> system? If so, then it is an implementation detail and does not need
> to exposed in a mIB object. If it is for use by the remote system,
> then it shouldn't be a default value, but the actual value supported
> by the implementation.
Fixed (removed).

> 
> 17) syslEntOpsTable uses abbreviated elements in the name. I don't
see
> why they need to be abbreviated, or what the name actually means.
The
> description does not mention "ops".
Fixed.

> 
> 18) object prefixes should be consistent for the whole module. The
> DefaultXXX uses syslog as the prefix, but here we use sysl. Why? See
> RFC4181 appendix C for naming guidelines.
Fixed.
> 
> 19) syslEntCtlTable contains static info; does that imply that
> syslEntOpsTable contains dynamci info? Or is syslEntOpsTable about
the
> operational environment, and syslEntCtlTable about control info? The
> descritions should kae the purpose of the table unambiguous.
Fixed.

> 
> 20) In the SNMPv2 effort, we found that using integer indices made
> using the tabels more difficut for human readers. It would be much
> easier for a human to interpret the statistics here is it is easy to
> tell what the systlog entity is. So I recommend using an
> SnmpAdminString as the index. For systems that cannot, for whatever
> reason, determine a human-readable identifier for the index, the
> SnmpAdminString can always be "1", "2", etc.
Not fixed.

> 
> 21) what is the persistence of the index? If syslog entities happen
to
> start in a different order, will the index# refer to the same entity
> after a reboot? If the MIB says they must be persistent across
> reboots, how difficult will that be for the OS that starts the
> applications? What value will the system keep to match up to the
> integer indicies to make sure they remain the same?
Partially fixed. 
Is it important for interoperability to be able to correlate messages
from before a system reboot and after a system reboot? If so, what
object can be used to do this correlation since integer index can
change across reboots? 

I suspect the ControlDescr object might be able to be used, but the
description for ControlDescr does not specify the persistence of that
object.

All objects in the syslogEntityControlTable should probably persist
across reboots if you want the syslog entity to be configured the same
way across reboots.

You have a problem, however. You are using an integer index that does
not persist across reboots. How does the SNMP agent correlate the
persistent configuration parameters with the appropriate application
index after a reboot? How does a remote manager read this table and
understand which row of configuration and monitoring info (like
statistics) refers to which application? 

> 
> 22) syslEntOpsMsgsDropped counts messages that could not be relayed.
> What about messages that cannot be queued for transmission for an
> original sender?
Fixed.

> 
> 23) syslEntOpsMsgsIgnored - where are the "allowed specifications"
> defined? We don't want a value that can be interpreted differently
by
> different entities, because then the values canot be compared across
> systems, or have consistent baselines for comparison across
products,
> etc.  Objects shoud be defined to be interoperable and unambiguous.
Partially fixed. This is still ambiguous, and could be interpreted in
different ways by different implemnenters resulting in
non-interoperability. This needs to be unambiguous as to what gets
counted.
This object counts things outside the "allowed specifications" - again
I ask where are the allowed specfications defined so an implementer
knows what they are?

> 
> 24) syslEntOpsLastMsgDeliveredTime - the system does not know when
the
> message was delivered, only when it was transmitted or received. 
Fixed.

> 
> 25) syslEntOpsLastError talks about "this process". Is this the
syslog
> entity? This needs to be clear and unambiguous, and consistent with
> the terminology in the other WG documents.
I'm confused. Is an entity an application, such as login, or is the
entity the thing that sends syslog messages, such as a syslog daemon,
that sends messages for multiple applications? 
Does the last error refer to the last error seen by the login process,
or by the syslog sender process (e.g. daemon)?

Since entity refers to all the different roles - senders, receivers,
relays, and collectors, does that mean we are keeping "last error"
info at the receiver as well as at the sender, and at the relays as
well? 

> 
> 26) syslEntOpsLastError talks about the last error this process
> "encountered". The definition of encountered needs to be made
unclear
> and unambiguous.
Not fixed. What does "encountered" mean?
Sent/received/relayed/collected?

While we're at it, what exactly does error mean? How do I know when I
am encountering an error? Can I encounter other things, like warnings?
I see that Error is a type of severity. Is that what we ar ecounting?
Do we also want to count criticals, and alerts, and emergencies, etc.
Or is that not what you mean by "encounter an error". 

> 
> 27) what is the persistence of the syslEntOpsReference across
reboots
> of the OS? Across reboots of the SNMP system? If it is not
persistent,
> but the table is, what should the SNMP agent do - delete the
> references? Change the references to match the new SWRunIndex? 

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

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

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 09 Dec 2006 15:26:30 +0900

Dave,
     Thanks for the detailed review. I count a total of
13 + 7 + 4 = 24 issues raised in the three mails. Let
me go through these and try to figure out how to address
the issues, hopefully by 18/12/2006.

      Cheers

      Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 13 Dec 2006 20:45:16 +0900

Hi,
   I have pruned the list of comments and renumbered them.
   The following starts the discussion on the points raised
in Dbh re-Review of -mib-11, part 2.

   Cheers

   Glenn

+---------------------------------------------------------------+
2.1 > > 5) is there a mismatch between transportaddresstype and
     > > syslEntCtlService? Is there a transportAddressType for this
     > > type of
     > > "address"?
     Not fixed.
     I think you are using an enumeration to identify the format of the
     value in the next object, and then using a format in the next object
     that does not match any of the enumerated choices. This is obviously
     wrong.

Response:
     That is not what we are doing.

     syslogEntityControlTransportDomain maps onto a transport domain.
           e.g. transportDomainUdpIpv4
     syslogEntityControlService maps onto a port number
           e.g. 512

     Let me know if I got this wrong.

2.2 > > 6) syslEntCtlConfFileName - using lots of abbreviations in
     > > the  name
     > > makes it hard for people to remember how the words were
     > > abbreviated.
     > > It would be better to use something like syslogEntCtlFilename.
     > > Why do
     > > we need Ent in the name? we never deal with anything other than
     > > entities, do we? syslogControlFile would be much easier to
     > > remember
     > > than syslEntCtlConfFileName.
     Fixed (mostly).

Response:
     What is the remaining problem?

2.3 > > 9) syslEntCtlStorageType - is this definition exactly the
     > >    same as the
     > > StorageType T-C?
     I am not sure this is the same semantics as StorageType T-C.
     Your text is somewhat unclear when it says "backed up by
     non-volatile (permanent)"

Response:
     Will the following help:
       syslogEntityControlStorageType OBJECT-TYPE
           SYNTAX       StorageType
           MAX-ACCESS   read-create
           STATUS       current
           DESCRIPTION
               "This object defines whether the parameters defined in
                this row are kept in volatile storage and lost upon
                reboot or are backed up by non-volatile or permanent
                storage.
                Conceptual rows having the value 'permanent' need not
                allow write-access to any columnar objects in the row.
               "

     That mimics the DESCRIPTION used in DISMAN-MIB e.g.
     smLaunchStorageType

2.4 > > 11) syslEntStarted and syslEntStopped - spell out MO. I don't
     > > understand the second sentence; how does the manager know what
     > > syslEntOpsIndex is used?
     Partially fixed. I still do not understand the second sentence. Can
     you reword this sentence?

Response:
     When a trap is received, the NMS/Operator needs to figure out which
     syslog "entity"  the trap is about. This is done by using the
     syslogEntityOperationsIndex instance identifier of the objects in
     the notification.

     Will the following help?

       "The syslog entity corresponding to the notification will be
        identified by the  syslogEntityOperationsIndex instance identifier
        of the objects in the notification."

2.5 > > 13) why are notifications not mandatory for compliance?
     syslogFullCompliance2 says this means support for writable
     objects and
     notifications, but th enotification group has been left out
     of the manadatory-groups.

     If the intention is to leave out the notification, I would like to
     know why this is desirable.

Response:
     The intention is to leave out the notification.

       syslogFullCompliance2 MODULE-COMPLIANCE
           STATUS  current
           DESCRIPTION
               "The compliance statement for SNMP entities which
                implement the SYSLOG-MIB with support for writable
                objects. Such an implementation can
                be both monitored and configured via SNMP.
               "
           MODULE -- this module
           MANDATORY-GROUPS {
               syslogDefaultGroup,
               syslogEntityOperationsGroup,
               syslogEntityControlGroup
           }
           ::= { syslogCompliances 2 }

     The reason is to retain the possibility of a compliant
     implementation that does not support notifications.

2.6 > > 14) The MIB module exposes some info from syslog, such as
     > > last error.
     > > The security considerations talk about securing snmp, but
     > > that does
     > > not make sense if you do not also secure the syslog transport.
     > > The
     > > security considerations should recommend securing syslog to
     > > match the
     > > snmp security.
     Not fixed.

Response:
     To me that appeared to be out of scope. That seems to be a matter
     for the "security considerations" for syslog transport. No?

     Will something like the following suffice:

       "Under some circumstances securing SNMP will not make sense if
        the syslog transport is not secured. It is recommended that the
        syslog transport be secured to match the security level of SNMP."

2.7 > > 17) I suspect you are not usinng xml2rfc. If not, you need to
     > > make
     > > sure all the boilerplates are up-to-date. Please check the
     > > funding
     > > statement and the intellectual property clauses.
     Partially fixed. Needs updated boilerplates.

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 13 Dec 2006 12:56:30 -0500

Hi,

Dbh> If the intention is to leave out the notification, I would like
to
     know why this is desirable.
Glenn>  The reason is to retain the possibility of a compliant
     implementation that does not support notifications.

This still does not explain why this is desirable. Who wants this
feature?

It may be desirable to implementers who have not chosen to implement
notifications, so they can market their products as being
IETF-compliant, but we are NOT here to help marketing departments
claim compliance for their  implementations by lowering the standards
to match their implementations.

The majority of snmp agents are based on either the commerical toolkit
from SNMP research (or other commercial snmp toolkits), or the
NET-SNMP (nee CMU-SNMP) toolkit. These already support notifications,
and the objects carried in the notification are required for
compliance, so I think it should be pretty simple to support the one
notification. So I don't see a strong benefit for an implementer to
not support the notification.

I especially do not see the benefit of making this optional in the
standard. Keep in mind that our job here is NOT to define a
specification that allows as many incompatible implementations to
claim compliance as possible. Our job here is to set some standards -
a minimum level of support for a common set of features to provide
multi-vendor and vendor-neutral interoperability. Having some
implementations support notfications and others not support
notifications negatively impacts interoperability.
Non-interoperability is NOT a desirable feature.

So I STRONGLY question the need for a compliance level to allow the
lack of support for the notification. 

-- Let me approach the question from a different angle. 

Does the WG believe that this notification is so useless that most
implementers will not implement it? Is this a nice-to-have but not
really necessary feature in the standard? If so, then we should simply
remove it from the standard.

My personal opinion is that this would be a useful feature, and should
not be optional. It should be part of the mandatory compliance, and an
implementation without it should NOT be allowed to claim compliance to
the standard. 

dbh

> -----Original Message-----
> From: Glenn M. Keeni [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 6:45 AM
> To: [email-masked]
> Subject: Re: [Syslog] Dbh re-Review of -mib-11, part 1,2,3
> 
> Hi,

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 14 Dec 2006 20:15:42 +0900

Hi,
    The following starts the discussion on the points
raised in Dbh re-Review of -mib-11, part 1. There is
a basic issue about terminology (points 1.1,1.2,1.3,
1.4)  and another 1.9 about the nature and usage of
indices on which the WG definitely needs to provide
input.

     Cheers

     Glenn

+---------------------------------------------------+
1.1 > > 3) the terminology is not consistent with the
     other WG documents.
     Not fixed. Still a problem. The WG consensus was
     to use sender,
     receiver, relay, and collector. Other document were
     required to change
     to match this terminology. The MIB document uses entity,
     which is a term not found in the protocol draft.

     I find this change in terminology makes it difficult
     to interpret some objects in the mib module.

Response:
     We have a single MIB module for all the roles of a syslog
     "entity" - sender, receiver, relay and collector.
     I do not see any problem with this generic nature of the
     MIB, as yet.

     Let me know about the specific objects that are difficult
     to interpret. We may try the following:
        Use the generic "syslog entity" when the discussion
        applies to all the roles
        Use the role(s) explicitly "syslog sender", "syslog
        receiver", etc. when the discussion does not apply to
        all the roles.
        Add a  statement to that effect in the early part of
        the text.

     Any other suggestions?

1.2 > > 4) "roles a syslog entity maybe in" would be better as "roles of a
     > > syslog entity" (although then entity should be changed according to
     See #3.
Response:
     See #1.
1.3 > > 5) I concur with Bert that the citations in section 2 seem
     See #1.

1.4 > > 6) I find the references to SA-Li, RA-Rj confusing since these are
     not
     See #1.

1.5 > > 7) "The MIB comprises of four groups" would be better as
     > > "The MIB

Response.
     Done.

1.6 > > 11) in SyslogSeverity, I recommend removing the second sentnece
     > > in the
     > > description "The syslog protocol uses the values 0 (emergency)
     > > to 7 (debug)." since this is already spelled out in the SYNTAX
     > > clause,andshows that 99 (other) is also used. Why do we
     > > need 99? Are other
     > > values valid?

Response.
     "other" will be used to count messages that do not have severity in
     the range 0-7. The syslog protocol specs (-19.txt) does not disallow
     such messages.

1.7 > > 12) SyslogService - can we make this just a service name. The
     > > port semantics are really ambiguous. How do distinguish a UDP
     > >port# from a TCP port#?
     Not fixed.

Response.
     The syslogEntityControlTransportDomain specifies the transport e.g.
     transportDomainUdpIpv4.

1.8 > > 14) transportAddressType is designed to be used with specific
     > > types of
     > > transportAddress. The syslogDefaultTransport object should
     > > probably be
     > > syslogDefaultTransportType. A transportAddressType
     > > seems inappropriate
     Partially fixed.
     How will the syslog/TLS transport address be specified in this
     object?

Response.
     A syslog TLS transport domain will be defined. E.g. something like
     SyslogTLSTransportDomain. We will specify that as the
     syslogEntityControlTransportDomain.
     Thus, we will have something like:
          syslogEntityControlTransportDomain : SyslogTLSTransportDomain
          syslogEntityControlService: SyslogTLSPort

1.9 > > 20) In the SNMPv2 effort, we found that using integer indices
     > > made using the tabels more difficut for human readers. It would
     > > be much easier for a human to interpret the statistics here is
     > > it is easy to tell what the systlog entity is. So I recommend
     > > using an SnmpAdminString as the index. For systems that cannot,
     > >  for whatever reason, determine a human-readable identifier for
     > > the index, theSnmpAdminString can always be "1", "2", etc.
     Not fixed.

Response.
     The human readable identifier/description is there in
     syslogEntityControlDescr. I think that any NMS can easily handle
     this and make the table nicely "readable" to the user.
     I accept that the primitive snmpget/snmpwalk type applications
     which show OIDs will be difficult to "read".
     I will not recommend mixing indices and descriptions - that may
     lead to constraints on or, inappropriate usage of both indices and
     descriptions.
     If the working group wants descriptive indices, that is not a big
     deal.

1.10> > 21) what is the persistence of the index? If syslog entities
     > > happen to
     Partially fixed.
     Is it important for interoperability to be able to correlate
     messages
     from before a system reboot and after a system reboot? If so, what
     object can be used to do this correlation since integer index can
     change across reboots?

     I suspect the ControlDescr object might be able to be used, but the
     description for ControlDescr does not specify the persistence of
     that object.

     All objects in the syslogEntityControlTable should probably persist
     across reboots if you want the syslog entity to be configured the
     same way across reboots.

     You have a problem, however. You are using an integer index that
     does

Response.
     The syslogEntityControlDescr will be used by the application/NMS
     to correlate the index and the target syslog application. It is
     the user/admin responsibility to use appropriate
     syslogEntityControlDescr.

1.11> > 23) syslEntOpsMsgsIgnored - where are the "allowed
     > > specifications"
     > > defined? We don't want a value that can be interpreted
     > > differently by
     Partially fixed. This is still ambiguous, and could be interpreted
     in different ways by different implemnenters resulting in
     non-interoperability. This needs to be unambiguous as to what gets
     counted.
     This object counts things outside the "allowed specifications" -
     again
     I ask where are the allowed specfications defined so an implementer
     knows what they are?

Response.
     The allowed specifications are in the protocol document. There are
     several MUST clauses. Some clauses explicitly mention that if the
     MUST condition is not met the message MAY be discarded, some don't.
     E.g.  Sec. 6.1 Message length, Sec. 6.2 HEADER.

1.12> > 25) syslEntOpsLastError talks about "this process". Is this the
     I'm confused. Is an entity an application, such as login, or is the
     entity the thing that sends syslog messages, such as a syslog
     daemon, that sends messages for multiple applications?
     Does the last error refer to the last error seen by the login
     process, or by the syslog sender process (e.g. daemon)?

Response.
     Let me try it this way. The MIB is about syslog entities- syslog
     senders, syslog receivers, syslog relays etc. We do not need to care
     whether the Sender is a syslog daemon or a mail application as long
     as it is sending and/or receiving syslog messages.
     Having said that, I agree that the description of the lastError is
     difficult to interpret.
     Will the following help?
         "A description of the last error related to sending, receiving
          or processing a syslog message that was encountered by this
          syslog entity.
         "

1.13> > 26) syslEntOpsLastError talks about the last error this process

     While we're at it, what exactly does error mean? How do I know when
     I am encountering an error? Can I encounter other things, like
     warnings? I see that Error is a type of severity. Is that what we
     ar ecounting? Do we also want to count criticals, and alerts, and
     emergencies, etc.
     Or is that not what you mean by "encounter an error".

Response.
     see #12 above.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 14 Dec 2006 15:25:50 +0100

So far, just one comment...

>      the range 0-7. The syslog protocol specs (-19.txt) does 

Actually, -syslog-protocol disallows this by the way the PRI value is
specified (this was different in previous versions of the I-D). In
short: PRI MOD 8 is severity. So if a severity greater than 7 would be
given, it would actually modify the facility. See 6.2.1:

--
  The Priority value is calculated by first multiplying the Facility
  number by 8 and then adding the numerical value of the Severity.
--

Rainer

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 10:24:02 -0500

Hi,

I don't think -protocol- spelled out the restriction clearly that
severity could only be 0-7. The document states that the 0-7
severities listed were not normative. 

Now that Rainer pointed this out, I do realize that an implementer of
the PRI calculation code might recognize that the PRI calculation
implies such a restriction. But syslog is often implemented as a
system of independently-implemented pieces (daemon vs application, for
example), and not all of them will need to implement the PRI
calculation code, so it may not be obvious (just as it was not obvious
to Gleen who has been working with this WG for a long time).

Before we publish the spec as an RFC, is the WG satisfied with this
restriction of severity to 0-7, and is the WG satisfied that this is
clear and unambiguous in our spec?

If the WG believes the 0-7 restriction is unacceotable, we will need
to pull the draft back from the IESG and make changes to PRI.

If the WG accepts the 0-7, but thinks the draft is not clear and
unambiguous, then we could provide clarifying text as part of WGLC
without pulling the draft back from the IESG.

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

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Thursday, December 14, 2006 9:26 AM
> To: Glenn M. Keeni; [email-masked]
> Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 14 Dec 2006 16:31:27 +0100

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, December 14, 2006 4:24 PM
> To: [email-masked]
> Subject: [Syslog] severity
> 
> Hi,
> 

The last time a version was submitted (roughly a year ago), it was
pulled back *because* PRI calculation was different from legacy syslog.
This was the whole point in that discussion. And, yes, then there wasn't
this restriction. IMHO we can not change that without going into a
"deep-inconsistency-loop" of WG decisions.
> without pulling the draft back from the IESG.

This is what I'd recommend. A simple sentence like "severities MUST be
in the range of 0 to 7" should do the job.

Rainer

---

From: "tom.petch" <[email-masked]>
Date: Thu, 14 Dec 2006 17:35:45 +0100

----- Original Message ----- 
From: "Rainer Gerhards" <[email-masked]>
To: "David Harrington" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 14, 2006 4:31 PM
Subject: RE: [Syslog] severity

Rainer
<tp>
I agree with Rainer

Tom Petch
</tp>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 16:41:56 -0500

Hi,

[speaking as coc-ahir]
We need WG input on this. 
Please look at mib-11 and decide whether "entity" is appropriate. 
Glenn has changed the terminology in many places to be more consistent
than previous revisions. 

In the TLS document, Miao and Yuzhi tried to use a generic term for
any role and WG consensus was to change the document to use the
sender/receiever/relay/collector terminology. Does the same thing need
to be done here?
[co-chair end]

[speaking as contributor (and MIB Doctor)]
I have mixed feelings on this issue.

I personally think not having a generic term makes it harder to write
documents and design mib modules that can be applied to any of the
roles. In SNMPv3, we deliberately moved away from different processing
for different roles and toward a common "entity" that could act in
different roles.  

When designing a MIB module to encompass multiple roles as one entity,
it is very important to review the design from the perspective of each
of the roles. For example, it may make sense to count messagesSent if
you are implementing a sender or relay, but not if you are
implementing a reciever or collector. It will be a poor MIB module
design if it makes a great deal of sense for implementers to only
implement some of the objects in a table that is
mandatory-to-implement for compliance. Having objects that only make
sense for certain roles and not others in one common table will
encourage non-compliant implementations.

On the other hand, defining the MIB module to contain four tables to
model the sender configuration, and the receiver configuration, and
the relay configuration, and the collector configuration, even though
all four tables would contain identical information is simply
ridiculous design.

I do not like having one set of terminology in the protocol
specifications, and a different set of terminology in the management
interface, because it makes it harder for operators to interpret the
data in the MIB module.

The WG needs to review the MIB module design and determine what makes
protocol sense.
[contributor end]

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 17:59:22 -0500

Hi Glenn,

Maybe I misunderstand how transportDomain and transportAddress are
supposed to work. I have consulted one of the authors of RFC3419 to
make sure my understanding is correct. 

As I read RFC3419, it seems to me that transportDomain and
transportAddress form a discriminated union; they form a corresponding
pair. So your response to my concern did not answer the question.

>From RFC3419:
transportDomainUdpIpv4 OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "The UDP over IPv4 transport domain.  The corresponding
         transport address is of type TransportAddressIPv4 for
         global IPv4 addresses."
    ::= { transportDomains 1 }

TransportAddressIPv4 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d:2d"
    STATUS      current
    DESCRIPTION
        "Represents a transport address consisting of an IPv4
         address and a port number (as used for example by UDP,
         TCP and SCTP):

          octets       contents         encoding
           1-4         IPv4 address     network-byte order
           5-6         port number      network-byte order

         This textual convention SHOULD NOT be used directly in object
         definitions since it restricts addresses to a specific
format.
         However, if it is used, it MAY be used either on its own or
         in conjunction with TransportAddressType or TransportDomain
         as a pair."
    SYNTAX      OCTET STRING (SIZE (6))

When syslogEntityControlTransportDomain contains the value
transportDomainUdpIpv4, into which object in the syslog mib does one
put the corresponding transport address of type TransportAddressIPv4?

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 19:06:12 -0500

Hi Glenn,

>      The syslogEntityControlTransportDomain specifies the 

I am looking for an unambiguous format for the value of this field.
SyslogService  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The service name or port number that will be used to
            send and/or receive messages.
            The service name must resolve to a port number on the
            local host.
           "
       SYNTAX OCTET STRING (SIZE (0..255))

A service name is presumably a string; a port number is a decimal
value.
When put into this object, MUST the port number be represented as an
ASCII string? If so, the description does not say so.
If a service name is specified, is this done as an ASCII string or a
UTF-8 string? The description doesn't say. If it is not UTF-8, why
not?

If the service name must resolve to a port number on the local host,
how will a remote NMS get that resolution from the local host?
Wouldn't it be simpler to put only a port number in the managed
object? 

If you restricted it to a port number, then implementers only need to
provide memory for an unsigned32 value (4 octets) rather than 255
octets.

dbh

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 19:26:51 -0500

Hi Glenn, 

>      > > different entities, because then the values canot be
compared
>      > > across

We want to ensure consistency in what is counted; Will you please
enumerate which conditions should be counted in this object. List
which MUST clauses are relevant to this object, and which are not, and
make it clear that ONLY these conditions should be counted. 

We should consider counting these conditions separately rather than
counting them in an aggregated count. That way, a remote system could
tell what the problem is, whereas "outside the allowed specifications"
only says "there are one or more problems being encountered; we'll
tell you how many problems have been encountered, but not which
problems have been encountered."

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

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 19:37:24 -0500

>      What is the remaining problem?

syslogEntityControlConfFileName uses an abbreviation for
Configuration.
The abbreviation could have been Conf or Config or Cfg. 
This makes it harder to remember.
I can live with this.
You can mark it as fixed.

dbh

---

From: "David Harrington" <[email-masked]>
Date: Thu, 14 Dec 2006 20:24:19 -0500

>      That mimics the DESCRIPTION used in DISMAN-MIB e.g.
That will do, yes.

>         of the objects in the notification."

Yes. Thanks.

>         syslog transport be secured to match the security 

Let me just withdraw my comment. If the IESG wants something here,
they can request it. 
>      http://tools.ietf.org/tools/idnits/
Good.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 15 Dec 2006 08:19:25 +0100

David,

I went through my notes. Retaining PRI as is is actually a charter item:

---
Reviews have shown that there are very few similarities between the
message formats generated by heterogeneous systems. In fact, the only
consistent commonality between messages is that all of them contain
the <PRI> at the start. Additional testing has shown that as long as
the <PRI> is present in a syslog message, all tested receivers will
accept any generated message as a valid syslog message. In designing a
standard syslog message format, this Working Group will retain the
<PRI> at the start of the message and will introduce protocol
versioning. 
---

So we can not change the PRI representation (and thus the representation
of severity).

>From what I see in my notes, we simply copied over the 3164 text on PRI
without any further thinking after we had set on this charter. I think
this is the primary reason that it was not better spelled out and be
undetected until now.

Rainer

> > > short: PRI MOD 8 is severity. So if a severity greater 
> than 7 would
> > be

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 15 Dec 2006 06:25:10 -0800 (PST)

Hi,

Rainer has it right.  I agree that a simple note as Rainer suggests will 
do it.

Thanks,
Chris

---

From: "tom.petch" <[email-masked]>
Date: Fri, 15 Dec 2006 15:17:44 +0100

This is also tied up with the scalar/table question.  If we had a scalar MIB
module, then much of my difficulty would vanish.

If we keep the table, then it should not be of entities.  As you point out,
SNMPv3 has given the word 'entity' a specific meaning and I think it wrong to
re-use the word to mean something different in a MIB module (it would be ok if
this were SMTP or BGP); I find the use of 'managed entity' in DESCRIPTION
clauses especially confusing.  I like 'daemon' (not seeing that as being in any
way limited to a particular role) or 'device', which is already in use in other
syslog documents.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Fri, 15 Dec 2006 13:23:06 -0500

Hi,

[posting as a contributor]

Tom mentions that we should not use the term entity here, because it
conflicts with the SNMP usage of that term. Since this is a MIB module
designed for use in an SNMP environment, that is a really good point.
It would hurt us to have conflicts between the terminology used to
describe syslog things, and the terminology used to describe SNMP
things in this mib module.

Which raises an interesting question. Is the terminology used for
syslog and the terminology used for SNMP compatible? Could we make
them more compatible (without modifying any of the other syslog
documents?)

One approach to consider would be to use the RFC3411 "descriptive"
architecture to describe the syslog architecture. The processes of
preparing messages, dealing with message security, and sending
messages via different transports are all services provided by the
"engine": 

+-------------------------------------------------------------------+
   |  SNMP entity
|
   |
|
   |  +-------------------------------------------------------------+
|
   |  |  SNMP engine (identified by snmpEngineID)                   |
|
   |  |                                                             |
|
   |  |  +------------+                                             |
|
   |  |  | Transport  |                                             |
|
   |  |  | Subsystem  |                                             |
|
   |  |  +------------+                                             |
|
   |  |                                                             |
|
   |  |  +------------+ +------------+ +-----------+ +-----------+  |
|
   |  |  | Dispatcher | | Message    | | Security  | | Access    |  |
|
   |  |  |            | | Processing | | Subsystem | | Control   |  |
|
   |  |  |            | | Subsystem  | |           | | Subsystem |  |
|
   |  |  +------------+ +------------+ +-----------+ +-----------+  |
|
   |  +-------------------------------------------------------------+
|
   |
|
   |  +-------------------------------------------------------------+
|
   |  |  Application(s)                                             |
|
   |  |                                                             |
|
   |  |  +-------------+  +--------------+  +--------------+        |
|
   |  |  | Command     |  | Notification |  | Proxy        |        |
|
   |  |  | Generator   |  | Receiver     |  | Forwarder    |        |
|
   |  |  +-------------+  +--------------+  +--------------+        |
|
   |  |                                                             |
|
   |  |  +-------------+  +--------------+  +--------------+        |
|
   |  |  | Command     |  | Notification |  | Other        |        |
|
   |  |  | Responder   |  | Originator   |  |              |        |
|
   |  |  +-------------+  +--------------+  +--------------+        |
|
   |  +-------------------------------------------------------------+
|
   |
|
 
+-------------------------------------------------------------------+

One engine can support multiple "SNMP applications". SNMP applications
are the things that define the roles, e.g. a notification originator
(Cf: a syslog sender), a notification receiver (Cf: a syslog
receiver), and a proxy forwarder (Cf: syslog relay). 

The RFC3411 architecture also supports command generator (that makes
requests) and command responder (that processes requests and responds)
that do not apply to syslog.

The "SNMP applications" describe functionality that is combined with
other functionality provided by software or devices; to put this in
syslog terms, the facilities would utilize the "SNMP application"
style functionality to generate, receive, or relay messages.

Since this is a MIB document, we could provide an introductory section
that maps from the syslog terminology to the RFC3411 terminology. Most
users of the MIB will already have some knowledge of the SNMPv3
concepts. We could use the picture above. modified to describe the
syslog architecure:

+-------------------------------------------------------------------+
   |  Syslog entity
|
   |
|
   |  +-------------------------------------------------------------+
|
   |  |  Syslog engine                                              |
|
   |  |                                                             |
|
   |  |  +------------+                                             |
|
   |  |  | Transport  |                                             |
|
   |  |  | Subsystem  |                                             |
|
   |  |  +------------+                                             |
|
   |  |                                                             |
|
   |  |  +------------+ +------------+ +-----------+                |
|
   |  |  | Dispatcher | | Message    | | Security  |                |
|
   |  |  |            | | Processing | | Subsystem |                |
|
   |  |  |            | | Subsystem  | |           |                |
|
   |  |  +------------+ +------------+ +-----------+                |
|
   |  +-------------------------------------------------------------+
|
   |
|
   |  +-------------------------------------------------------------+
|
   |  |  Application(s)                                             |
|
   |  |                                                             |
|
   |  |  +-------------+  +--------------+  +--------------+        |
|
   |  |  | Syslog      |  | Syslog       |  | Syslog       |        |
|
   |  |  | Sender      |  | Receiver     |  | Relay        |        |
|
   |  |  +-------------+  +--------------+  +--------------+        |
|
   |  |                                                             |
|
   |  +-------------------------------------------------------------+
|
   |
|
 
+-------------------------------------------------------------------+

I think with the addition of entity and engine to the terminology,
this picture  does a good job of describing the syslog architecture,
and would make it clearer what the "things" are that are modeled in
the syslog mib module. 

It would however, only be clearer to a degree. The table in the mib
document would likely model one or more *engines* (daemons that serve
multiple applications) in a *NIX environment, but would model multiple
*entities* in a Windows environment. And sometimes, the table would
include multiple engines and multiple entities. We need to model the
real world.

As Tom points out, one way to avoid this is to develop a scalar mib
module. Such a mib module would only model one engine at a time. It
might be immaterial  whether that engine services one or more
applications. It could however be important to know that, so we might
need to model the engine as a scalar, and supplement that with a table
of applications (facilities?) serviced by the one engine, and
statistics related to that usage. 

If a system had more than one syslog engine operating, a single SNMP
engine could service them all, using different SNMP contexts to model
them. But this brings us back to where we are now, with the reality
that some engines are contained in complete entities, and some engines
are not.

<soapbox> 
I have a bias toward an approach using RFC3411. Not only am I one of
the authors of RFC3411, I am trying to migrate SNMP, syslog, ipfix,
and netconf to all use a common terminology, where possible, to
describe their concepts and functionalities, so it is easier to
compare, and possibly reuse, some design decisions.

It might also be possible to reuse some specifications. All of these
protocols are looking to utilize secure transports (e.g., SSH and
TLS). It would be a good thing if they all used similar approaches, so
operators only had to configure one secure transport protocol (e.g.
TLS) in one consistent manner to secure all four NM protocols. 

All four protocols need data modleing capabilities, to different
degrees, and if the IETF NM community could agree to all use, say XML
for encoding, and XSD for modeling, it would be easier to reuse and/or
correlate the data. Netconf is looking at a notification design that
can carry syslog info and snmp info; if the syslog SDEs can be
translated into XML, and MIB data can be translated into XML, and
ipfix data can be transalted into XML, (e.g., via XSLT transform
tools), then it might be much easier for operators to correlate the
data of the four NM protocols.
</soapbox>

I am only suggesting here that we use a diagram and entity/engine
terminology similar to RFC3411 terminology to make the MIB module
easier to understand. Doing so would place no constraints on syslog
designers, implementers, or users (except of course, the designers of
this mib module).

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

> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, December 15, 2006 9:18 AM
> To: David Harrington; 'Glenn M. Keeni'; [email-masked]
> Subject: Re: [Syslog] Mib terminology and MIB design
>

---

From: "tom.petch" <[email-masked]>
Date: Mon, 18 Dec 2006 11:50:29 +0100

An architecture is very useful for me as long as it captures the essence of the
engineering being architected, and this I am becoming increasingly unclear
about.

My use case is masses of dumb devices that just about support syslog (with a
struggle) feeding a small number of powerful servers.  Others on the list talk
of servers as senders while the existence of relays is highly plausible.

I now know of the Windows case of multiple applications each as its own sender
but you now seem to be extending that to a host (to use the IP term) with
multiple syslog processes each of which can be sender/relay/collector; and that
seems an over-complication which noone is asking for.

We already have an architecture - sender, relay, collector - which allows for a
combined collector/relay and sender/relay (as defined in -protocol).   I think
we need a good reason to move away from that.

Note in passing that -protocol uses the terms 'application' and 'system'

Tom Petch