On Sat, Sep 15, 2018 at 11:38:30AM +0900, Hiroshi Tsunoda wrote: > Hi Benjamin, > > Thank you very much for your thorough review and comments. > My replies are inline. > > > 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. > > I have received the advice from the MIB doctor on this matter and > I am going to update the draft along with the advice.
Excellent, I am sure the MIB doctor's advice is better than mine in this matter. > > (Incidentally, why ar mvpnMrouteCmcastSourceAddrs > > and mvpnMrouteNextHopSourceAddrs plural with the final 's'?) > > For example, the DESCRPIPTION of mvpnMrouteCmcastSourceAddrs > says as follows. > > "The network address which, along with the > corresponding mvpnMrouteCmcastSourcePrefixLength object, > identifies the sources for which this entry contains > multicast routing information." > > Thus, this object identifies the (multiple) multicast sources, not a > single source. > Consequently, I prefer that the names of these objects are in plural form. Ah, thank you for the explanation. > > Perhaps using subsections to separate the various tables' descriptions > > would aid readability. > > Please let me confirm one thing. > I assume that you are talking about "Sec 3.1. Summary of MIB Module." > Do you mean that the description of each table should be in each > different subsection? > Or, do you mean that there should be one subsection including a set of > tables' descriptions? I was thinking about each table having its own subsection. In particular, when I was reading, it was easy for me to miss the comments like "-- Table of PMSI information", especially when the comment was on a different page from the actual MIB contents. Having a section number might make those boundaries more clear. Thanks, Benjamin > Thanks in advance, > > -- tsuno > > 2018-09-12 10:49 GMT+09:00 Benjamin Kaduk <[email protected]>: > > 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
