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

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 7 May 2009 09:59:28 -0400

Hi

Is that all that is required to fix it? Add a context parameter? I
thought there would be more to it than that. I like that idea better.
I'll do two pre-versions: one to remove and one to add context and
people can see which they like.

Sharon 

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Thursday, April 09, 2009 12:38 PM
To: Chisholm, Sharon (CAR:ZZ00); 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: RE: [OPSAWG] Proposed update to syslog Alarm

Hi,

I think my perspective is to either fix it or remove it. As Juergen and
I have pointed out, the OID is incomplete without a context. 

dbh

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Friday, April 03, 2009 9:00 AM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> Subject: Re: [OPSAWG] Proposed update to syslog Alarm
> 
> Hi
> 
> It is acknowledged that resourceOID does not work in all
circumstances
> but the idea of leaving it in is that it is understood by the
majority
> of SNMP users. The URI approach was introduced to cover the cases
that
> OID could not. So, we are using the SNMP URI approach either way,
the
> question is whether to also keep the resourceOID. In my view, using 
> OIDS, which are universally understood, is something a lot of 
> implementations will want to do so it would be nice to have a
standard
> way to do that, but I'll go with working group consensus. 
> 
> So far I have heard
> 
> Dave H - remove it
> Sharon - keep it
> Juergen - remove it or align it to other work
> 
> So, if there are no other views I would suggest that we remove it.
> 
> Sharon
> 
> -----Original Message-----
> From: Juergen Schoenwaelder
> [mailto:[email-masked]]
> Sent: Monday, March 23, 2009 12:54 PM
> To: Chisholm, Sharon (CAR:ZZ00)
> Cc: [email-masked]
> Subject: Re: [OPSAWG] Proposed update to syslog Alarm
> 
> On Mon, Mar 23, 2009 at 05:04:41PM +0100, Sharon Chisholm wrote:
>  
> > 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
> 
> -- 
> 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
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 7 May 2009 14:07:45 -0400

Hi

As promised.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chisholm, Sharon (CAR:ZZ00)
Sent: Thursday, May 07, 2009 9:59 AM
To: David Harrington; Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [OPSAWG] Proposed update to syslog Alarm

Hi

Sharon 

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: Thursday, April 09, 2009 12:38 PM
To: Chisholm, Sharon (CAR:ZZ00); 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: RE: [OPSAWG] Proposed update to syslog Alarm

Hi,

dbh

circumstances
majority
that
the
standard

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 May 2009 21:04:33 +0200

> As promised.

Sorry, but the description of resourceContext looks like a joke. I
have no clue how someone implements this in an interoperable manner.
See RFC 3411 for a definition what an SNMP context is.

That said, I clearly prefer the resourceURI approach but (a) I do not
agree with the unneeded restriction to just SNMP URIs - I would prefer
to allow any URIs but spell out that SNMP URIs can and must be used to
refer to SNMP objects and (b) I think the example given is wrong. (And
references to the respective RFCs are missing as well.)

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 7 May 2009 16:00:32 -0400

Hi,

I agree with Juergen.

The "fixed" file is a pitiful response to the requested changes.
I find it insulting.

dbh

> Sent: Thursday, May 07, 2009 3:05 PM
> To: Sharon Chisholm
> Cc: David Harrington; [email-masked]

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 8 May 2009 09:02:07 -0400

Hi

I just assumed people would know how to fill in the context if they were
familiar with SNMP, but you are right, a more specific description would
help interoperability.

I almost agree with you about the general URI idea. The primary goal
here was to be able to specify SNMP-managed resources. I suppose that
doesn't mean we need to preclude other URIs.

I modelled the URI example on what I saw in the SNMP URI RFC examples.
I've never used them before in my life. Can you clarify what is wrong
about it?

Sharon

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Thursday, May 07, 2009 4:01 PM
To: 'Juergen Schoenwaelder'; Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: RE: [OPSAWG] Proposed update to syslog Alarm

Hi,

I agree with Juergen.

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 May 2009 15:14:23 +0200

> familiar with SNMP, but you are right, a more specific description would

For someone familiar with the notion of SNMP contexts, it is clear
that it is completely unclear how to fill this new SD-ID param out.
People making proposals should IMHO do their homework and work through
the details of the proposal first, or even better implement what they
propose to see how it works.

