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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 21 May 2003 00:22:45 +0200

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 

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> Sent: woensdag 7 mei 2003 15:08
> To: SNMPv3 (E-mail)
> Subject: draft-ietf-snmpv3-coex-v2-04.txt
> 
> 
> Colleagues,
> 
> Although the announcement hasn't yet been sent,
> 
> http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt
> 
> is now available in the repository.  It matches the version posted to
> this list on 15 April 2003.  As previously noted, that version fixed
> all outstanding comments except the following one:
> 
> On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote:
> > I see (In the MIB REVISION clause)
> >                    Changed the name of 'snmpCommunityGroup' 
> to a name
> >                    conflict with the SNMPv2-MIB.
> > Should that be:
> >                    Changed the name of 'snmpCommunityGroup' to 
> >                    snmpCommunityTableGroup to avoid a name conflict
> >                    with the SNMPv2-MIB.
> 
> So this error still needs to be fixed before publication (note that
> a similar error was was fixed in the revision log in appendix B).
> 
> //cmh
>

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 20 May 2003 18:26:54 -0700 (PDT)

> We could add a SIZE of (1..0xffff) I would think

If a SIZE constraint is put in at all it should probably be
(0..65535) (or (0..'ffff'h) if the hexadecimal style is preferred)
since neither RFC 1157 nor RFC 1901 actually specified that the
length of the community name must be non-zero.

That said, I don't care one way or another, and I'm happy to leave
it up to the document authors.  But if a SIZE constraint is added,
then the following text in the DESCRIPTION clauses should be
adjusted to match:

   There is no SIZE constraint specified for this object because
   RFC 1157 does not impose any explicit limitation on the length
   of community strings (their size is constrained indirectly by
   the SNMP message size).

//cmh

---

From: Michael Kirkham <[email-masked]>
Date: Tue, 20 May 2003 18:29:14 -0700 (PDT)

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

> Date: Wed, 21 May 2003 00:22:45 +0200
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "SNMPv3 (E-mail)" <[email-masked]>
> Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt
>

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

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 20 May 2003 21:27:54 -0700 (PDT)

> | it's not obvious what the limit should be anyway.

How short my memory is.  Let's leave it alone and not embarrass
me any more :-(

//cmh