Subject: Re: [OPSAWG] Begin WG Last Callondraft-ietf-opsawg-syslog-alarm-00.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 15 Dec 2008 13:03:11 -0500

Hi

Here is the complete list off issues and proposed resolutions. It
includes several specific text proposals that have not been included in
earlier emails. If it is agreed these resolve the raised issue I will go
ahead and make these changes and then I think we are good to send the
document to the IESG.

1) I think the title and the abstract should better indicate what the
scope of 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. [...]".
*	Proposed Resolution: Keep the title the same since there are
objects in the document that don't come from X.733 and there may be more
in the future. But ensure this relationship is included in the abstract.
*	Specific Text
*	This document describes how to send alarm information in syslog.
It includes the mapping of ITU perceived severities onto syslog message
fields and a number of alarm-specific SD-PARAM definitions from X.733
and the IETF Alarm MIB. 

2) The last sentence of section 1 is confusing; 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.
*	Proposed Resolution:  
*	See text for issue #1

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.
*	Proposed Resolution: Make this a standalone section. 
*	This change was done in -01

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.
*	Proposed Resolution: 
*	Make this change 
*	Forgot to do this in -01. 

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.
*	Proposed Resolution: 
*	Add the following text
*	Both the alarmedResource and the resourceMapping parameters
point at the resource experiencing the alarm, but the resourceMapping
has syntactic constraint requiring this  to be an OID.  For example, in
the case of an interface, resourceMapping might take a value of
1.3.6.1.2.1.2.2.1.1.42, which is ifIndex with an instance value of 42.
This makes it easy to correlate this syslog alarm with any SNMP traps
that are received or to use SNMP to get additional information about
this interface.

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.
*	Proposed Resolution:
*	 No change in text

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?).
*	Proposed Resolution:
*	 Add some description
*	The Alarm MIB (RFC 3877) included mandatory alarm fields from
X.733 as well as information from X.736. In additional, the Alarm MIB
introduced its own alarm fields. This memo reuses terminology and fields
from the Alarm MIB.

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?
*	Proposed Resolution: 
*	Add the following text
*	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

9) You might want to update the acknowledgement to include OPSAWG.
*	Proposed Resolution: Make this change 
*	Done in -01

10) The reference X.X should be replaced with something meaningful and
references need to be updated.
*	Proposed Resolution: Make this change
*	Done in -01
 
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chisholm, Sharon (CAR:ZZ00)
Sent: Tuesday, November 18, 2008 11:11 AM
To: [email-masked]
Cc: [email-masked]; Seely, Ted A [CTO]
Subject: Re: [OPSAWG] Begin WG Last
Callondraft-ietf-opsawg-syslog-alarm-00.txt

Hi

Thanks again for the input.

Comments inline .... 

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]]
Sent: Monday, November 03, 2008 4:04 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Seely, Ted A [CTO]; [email-masked]
Subject: Re: [OPSAWG] Begin WG Last Call
ondraft-ietf-opsawg-syslog-alarm-00.txt

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.

<Sharon>
Agreed. I would suggest that not including it in the title and including
it in the abstract is the most accurate.
</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>

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.
<Sharon>
The document has two purposes really. One is to provide that severity
mapping and the other is to define some standard SD-IDs for holding
alarm information. I think collectively these describe how to send
alarms via syslog, but perhaps there are additional things we would need
to define in order to make this claim? Other than repeating a lot of
information from the Alarm MIB and other known sources, I'm not sure
what else that would have to add. I suppose I could replace this
sentence with the something more along the lines of my first two
sentences in this paragraph and that would be more accurate.
</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>

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.
<Sharon>
Ok. I can come up with some text and examples. For some history,
originally we only had the SNMP-ish one and then we received feedback
that people wanted a more syslog-ish field and wanted that one to be the
mandatory one.
</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>

I don't know if this solves the problem as you have to update the IANA
rules of some other document.
<Sharon>
So, are we OK if we just keep this in minds ourselves?
</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>

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).
<Sharon>
Ok. I believe the criteria was to pull in the mandatory objects. I'll
work on some text.
</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>

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.

<sharon>
I like that text. I'll include it.
</sharon>

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: [email-masked] (Scott O. Bradner)
Date: Mon, 15 Dec 2008 13:09:26 -0500 (EST)

seems fine to me

Scott

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Dec 2008 19:50:02 +0100

> and defines a mapping of ITU X.733 perceived security values to SYSLOG

So is the sentence in question going to be changed or not?
 
> that are received or to use SNMP to get additional information about

If this is the meaning, then I suggest to name resourceMapping to
alarmedResourceOID and I like to add that an OID by itself is not
sufficient to identify something in SNMP land since OIDs are scoped by
a context. So I guess this needs more work to be useful. And what is
going to be carried in alarmedResource?

I am repeating my request to include some examples as this might help
people to understand what the authors have in mind.

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 16 Dec 2008 13:46:52 -0500

Inline 

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Monday, December 15, 2008 1:50 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; Seely, Ted A [CTO]
Subject: Re: [OPSAWG] Begin WG
LastCallondraft-ietf-opsawg-syslog-alarm-00.txt

On Mon, Dec 15, 2008 at 01:03:11PM -0500, Sharon Chisholm wrote:
 
> 2) The last sentence of section 1 is confusing; the document really 
> maps ITU perceived severity to SYSLOG severity and not the other way
round.

<sharon>
Yes. Both item #1 and #2 related to the same text. That sentence then
becomes

and the IETF Alarm MIB
</sharon>
 
> 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.
> has syntactic constraint requiring this  to be an OID.  For example, 
> in the case of an interface, resourceMapping might take a value of 

If this is the meaning, then I suggest to name resourceMapping to
alarmedResourceOID and I like to add that an OID by itself is not
sufficient to identify something in SNMP land since OIDs are scoped by a
context. So I guess this needs more work to be useful. And what is going
to be carried in alarmedResource?

<sharon>
I think the rename makes sense.

Right context. Yes, I guess we need to say working within a context is
for future study.
</sharon>

<Sharon>
I'll call that issue #11.

Proposed resolution:

Add a new section called "Examples" that includes the following.

Example 1 - Mandatory Alarm Information

           <165>1 2003-10-11T22:14:15.003Z mymachine.example.com
           evntslog - ID47 [exampleSDID@0 iut="3" eventSource=
           "Application" eventID="1011"][alarm alarmResource="su root" 
            probableCause="unauthorizedAccessAttempt"
perceivedSeverity="major"] 
           BOMAn application event log entry...

   In this example, extended from [Syslog], the VERSION is 1 and the
Facility has the value of 4.  The severity is 2.  The message was
created on 11 October 2003 at 10:14:15pm UTC, 3 milliseconds into the
next second.  The message originated from a host that identifies itself
as "mymachine.example.com".  The APP-NAME is "su" and the PROCID is
unknown.  The MSGID is "ID47".  We have included both the structured
data from the original example, a single element with the value
"[exampleSDID@0 iut="3" eventSource="Application" eventID="1011"]" and a
new one with the alarm information defined in this memo. The alarm SD-ID
contains the mandatory SD-PARAMS of alarmResource, probableCause and
preceivedSeverity.  The MSG itself is "An application event log
entry..."  The BOM at the beginning of MSG indicates UTF-8 encoding.

Example 2 - Additional Alarm Information

           <165>1 2004-11-10T20:15:15.003Z mymachine.example.com
           evntslog - ID48 [alarm alarmResource="interface 42" 
           probableCause="unauthorizedAccessAttempt"
perceivedSeverity="major"
           eventType="communications" alarmedResourceOID
="1.3.6.1.2.1.2.2.1.1.42"]

In this example, we include two optional alarm fields - eventType and
alarmedResourceOID .

</Sharon>

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Dec 2008 20:47:09 +0100

On Tue, Dec 16, 2008 at 01:46:52PM -0500, Sharon Chisholm wrote:
 
> Right context. Yes, I guess we need to say working within a context
> is for future study.

I doubt very much that this flies in the IETF. And this problem has
been solved before. Perhaps you want to ship an SNMP URI (RFC4088)?
If I recall correctly, SD-IDs can appear multiple times so it might
actually be a solution to ship an alarmedResourceURI.

>            BOMAn application event log entry...

alarmResource == alarmedResource? Perhaps the param names should be
made short since there might be message size constraints? My
understanding is that alarmedResource is free text that is nothing I
can really count on to have a certain meaning for a program. Is that
correct? How useful is this then to have? And "su root" does not match
my intuitive understanding of a resource anyway.
 
>            eventType="communications" alarmedResourceOID

I can't find "communications" in IANAItuEventType.

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 18 Dec 2008 11:20:01 -0500

Inline 

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Tuesday, December 16, 2008 2:47 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; Seely, Ted A [CTO]
Subject: Re: [OPSAWG] Begin
WGLastCallondraft-ietf-opsawg-syslog-alarm-00.txt

> for future study.

I doubt very much that this flies in the IETF. And this problem has been
solved before. Perhaps you want to ship an SNMP URI (RFC4088)?
If I recall correctly, SD-IDs can appear multiple times so it might
actually be a solution to ship an alarmedResourceURI.

<sharon>
Perhaps both is most appropriate. For those cases where it is a simple
solution and people only understand the OID and only need to OID, having
the OID is best. For the more complicated cases and when people know how
to use the SNMP URI, that is also available.

The proposal would be to replace section 3.6 with the following

3.6.  alarmedResourceOID and alarmedResourceURI

   If the alarm SD-ID is supported, the alarmedResourceOID and
alarmedResourceURI
   SD-PARAMs SHOULD
   be supported.  This is particularly useful for the systems that also
support SNMP.
   These item uniquely identifies the resource under alarm
   within the scope of a network element.  alarmedResourceOID must be
the same value
   as alarmActiveResourceId [RFC3877] for this alarm or follow similar
   semantics if the Alarm MIB is not supported. alarmedResourceURI is
the same resource, but
   defined using the SNMP URI [RFC4088].
</sharon>

>            BOMAn application event log entry...

alarmResource == alarmedResource? Perhaps the param names should be made
short since there might be message size constraints? My understanding is
that alarmedResource is free text that is nothing I can really count on
to have a certain meaning for a program. Is that correct? How useful is
this then to have? And "su root" does not match my intuitive
understanding of a resource anyway.

<sharon>
I've always been a fan of clarity over saving a few bits, but that
having been said, changing to resource would probably still be readable
since it is all wrapped in an "alarm" SD-ID. We should remove the alarm
prefix also from alarmResourceOID and AlarmResourceURI as well for
consistency.

What would you consider to be the resource in this example then? "root"?
I wasn't sure what to put. Yes, it is free form text.
</sharon>

<sharon>
My bad. I tried to go from memory. That should be "communicationsAlarm".
</sharon>

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Dec 2008 18:25:13 +0100

> to use the SNMP URI, that is also available.

I do not insist on the usage of SNMP URIs - I do however insist on a
solution that is compliant with section 3.3 of RFC 3411. A simple OID
is not unless it is clear how it is scoped.

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 18 Dec 2008 12:25:34 -0500

Hi,

Hi Sharon,

Please do not use private enterpise number 0 for examples.
IANA has now created an "example" private enterprise number
Please use 32473 
(see http://www.iana.org/assignments/enterprise-numbers)
The syslog WG RFCs will use this value as well.
 
dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Thursday, December 18, 2008 11:20 AM

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Dec 2008 18:29:58 +0100

Can we put a short note on the OPS Area Web page to recommend this and
send folks to this note in the future? 

Dan

> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Thursday, December 18, 2008 7:26 PM
> To: 'Sharon Chisholm'; [email-masked]
> Cc: [email-masked]; 'Seely, Ted A [CTO]'
> Please use 32473 (see 
> http://www.iana.org/assignments/enterprise-numbers)
> > solution and people only understand the OID and only need to OID, 
> > having the OID is best. For the more complicated cases and 
> when people 
> > know how to use the SNMP URI, that is also available.
> > 
> >    be supported.  This is particularly useful for the systems that 
> > also support SNMP.
> > having been said, changing to resource would probably still be 
> > readable since it is all wrapped in an "alarm" SD-ID. We 
> should remove 
> > the alarm prefix also from alarmResourceOID and AlarmResourceURI as 
> > well for consistency.
> >

---

From: "David Harrington" <[email-masked]>
Date: Thu, 18 Dec 2008 12:34:07 -0500

Yes.
An ID has been submitted for publication.
The OPS page should probably point to the RFC, once it is published. 

dbh

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Thursday, December 18, 2008 12:30 PM
> To: David Harrington; Sharon Chisholm; 
> [email-masked]
> Subject: RE: [OPSAWG] Begin 
> > >    within the scope of a network element.  alarmedResourceOID
must
> > be
> > >    semantics if the Alarm MIB is not supported.
alarmedResourceURI
> > is
> > > What would you consider to be the resource in this example then?

> > > "root"?

---

From: "David Harrington" <[email-masked]>
Date: Thu, 18 Dec 2008 12:39:21 -0500

+1

An OID alone is inadequate.

dbh 

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Thursday, December 18, 2008 12:25 PM
> To: Sharon Chisholm