RE: draft-ietf-snmpv3-coex-v2-04.txt

On Wed, 21 May 2003, Wijnen, Bert (Bert) wrote:

> Date: Wed, 21 May 2003 00:22:45 +0200
> From: "Wijnen, Bert (Bert)" <[email protected]>
> To: "SNMPv3 (E-mail)" <[email protected]>
> Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt
>
> DO we worry at all about two SMICng warnings:
> W: f(coex.mi2), (178,24) Item "snmpCommunityName" should have SIZE specified
> W: f(coex.mi2), (396,23) Item "snmpTrapCommunity" should have SIZE specified
>
> We could add a SIZE of (1..0xffff) I would think
>
> Thanks,
> Bert
>

This very question was brought up up back in December in a message to this
list in the thread "Re: WG last call: Coex draft" and the response at the
time (though I'm only seeing one in my archive offhand) seemed to be "no":

| On Mon, 23 Dec 2002, Michael Kirkham wrote:
| > I would suggest that snmpCommunityName and snmpTrapCommunity should have
| > size restrictions.  While SMIv2 has an implied limit of 64k for OCTET
| > STRING, it's not particularly realistic to have 64k community strings, let
| > alone in the table.  Unfortunately SNMPv1 and v2c don't specify a
| > community string size limit, so choosing one that's appropriate and agreed
| > upon may be difficult.
|
| I think these object definitions should be left unchanged.  Changing
| (or adding) a SIZE restriction is not one of the modifications that is
| permitted by RFC 2578 Section 10.2.  Since neither of these objects
| appears in an INDEX clause, there is nothing illegal about the
| definitions as they stand and so no error to fix;  and as noted above,
| it's not obvious what the limit should be anyway.
|
| //cmh


--
Michael Kirkham
www.muonics.com