Re: [OPSAWG] Begin WG Last Call on draft-ietf-opsawg-syslog-alarm-00.txt

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Oct 27, 2008 at 09:30:17AM -0400, Sharon Chisholm wrote:
 
> I have read the document and below are my comments.
> 
> 1) I think the title and the abstract should better indicate what the
>    scope fo the document is. As far as I understand it, it is all
>    about representing X.733 alarms in SYSLOG messages. So perhaps the
>    title should be "Representing ITU X.733 Alarms in SYSLOG" and the
>    abstract should read "This document describes how to represent
>    X.733 alarm information in SYSLOG. [...]".
> 
> <Sharon>
> The scope of the document is alarms in syslog, not specifically X.733.
> Yes, pretty much all alarm work in the industry I've seen can be mapped
> back to X.733 and X.736, but I don't think referencing this in the title
> is accurate. We have one field that was introduced in the Alarm MIB in
> this mapping and may wish to extend the document in the future with
> other alarm information.
> </Sharon>

These are the SD-IDs defined in the document:

alarmedResource
probableCause     - maps to IANAItuProbableCause which talks about X.733
perceivedSeverity - text talks about X.736 and ituAlarmPerceivedSeverity
		    is part of the ITU-ALARM-MIB
eventType         - maps to IANAItuEventType and this refers to X.733
		    and X.736 and M.3100
trendIndication	  - text talks about X.733 and ItuTrendIndication itself
		    refers to X.733 and M.3100
resourceMapping

If I count then 4/6 SD-IDs (a pretty decent majority) are specific to
ITU / X.733 and friends. I think truth in advertising is a good thing.
 
> 2) The last sentence of section 1 is confusig; the document really
>    maps ITU perceived severity to SYSLOG severity and not the other
>    way round. So I suggest to replace
> 
>    [...] This memo defines a set of SD-PARAM to support
>    logging and defines a mapping of syslog severity to the severity of
>    the alarm.
> 
>    with
> 
>    [...] This memo defines a set of SD-PARAM to support logging and
>    defines a mapping of ITU X.733 perceived security values to SYSLOG
>    severity values.
> 
> <Sharon>
> (The mapping we are referring to is the one in section 1.2.) The table
> sort of provides a two way mapping since it should be fairly obvious to
> a human, but perhaps not a machine, whether to map a  Notice to be
> 'indeterminate' or 'cleared'. Perhaps an update to the text to clarify
> this would be helpful?
> </Sharon>

I am confused. I thought the purpose of the document is to define
SYSLOG SD-IDs for representing alarms. The abstract says:

   This document describes how to send alarm information in syslog.  It
   includes the mapping of ITU perceived severities onto syslog message
   fields.

So either the whole document is wrong or the sentence I quoted is
wrong.
 
> 5) I fail to see the difference between alarmedResource and
>    resourceMapping. Quoting from the two definitions:
> 
>      This item uniquely identifies the resource under alarm within the
>      scope of a network element.
> 
>      This item uniquely identifies the resource under alarm within the
>      scope of a network element.
> 
>    OK, the resourceMapping has an additional constraint requiring this
>    to be an OID or follow similar semantics (I am not quite sure what
>    that means - does this still imply the OID format? And how is the
>    OID represented in the first place?). I am not sure how useful this
>    is in practice. Perhaps some examples would help me to find both
>    useful.
> <Sharon>
> The two pieces of information point at the same thing, but in two very
> different ways. This is fairly common to do in practice. One is very
> SNMP-ish and maps to the Alarm MIB. The other is more syslog-ish and
> more string-based. The former SNMP-ish ones allows you to cross
> reference with information obtained from SNMP. 
> </Sharon>

This needs to be described more clearly. As it stands, it remains
unclear to me how people should come up with interoperable
implementations. And as I said, some examples might help to better
understand this.

> 6) The usage of the TC labels makes sense. This of course assumes that
>    the labels are never changed. The SMIv2 actually allows to change
>    labels (although this is a really bad idea in most cases). Since
>    you import labels from IANA maintained modules, perhaps IANA should
>    be aware that these labels have significance and should not be
>    changed. OK, I am making up a story here but I thought I at least
>    mention that there is this implicit assumption here that the labels
>    of enumerations are somewhat stable.
> <Sharon>
> Should we add something in the IANA considerations section?
> </Sharon>

I don't know if this solves the problem as you have to update the IANA
rules of some other document.

> 7) I think some text should be added to better describe the
>    relationship to X.733 (what subset of X.733 is covered by the new
>    SD-ID?) and RFC 3877 (how does the information captured in the
>    SD-ID relate to the information captured in the RFC 3877 MIB
>    modules?).
> <Sharon>
> Like what? This document reports information from the Alarm MIB and the
> alarm MIB reports information from X.733 and X.736?
> </Sharon>

Text is needed to describe which portions are mapped since obviously
there is not a 1:1 mapping. I don't find this particularly clear nor
do I understand by which criteria the SD-IDs have been selected from
the MIB modules (if that is there origin).

> 8) I am not sure how to interpret the last paragraph in the security
>    considerations. SYSLOG in general does not seem to have a notion
>    who the receiver is unless you run it over a secure transport.  And
>    even if I am lucky to know the identity of the receiver (well I
>    actually can only reasonably know the identity of the next hop
>    which might be a proxy), then does the paragraph require that the
>    whole SD-ID is removed from the message or only selected SD-PARAM
>    or is the whole message dropped?
> <Sharon>
> Just like in SNMP, we only assume next-hop. Security considerations
> sections are hard to write. In NETCONF, we don't drop the entire message
> if people don't have permissions. I'm not sure how much of an access
> model syslog has defined so I'd prefer to leave it vague. I'm not sure
> what all we should say.
> </Sharon>

SNMP has a well defined access control models and well defined
security models and well defined proxy behaviour. This is not the case
for SYSLOG and also not for NETCONF. Perhaps the security
considerations just need to spell this out by stating clearly that
there is no standardized access control model for SYSLOG and hence the
ability to filter alarms based on a notion of a receiver identity is
at best implementation specific.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
OPSAWG mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsawg