Re: [MIB-DOCTORS] Fix of Security Guidelines for IETF MIB Modules

[Glenn Mansfield Keeni <[e-mail]>]

Hi,

 > This seemed like a better fix than just changing the i.e to an
 > e.g, and so I went ahead and made that change.
Thanks. That is one nit less!

The discussion on further fixes will continue..

Glenn

On 2018/10/09 9:11, Warren Kumari wrote:
> On Sun, Sep 30, 2018 at 10:16 PM Glenn Mansfield Keeni <[e-mail]>
> wrote:
> 
>> Hi,
>>   > disclosure.  For example, consider a hostname.  Are we willing to
>>   > do major surgery on this paragraph, probably splitting it into two,
>>   > and thus affecting the structure of these security considerations?
>> I would suggest that we take this in 2 steps.
>> First, fix the (now) obvious nit.
>> +--------------------------------------------------------------------+
>> OLD:  Some of the readable objects in this MIB module (i.e., objects
>>          with a MAX-ACCESS other than not-accessible) may be considered
>>          sensitive or vulnerable in some network environments.
>>
>> NEW:  Some of the objects in this MIB module may be considered sensitive
>>          or vulnerable in some network environments.  This includes INDEX
>>          objects with a MAX-ACCESS of not-accessible, and any indices from
>>          other modules exposed via AUGMENTS.
>> +---------------------------------------------------------------------+
>>
> 
> This seemed like a better fix than just changing the i.e to an e.g, and so
> I went ahead and made that change.
> Please, if anyone objects, let me know and I'll change it back (it isn't
> really my text, but I figured it was clearly enough broken that I'm
> qualified to have an opinion).
> 
> 
> 
>> Next, discuss and arrive at the decision (and maybe text too) on whether
>> we are willing to do major surgery etc. I agree that in the current form
>> (even with the nit-fix) the security considerations remain incomplete.
>>
> 
> This discussion should still continue...
> 
> W
> 
> 
> 
>>
>> Glenn
>>
>> On 2018/10/01 0:40, Randy Presuhn wrote:
>>> Hi -
>>>
>>>
>>> On 9/30/2018 5:59 AM, Glenn Mansfield Keeni wrote:
>>>>
>>>> Hi,
>>>>   >         What
>>>>   >         is the point of limiting read access and then sending the
>>>>   >         information in the clear?
>>>> Total agreement. Sending info in the clear is by default NG and must
>>>> be strongly discouraged.
>>>> It will help to have some proposed replacement text for
>>>>   > OLD:  It is thus important to control even GET and/or NOTIFY access
>> to
>>>>   >        these objects and possibly to even encrypt the values of these
>>>>   >        objects when sending them over the network via SNMP.
>>> ...
>>>
>>> As I wrote previously, this would be editorially tricky since the
>>> paragraph currently conflates "sensitive" (which I take to mean
>>> "that which should be protected from disclosure") with "vulnerable"
>>> (which I take to mean "that which should be protected from
>>> modification").  It *is* possible to have something which one wants
>>> to protect from modification, but there's no need to protect it from
>>> disclosure.  For example, consider a hostname.  Are we willing to
>>> do major surgery on this paragraph, probably splitting it into two,
>>> and thus affecting the structure of these security considerations?
>>>
>>> Randy
>>
>>
>