> I've never used them before in my life. Can you clarify what is wrong

OLD:

  snmp:example.com/1.3.6.1.2.1.2.2.1.1.42

NEW:

  snmp:example.com//1.3.6.1.2.1.2.2.1.1.42

And the reason for the double slash is exactly the SNMP context...
See RFC 4088 for the details and RFC3411 section 3.3.1 for the
definition of an SNMP context.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 May 2009 08:33:39 -0700

>>>>> On Fri, 8 May 2009 15:14:23 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> OLD:

JS> snmp:example.com/1.3.6.1.2.1.2.2.1.1.42

JS> NEW:

JS> snmp:example.com//1.3.6.1.2.1.2.2.1.1.42

NEWER:

snmp://example.com//1.3.6.1.2.1.2.2.1.1.42
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 May 2009 17:39:33 +0200

> snmp://example.com//1.3.6.1.2.1.2.2.1.1.42

Yep - we are getting closer. ;-)

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 8 May 2009 14:43:44 -0400

Hi

I'm now updating the two proposals (where a third might be to turn the
URI into a generic URI and keep it and OID+Context) and have noticed a
potential ambiguity. I thought someone might have discussed this
earlier, but can't now find the email. 

When dealing with the default context, there are some options.

1. When the resource is in the default context, the context is ""
2. When the resource is in the default context, the context is not
present
3. Both 1 or 2.

I know some syslog implementations are concerned about message length,
so I prefer 2.

Sharon 

-----Original Message-----
Sent: Friday, May 08, 2009 9:02 AM

Hi

Sharon

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: Thursday, May 07, 2009 4:01 PM
To: 'Juergen Schoenwaelder'; Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: RE: [OPSAWG] Proposed update to syslog Alarm

Hi,

I agree with Juergen.

dbh

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 13 May 2009 12:04:26 -0400

Hi

Attached are updates of both proposed paths forward with changes
discussed and a few other bits of clean up.

Sharon

-----Original Message-----
Sent: Friday, May 08, 2009 2:44 PM

Hi

present 3. Both 1 or 2.

Sharon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 May 2009 18:42:34 +0200

> discussed and a few other bits of clean up.

I though we had agreement that there is no need to restrict the URI to
the snmp: scheme. But the text does not reflect that agreement.

Concerning the other version, let me once again point you to RFC 3411
and in particular the fact that a context is not the same as a
contextName.

And in general, I would prefer shorter SD element names to save
valuable space in syslog messages. Everything is scoped by the "alarm"
SDID so using short names should carry not much risk of problems later
on.

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 13 May 2009 12:59:59 -0400

Hi

I wasn't sure we reached full agreement on the URI issue, but if we have
I would propose I merge the two proposals into one and have resourceURI,
resourceOID and resourceContext. Would that make sense?

I'll reread 3411.

The names are self-describing and familiar to people doing a lot of
alarm management. I'm not sure shortening them (probableCause->cause,
trendIndication->trend, perceivedSeverity->Severity, eventType->event)
is worth it. I know, for example that sometimes there is more than one
severity in an alarm record, but I guess these sort of extensions would
be done in a different SD-ID.

Sharon

-----Original Message-----
Sent: Wednesday, May 13, 2009 12:43 PM

And in general, I would prefer shorter SD element names to save valuable
space in syslog messages. Everything is scoped by the "alarm"
SDID so using short names should carry not much risk of problems later
on.

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 13 May 2009 13:36:19 -0400

Hi Sharon,

Here's an overview statement from RFC3411 section 3.3:

Thus, in order to identify an
   individual item of management information within the management
   domain, its contextName and contextEngineID must be identified in
   addition to its object type and its instance.

So instead of ResourceOID and ResourceContext, I think you need
contextEngineID, contextName, objectType, and objectID. The full
details of what these fields MUST contain to be useful can be found in
RFC3411 section 3.3.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: Sharon Chisholm [mailto:[email-masked]] 
> Sent: Wednesday, May 13, 2009 12:04 PM
> [mailto:[email-masked]] On Behalf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 May 2009 00:10:03 +0200

> resourceOID and resourceContext. Would that make sense?

