Hi Benjamin, > 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.
Thank you for your clarification. I have carefully considered your suggestion, but it looks a bit redundant for me when each table has its own subsection. Consequently, I have decided to keep the original style. I would appreciate your understanding of my decision. Thanks, -- tsuno 2018-09-16 11:15 GMT+09:00 Benjamin Kaduk <[email protected]>: > 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
