[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIB
- To: mibs@ops.ietf.org
- Subject: RE: MIB
- From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
- Date: Mon, 5 Jun 2000 15:59:44 +0200
- Delivery-date: Mon, 05 Jun 2000 07:02:36 -0700
- Envelope-to: mibs-data@psg.com
Comments inline
I started sending to just mibs mlist, I was getting multiple copies of every
msg
(as I bet most if not all of you do).
Bert
> ----------
> From: RJ Atkinson[SMTP:rja@inet.org]
> Sent: Monday, June 05, 2000 3:50 PM
> To: Jon Saperia
> Cc: Wijnen, Bert (Bert); Juergen Schoenwaelder;
> Spencer.Giacalone@predictive.com; djoyal@nortelnetworks.com;
> mibs@ops.ietf.org
> Subject: Re: MIB
>
> Several folks have COMPLETELY missed the issue, so please let
> me start over and try to explain from the top:
>
> The original proposal was for DESCRIPTION text for a
> specific OID in the OSPF that said that if a particular OSPF
> implementation
> did NOT implement SNMPv3, then a particular OID (one enabling OSPF
> cryptographic authentication) would be MAX-ACCESS of READ-ONLY,
> but that if the agent DID implement SNMPv3, then that OID would have
> a MAX-ACCESS of READ-CREATE.
>
> In short, the original proposal was that the MAX-ACCESS would be
> a function of what security mechanisms were implemented and
> hence were --AVAILABLE-- to the operator.
>
> There was no proposal to constrain what an operator would
> actually do, so please drop that irrelevant thread.
>
But if the implementer makes it READ-ONLY, then the operator cannot
change that to READ-WRITE or READ-CREATE, can he?
> Are there comments on the specific narrow proposal above ?
>
> Thanks,
>
> Ran
> rja@inet.org
>
>