Hi Don, If I understand you right, the answer on the security section amounts to “it’s just the standard boilerplate, John”. ;-) Which is fine — I was really more curious than anything else, there’s nothing wrong about the text in question, it just seems superfluous in this context.
I’m fine if you want to keep it as written. Thanks for the quick reply, —John > On Oct 17, 2022, at 4:44 PM, Don Fedyk <dfe...@labn.net> wrote: > > Hi John > > Please see [Don] inline: > > Thanks > Don > > -----Original Message----- > From: John Scudder via Datatracker <nore...@ietf.org> > > > John Scudder has entered the following ballot position for > draft-ietf-ipsecme-mib-iptfs-08: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!GWDkwYgWBDmuOyF7fu0N7_eVqGssdVMCFEWzoWnh6CvVm7br9S5McKqG16UimDnm5wakihg7EgM$ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/__;!!NEt6yMaO-gk!GWDkwYgWBDmuOyF7fu0N7_eVqGssdVMCFEWzoWnh6CvVm7br9S5McKqG16UimDnm5wak1jfSRXA$ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Routing AD comments for draft-ietf-ipsecme-mib-iptfs-08 > > ## COMMENTS > > ### Section 4.2 > > You have "TFS bit rate may be specified at layer 2 wire rate" and "TFS bit > rate > may be specified at layer 3 packet rate". Shouldn't that be "as", not "at"? I > did go looking for insight in ipsecme-yang but it just made me think that > document has the same (looks to me like a) bug. > > [Don] Yes "as" is better. I will make a note for both docs. > > ### Section 6 > > I'm a little mystified why "For the implications regarding write > configuration" > considering this is a read-only MIB? (Which the very next paragraph goes on to > say.) The same applies a few paragraphs down where you talk about "who on the > secure network is allowed to access and GET/SET (read/change/create/delete) > the > objects in this MIB module" -- isn't it really just who can GET (read) the > objects? And the same for the "Further" bullet point. > > [Don] We have specified YANG for full control write and read and SNMP MIB in > this document for read only viewing of the MIB for backwards compatibility. > The SNMP versions paragraph is a warning about using SNMP version that are > vulnerable. The text was added as an overall security recommendation, and we > did not scope that to read only for this MIB because is a general SNMP > security comment. > > Is that explanation OK or would you like to see a change? > > > > > > > ## NITS > > - s/paccket/packet/ > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