Having two ways to represent the same information is not helpful -
resourceURI is a powerful approach since it is not tightly bound to
SNMP and thus much more widely applicable.

I think I know my preference...

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 19 May 2009 10:28:27 -0400

Hi

Ok. I think we need a tie breaker vote here.

Juergen: Just resourceURI, where it can handle SNMP URIs and other URIs
Dave H: SNMP Context + additional fields to support.

I don't have a strong opinion, but if we do need as many fields as Dave
indicates we do, perhaps we should stick to resourceURI, using SNMP
examples. I think the example demonstrates how to use it, even for
people who are not familiar with the SNMP URI, which I think would be
most people.

Sharon 

-----Original Message-----
Sent: Wednesday, May 13, 2009 6:10 PM

On Wed, May 13, 2009 at 06:59:59PM +0200, Sharon Chisholm wrote:
 
> I wasn't sure we reached full agreement on the URI issue, but if we 
> have I would propose I merge the two proposals into one and have 
> resourceURI, resourceOID and resourceContext. Would that make sense?

Having two ways to represent the same information is not helpful -
resourceURI is a powerful approach since it is not tightly bound to SNMP
and thus much more widely applicable.

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 19 May 2009 12:45:49 -0400

Hi,

RFC4088 specifes the SNMP URI. It is a Proposed Standard.
Here is the abstract:
"   The Simple Network Management Protocol (SNMP) and the Internet
   Standard Management Framework are widely used for the management of
   communication devices, creating a need to specify SNMP access
   (including access to SNMP MIB object instances) from non-SNMP
   management environments.  For example, when out-of-band IP
management
   is used via a separate management interface (e.g., for a device
that
   does not support in-band IP access), a uniform way to indicate how
to
   contact the device for management is needed.  Uniform Resource
   Identifiers (URIs) fit this need well, as they allow a single text
   string to indicate a management access communication endpoint for a
   wide variety of IP-based protocols.

   This document defines a URI scheme so that SNMP can be designated
as
   the protocol used for management.  The scheme also allows a URI to
   designate one or more MIB object instances."

What you are trying to do is "specify SNMP access
   (including access to SNMP MIB object instances) from non-SNMP
   management environments."

I don't really see the need for a tie-breaker. I think it would be
appropriate to use the IETF Proposed Standard URI already approved for
this purpose. 

Despite your statement in this most recent email saying you do not
have a strong opinion, this discussion has gone on this long only
because you have had a strong opinion that resourceOID should be used,
rather than just accepting the IETF standard approach of using a URI.

Juergen said fix the resourceOID or remove it, and he prefers to use
the URI. I said either fix the resourceOID or remove it. Randy Presuhn
agreed with fix it or remove it. Wes apparently supports the URI
approach since he sent a correction for your example. You are the only
one arguing to keep the resourceOID. I think the consensus is clear
that just using a URI and removing the resourceOID is fine.

To make sure you understand my opinion - remove the resourceOID and
resourceContext please. Do not restrict the URI to snmp only.

dbh

> Sent: Tuesday, May 19, 2009 10:28 AM

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 21 May 2009 10:25:48 -0400

Hi

In the beginning, my view was that OID was simple and URL was
complicated. After the various bits of discussion, it seems the opposite
is sort of true.

I'll update the 'remove' version of the draft to not restrict to SNMP
and post here it here for final review before posting as an ID.

Thanks everyone,

Sharon 

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Tuesday, May 19, 2009 12:46 PM
To: Chisholm, Sharon (CAR:ZZ00); 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: RE: [OPSAWG] Proposed update to syslog Alarm

Hi,

RFC4088 specifes the SNMP URI. It is a Proposed Standard.
Here is the abstract:
"   The Simple Network Management Protocol (SNMP) and the Internet
   Standard Management Framework are widely used for the management of
   communication devices, creating a need to specify SNMP access
   (including access to SNMP MIB object instances) from non-SNMP
   management environments.  For example, when out-of-band IP management
   is used via a separate management interface (e.g., for a device that
   does not support in-band IP access), a uniform way to indicate how to
   contact the device for management is needed.  Uniform Resource
   Identifiers (URIs) fit this need well, as they allow a single text
   string to indicate a management access communication endpoint for a
   wide variety of IP-based protocols.

   This document defines a URI scheme so that SNMP can be designated as
   the protocol used for management.  The scheme also allows a URI to
   designate one or more MIB object instances."

Despite your statement in this most recent email saying you do not have
a strong opinion, this discussion has gone on this long only because you
have had a strong opinion that resourceOID should be used, rather than
just accepting the IETF standard approach of using a URI.

Juergen said fix the resourceOID or remove it, and he prefers to use the
URI. I said either fix the resourceOID or remove it. Randy Presuhn
agreed with fix it or remove it. Wes apparently supports the URI
approach since he sent a correction for your example. You are the only
one arguing to keep the resourceOID. I think the consensus is clear that
just using a URI and removing the resourceOID is fine.

dbh

> Juergen: Just resourceURI, where it can handle SNMP URIs and other 
> URIs Dave H: SNMP Context + additional fields to support.
> 
> I don't have a strong opinion, but if we do need as many fields as 
> Dave indicates we do, perhaps we should stick to resourceURI, using 
> SNMP examples. I think the example demonstrates how to use it, even 
> for people who are not familiar with the SNMP URI, which I think would
be

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 21 May 2009 12:32:23 -0400

Hi

As promised. Note that I removed a sentence about being scoped to a
network element from the resource URI section because it no longer
seemed to make sense.

Sharon 

-----Original Message-----
Sent: Thursday, May 21, 2009 10:26 AM

Hi

Thanks everyone,

Sharon 

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: Tuesday, May 19, 2009 12:46 PM
To: Chisholm, Sharon (CAR:ZZ00); 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: RE: [OPSAWG] Proposed update to syslog Alarm

Hi,

dbh

be

---

From: "tom.petch" <[email-masked]>
Date: Fri, 22 May 2009 09:06:16 +0200

----- Original Message -----
From: "Sharon Chisholm" <[email-masked]>
To: "David Harrington" <[email-masked]>; "Juergen Schoenwaelder"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 21, 2009 4:25 PM

> and post here it here for final review before posting as an ID.

Please don't.  I like my I-Ds to be I-Ds and my e-mail to be e-mail.  The
characteristic information of the two is different and my preferred delivery
route is therefore also different.

I read your earlier post and thought I would offer an opinion to help achieve a
rough consensus and then realised I did not know what you (collectively) were
talking about.  I downloaded the I-D - well, I didn't, it has expired - I went
to Watersprings (my favorite website) and got the most recent - and still do not
know what you are talking about.

So please, a current I-D with the text you want comments on and I promise (or
threaten?) I will comment on it (and all before Boxing Day:-).

Currently my view in the abstract is that OID are very simple and URI are very
nice but so what?

Tom Petch

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 25 May 2009 07:43:33 -0400

Hi

I find the pre-drafts a better way to get review of edits compared to
posting editing instructions like I used to do. You are free of course
to wait for the actual draft. If I don't hear any further comments on
this version, I'll post the update later today or early tomorrow.

Thanks,

Sharon 

-----Original Message-----
From: tom.petch [mailto:[email-masked]] 
Sent: Friday, May 22, 2009 3:06 AM
To: Chisholm, Sharon (CAR:ZZ00); David Harrington; Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [OPSAWG] Proposed update to syslog Alarm

----- Original Message -----
From: "Sharon Chisholm" <[email-masked]>
To: "David Harrington" <[email-masked]>; "Juergen Schoenwaelder"

> complicated. After the various bits of discussion, it seems the 
> opposite is sort of true.
>

Please don't.  I like my I-Ds to be I-Ds and my e-mail to be e-mail.
The characteristic information of the two is different and my preferred
delivery route is therefore also different.

I read your earlier post and thought I would offer an opinion to help
achieve a rough consensus and then realised I did not know what you
(collectively) were talking about.  I downloaded the I-D - well, I
didn't, it has expired - I went to Watersprings (my favorite website)
and got the most recent - and still do not know what you are talking
about.

So please, a current I-D with the text you want comments on and I
promise (or
threaten?) I will comment on it (and all before Boxing Day:-).

Currently my view in the abstract is that OID are very simple and URI
are very nice but so what?

Tom Petch

management
that
to
as