Hi,
If I remember correctly, the 484 byte limit of SNMP was the amount available within
the UDP message. So your numbers may be slightly high still. Did you calculate in the
overhead of the transport layer headers? If you plan to allow different transport
mappings you should probably calculate
Hi,
Assuming you use snmpv3 with e2e encryption, the relay wouldn't be able
to access the message contents to fragment it. An SNMP message should
never be fragmented anyway, so using snmp for the example is a bad
choice.
You should definitely not think of snmp as just some type of transport;
it
Hi,
I agree that we cannot demand mechanisms for correct synchronization. We
can provide a means to set the timezone, and recommend it be set
automatically via NTP. Following the recommendations of
draft-jones-opsec-03.txt, we should also allow an admin to set an object
that contains the offset
Hi,
Who makes the assertion that you can trust my timestamp? An
application? As Devin points out, an application has no way to determine
whether a timestsamp is valid, and thus cannot be trusted to make a
valid assertion on its own.
The best you could do is allow an administrator to set a value
Gerhards [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 10, 2004 12:15 PM
To: Andrew Ross; Harrington, David; Anton Okmianski;
[EMAIL PROTECTED]
Subject: RE: -international: trailer
Hi All,
I am a bit sad that I use Andrew's message to say this... but
Andrew has
just made an important point
be no problem. That would essentially be the same as having
such a limited compliance statement in the script mib document itself.
dbh
-Original Message-
From: Glenn Mansfield Keeni [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 1:12 AM
To: Harrington, David
Cc: [EMAIL
Hi,
I wrote a fairly long message, after your response to Anton, explaining
why I thought it would be a good thing, and clarifying how it should be
used. Did you not receive it?
dbh
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Friday, February 06, 2004 11:28 AM
To: [EMAIL PROTECTED]
Subject: RE: -protocol: transport mappings
Given that state of the discussion, I propose that we actually require
each implementation that talks to a
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Given that state of the discussion, I propose that we require each
implementation MUST support the to-be-written UDP transport mapping.
Everybody is free to use the format when not talking to someone else.
After
: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Friday, February 06, 2004 11:51 AM
To: Anton Okmianski; Harrington, David; [EMAIL PROTECTED]
Subject: RE: -international: trailer
Anton:
I agree with your conclusion that we need to support all
Unicode/UTF. I
also think that doing any kind
the implementors solve their own
implementation problems.
dbh
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Friday, February 06, 2004 12:14 PM
To: Anton Okmianski; Harrington, David; [EMAIL PROTECTED]
Subject: RE: -international: trailer
Anton:
I am still tempted
Hi,
Comments inline.
*snip*
2. I think requiring UDP implementation reduces the areas in which
syslog message format RFC could be utilized. I can see
many different
areas. For example, if RFC came without UDP baggage, we,
within Cisco,
could potentially standardize on this format
Hi
Comments inline.
My position is that -protocol should NOT contain any transport mapping
and that there should be a short RFC outlining how -protocol is to be
mapped on UDP transport.
I think it is important to have at least one transport mapping to ensure
interoperability.
I'm a bit
Hi,
I agree that a version number would be helpful; it will be even more
helpful when the **next** version of a syslog standard is published.
I suggest that you should consider adding two fields to a standardized
syslog format: the (IANA-assigned) enterprise ID and a version number.
(The IETF
Hi Glenn,
The benefit of having an SNMP trap is that there becomes some
coordination between the syslog messaging and SNMP trap manager
applications.
Operators often use trap management tools to alert them to problems, and
these applications often have the ability to filter out uninteresting
Hi,
I think there could be benefit to using a strict XML format, but there
are also tradeoffs.
Pro:
Compatibility with other protocols for doing manager-device
communications. The Netconf WG is developing an XML-based approach to
configuring devices; using a format that is compatible with
Hi,
There is a real demand in the industry for leveraging existing standards
rather than creating new languages or special syntaxes. The demand is to
reduce the number of special languages an operator needs to learn, and
to make it possible to integrate the data from one application type with
(or $.01).
Thanks,
dbh
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 9:02 AM
To: Harrington, David; [EMAIL PROTECTED]
Subject: RE: syslog-protocol: Cookie Format
Hi David and others,
There is a real demand in the industry
Hi Rainer,
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
I see the argument. Do you think that relying on something already
accepted - like BEEP XML in RFC3080 is a solution? As far as
I can see,
RFC3080 is increasingly becoming implemented. So while not
full
Hi Rainer,
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
I see the argument. Do you think that relying on something already
accepted - like BEEP XML in RFC3080 is a solution? As far as
I can see,
RFC3080 is increasingly becoming implemented. So while not
full
Hi,
If I recall correctly, there was a possibility of replay attacks if the
counter could wrap. That's why SNMP latches it. Given the 68 year
timeframe, wrap shouldn't be required.
(I remember questioning whether we shouldn't wrap when this was being
developed, and Marshall Rose assured me he
Hi Brett,
RFC 3014 is for retrieving a log of SNMP notifications. I don't believe
it is for retrieving syslog messages.
The purpose is to log traps/informs so that if they don't get delivered,
a manager can still see what was sent. This is equivalent to what you
want for syslog messages, but I
Hi,
I have some comments based on a fairly quick review of the mib in -01-. I will do a
more thorough review when Glenn publishes a new revision.
The bulk of section 2 should be replaced with the new mib boilerplate, which can be
copied from RFC3418. The paragraphs on RowStatus and RFC2119
23 matches
Mail list logo
