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 <gl...@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 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
