Subject: Re: [OPSAWG] Proposed update to syslog Alarm

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 23 Mar 2009 08:54:23 -0400

Hi

Comments inline. Again, thanks for the review. If we can resolve the
outstanding issues, I'll post the update when updates are permitted
again. 

Sharon

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Sunday, February 01, 2009 8:34 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [OPSAWG] Proposed update to syslog Alarm

On Fri, Jan 30, 2009 at 11:18:04AM -0500, Sharon Chisholm wrote:
 
> Attached is the propose update to the Syslog Alarm draft as a result 
> of comments received during working group last call. I believe it 
> addresses all known issues.
> 
> Please let me know if you have any comments or corrections and I can 
> make any necessary changes before posting this as version -02.

- Capitalize the section 1.1 heading or get rid of the heading
  and make the two sentences part of section 1.
<sharon>
I suspect that since this section is so short, the merge makes the most
sense
</sharon>

- You sometimes use "resource" and sometimes "alarmResource",
  please pick one an be consistent.
<sharon>
Oops. The latter is residue since we just changed it to resource. I have
found and replaced 4 instances.
</sharon>

- Section 3.6 is confusing - we now have three resource identifiers:

  (1) resource (or alarmResource)

      The specification leaves it open what it contains; so this value
      is really just for humans to read.

  (2) resourceOID

      This SD-ID contains an OID, namely the value of the
      alarmActiveResourceId MIB object. This SD-ID suffers from the
      problem that it does not carry SNMP context information and is
      thus ambiguous.

  (3) resourceURI

      This is defined to hold an SNMP URI. This solved the missing
      SNMP context problem of resourceOID but fires back in the sense
      that it can't carry other URIs.

  My proposal is to keep (1), delete (2), and to change (3) such that
  it can carry arbitrary URIs and can appear multiple times. If an
  alarmActiveResourceId MIB object exists, the value should be reported
  using the SNMP URI format in an resourceURI SD-ID.
<sharon>
I don't think people actually understand URI in SNMP, so this is why I
prefer the OID one, even with its limitations. My preference would be to
keep all three.
</sharon>

- In the example, I find it strange to consider "su root" a resource.
  For me, the resource raising the alarm is a subsystem of the OS
  dealing with authorization decisions. Also the message in the
  message part is not likely to be generated when you have an
  unauthorizedAccessAttempt. Please make the example more realistic.
<sharon>
You had mentioned this before, but I was not sure what else to put and I
could not find a reply to my request for more information so I left it
as is.  Your second sentence here is helpful. (Note that this is the
example from the base syslog protocol and we are only extending it, so
the argument of it not being realistic is a bit moot potentially). So, I
could say something like "aaa" or "security system" and that would work?
</sharon>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Mar 2009 14:52:24 +0100

> prefer the OID one, even with its limitations. My preference would be to

Those who understand SNMP know that an OID without context is broken.
I will keep pointing out this defect until it is fixed or higher
powers declare that RFC 3411 section 3.3.1 is not relevant anymore.

I believe using SNMP URIs is the easiest solution but I am fine if
people want to engineer something different as long as the solution
does take care of RFC 3411 section 3.3.1.

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 23 Mar 2009 12:04:41 -0400

Hi

So, are you OK with leaving all three in the document?

Sharon 

-----Original Message-----
Sent: Monday, March 23, 2009 9:52 AM

> prefer the OID one, even with its limitations. My preference would be 
> to keep all three.
> </sharon>

Those who understand SNMP know that an OID without context is broken.
I will keep pointing out this defect until it is fixed or higher powers
declare that RFC 3411 section 3.3.1 is not relevant anymore.

I believe using SNMP URIs is the easiest solution but I am fine if
people want to engineer something different as long as the solution does
take care of RFC 3411 section 3.3.1.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Mar 2009 17:53:37 +0100

> So, are you OK with leaving all three in the document?

Once again, resourceOID is broken. If you leave it, you have to fix
it. My preference would be to either (a) use the SNMP URI scheme or
(b) use the the SNMP to SYSLOG mappings also defined as part of the
OPSAWG working group. If you plan to invent a third solution, make
sure you have strong arguments; I prefer to reuse existing solutions.

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 23 Mar 2009 12:01:25 -0700

no.

dbh 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Monday, March 23, 2009 9:05 AM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 23 Mar 2009 12:01:41 -0700

+1

dbh 

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Monday, March 23, 2009 6:52 AM
> To: Sharon Chisholm
> Cc: [email-masked]