On 28 November 2011 18:14, Judith Walker <[email protected]> wrote:
> I’d like to know if there are any published guidelines for choosing
> community strings?
There's very little in the SNMP specifications as to what is or isn't valid
in a community string. The field is simply defined as an OCTET STRING,
with no length of content limitations, and there's no further guidance in
either RFC 1157 or RFC 1901
There are various MIB objects that represent community strings.
Some of these are also simply defined as plain OCTET STRINGs
but others use different syntax types, which impose implicit restrictions
on what values can be used.
In particular:
SnmpAdminString (i.e. OCTET STRING (SIZE (0..255)))
NOTIFICATION-LOG-MIB::nlmLogContextName
OCTET STRING( SIZE( 0..127 ))
RMON-MIB::eventCommunity
OCTET STRING
SNMP-COMMUNITY-MIB::snmpCommunityName
SNMP-COMMUNITY-MIB::snmpTrapCommunity
SnmpAdminString is "preferably in human-readable form"
so ought to be printable characters, rather than a binary string.
In addition, although the SNMP-COMMUNITY-MIB defines
a arbitrary mapping between (unrestricted) community names
and the internal Security Name - this is often expected to
be a straight one-to-one mapping.
The Security Name is limited to 32 (printable) characters,
so it would be sensible to restrict community names to the
same length.
Finally, although a zero-length community name is perfectly
valid, some software gets confused by this, so it's probably
best avoided.
Hope this helps
Dave
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders