Stewart, thanks for your review. Qin, thanks for your response. I entered a No Objection ballot.
Alissa > On Mar 13, 2020, at 8:26 AM, Qin Wu <bill...@huawei.com> wrote: > > Thanks Stewart for a good review, see reply inline below. > > -----邮件原件----- > 发件人: Stewart Bryant via Datatracker [mailto:nore...@ietf.org] > 发送时间: 2020年3月12日 21:12 > 收件人: gen-art@ietf.org > 抄送: net...@ietf.org; last-c...@ietf.org; > draft-ietf-netmod-factory-default....@ietf.org > 主题: Genart last call review of draft-ietf-netmod-factory-default-14 > > Reviewer: Stewart Bryant > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-netmod-factory-default-14 > Reviewer: Stewart Bryant > Review Date: 2020-03-12 > IETF LC End Date: 2020-03-16 > IESG Telechat date: Not scheduled for a telechat > > Summary: A well written document that is pretty much ready to go. I only have > one concern and that is whether the overwrite pattern needs some text so that > it does not accidentally become a covert channel. > > Major issues: None > > Minor issues: > > "All security sensitive data (i.e., private keys, passwords, etc.) SHOULD be > overwritten with zeros or a pattern before deletion. " > > "a pattern" is possibly vague, and care needs to be taken that this is not a > covert channel. Possibly it needs to say something like "an implementation > specific common pattern"? > > [Qin]: The proposed change works for me, maybe "common" should also be > removed. > Nits/editorial comments: > > Nits contains a warning about references, but one concerns text that will > removed, and the other is a format error that will be fixed in publication > [Qin]:Correct, YANG library reference is unused and should be removed. > I saw the SecDir comment on RPC. This is a starred term in the abbreviation > list and does not technically need expanding. > [Qin]: Right, RPC is an existing term that is defined in RFC7950, which > doesn't need to be expanded. > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
