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

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Sep 05, 2008 at 03:01:02PM -0500, Seely, Ted A [CTO] wrote:
 
> The Chairs are initiating a two week last call on
> draft-ietf-opsawg-syslog-alarm-00.txt.
> 
> Please provide feedback and comments to the list no later than September
> 19th.

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. [...]".

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.

3) I think the mapping (currently section 1.2) should not be part of
   the introduction. I suggest to merge sections 1 and 1.1 into one
   section and to make section 1.2 section 2.

4) Section 2 in the current ID should spell out what the name of the
   SD-ID is. The syslog document does a fine job in putting the name
   of SD-IDs and SD-PARAMs in double quotes. I suggest you follow the
   style used by the SYSLOG specs - and I particularly also like the
   examples at the end of an SD-ID definition.

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.

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.

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?).

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?

9) You might want to update the acknowledgement to include OPSAWG.

10) The reference X.X should be replaced with something meaningful
    and references need to be updated.

/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