Re: ftp://ftp.cisco.com/fred/rreq-03.txt

[David Waitzman <[e-mail]>]

>>      "When SNMPv2 reaches Full Standard, you MUST implement it.  You MAY
>>      continue to implement SNMPv1 at that point, but you MUST not allow
>>      use of SNMPv1 to compromise the security constraints imposed by
>>      SNMPv2".

> I would think people would be very uncomfortable _requiring_ the use
> of a mechanism that is neither standardized nor widely implemented.
>
> As with any major protocol change, i would expect a period of
> improving quality.  This wording appears to mandate a hard cut.

SNMPv2 won't become a full standard without lots of experience.  There
is somewhat of a hard cut here, but I can't think of suitably formal
wording to the effect of "When SNMPv2 reaches Full Standard and is
widely implemented, you MUST implement it."

> According to this wording, when vendor X does its first new release
> after the SNMPv2 becomes standardized, it MUST use SNMPv2 and can not
> use SNMPv1 for management.  This means that every network management
> package and utility must also be upgraded to SNMPv2 _simultaneously_.
> We all know that's a bad idea.

This is not the meaning that I intended to convey: I wanted to say
that you should not allow, for example, write-access to some MIB
variable via the very insecure SNMPv1 plain-text community string when
that MIB variable is supposedly protected via SNMPv2 MD5
authentication, e.g. don't lock the (v2) front door but leave the (v1)
back door wide open.

How about:

    When SNMPv2 reaches Full Standard, you MUST implement it.  It MUST be
    the default management protocol.  You MAY continue to implement SNMPv1
    at that point (e.g. be an SNMPv2 "bilingual agent"), and in this case,
    allow SNMPv2 to be disabled via a configuration option.  If SNMPv2 and
    SNMPv1 are enabled then the default MUST be to disallow the use of
    SNMPv1 to compromise any stricter security constraints imposed by
    SNMPv2.

-david