Re: [MIB-DOCTORS] [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)

Dear Glenn,

Thank for your advice on the the Security Considerations section.
I am going to revise that section along with your advice.

-- tsuno

2018-09-15 11:07 GMT+09:00 Glenn Mansfield Keeni <glenn@cysols.com>:
> Dear Tsuno,
>      I agree with Benjamin Kaduk's comment on the Security
> Considerations section. I understand the following sentence copied
> verbatim from The Security Guidelines for IETF MIB modules
>  >>     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.
> is causing the confusion. The scope of the readable objects restricted
> to "objects with a MAX-ACCESS other than not-accessible" is inadequate
> here.
>
> Please change the "i.e" to "e.g.". That will clear the confusion and
> make the statement accurate.
>
> Glenn
>
>
> On 2018/09/12 10:49, Benjamin Kaduk wrote:
>>
>> Benjamin Kaduk has entered the following ballot position for
>> draft-ietf-bess-mvpn-mib-11: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> A general comment that we've been making on lots of documents in this
>> space is that it would be nice to be in a place where the acronym "VPN"
>> implies transport encryption.  It's unclear that it's appropriate to
>> request
>> changes to this specific document toward that end, though.
>>
>> Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security
>> considerations in the list of address-related objects that may have
>> privacy/security impact.  That list is predicated on being "objects with a
>> MAX-ACCESS other than not-accessible", but all the instances of
>> mvpnAdvtPeerAddr I found in the body text were marked as not-accessible.
>> Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs,
>> mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and
>> mvpnMrouteNextHopAddr.  (Incidentally, why ar mvpnMrouteCmcastSourceAddrs
>> and mvpnMrouteNextHopSourceAddrs plural with the final 's'?)
>>
>> Perhaps using subsections to separate the various tables' descriptions
>> would aid readability.
>>
>>
>> _______________________________________________
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess