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

["Sharon Chisholm" <[e-mail]>]

Hi

I believe these are the only working group last call comments we have
received. Responses inline. Once I think we have reached consensus, I'll
send a list of proposed edits.

Thanks Juergen for the review ... 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Juergen Schoenwaelder
Sent: Tuesday, September 16, 2008 8:35 AM
To: Seely, Ted A [CTO]
Cc: [e-mail]
Subject: Re: [OPSAWG] Begin WG Last Call on
draft-ietf-opsawg-syslog-alarm-00.txt

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

<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>

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>


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.
<Sharon>
You are right that it should not be the introduction. I think a
standalone section is appropriate given this is a fairly short document.
</Sharon>

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.
<Sharon>
We can put SD-IDs in double quotes. I'll try to dig up an example. One
from the Alarm MIB would be good.
</Sharon>

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>

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>

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>

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>

9) You might want to update the acknowledgement to include OPSAWG.
<Sharon>
Will do
</Sharon>

10) The reference X.X should be replaced with something meaningful
    and references need to be updated.
<Sharon>
Oops. Will do.
</Sharon>

/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
_______________________________________________
OPSAWG mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsawg