-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/17/18 12:40, Eliot Lear wrote: > Thank you, Joe. Barring objections, I will hold these as editorial > and work with the RFC Editor on them.
That's fine. I really want to make sure the MUD YANG module gets its revision bumped since there was a change. Joe > > Eliot > > On 17.05.18 18:13, Joe Clarke wrote: >> On 5/17/18 11:36, Eliot Lear wrote: >>> Hi everyone, >> >>> This draft is intended to address all IESG comments. Thanks to >>> the IESG and reviewers for their contributions. A summary of >>> the changes is below, but people may wish to do a side by side >>> review. >> >> Thanks for working with the IESG to resolve the major comments. >> >> I have a few additional on this draft. >> >> Section 1.7 >> >> s/URL that the thing emitted/URL that the Thing emitted/ >> >> === >> >> Section 2.1 >> >> You changed container "mud" to component "mud" here likely to be >> consistent with the use of component in the other two bullets. >> However, because "mud" is quoted, it seems like you are directly >> referring to the mud container in the YANG model. Maybe drop >> the "mud" or say: >> >> the first component, the "mud" container, ... >> >> === >> >> Section 4.6 >> >> s/each every/each and every/ >> >> === >> >> Section 4.8 >> >> s/This MUST only applied to TCP. this/This only applies to TCP. >> This/ >> >> Not sure if that's what you want to say. >> >> === >> >> Section 7 >> >> You didn't bump the revision with this YANG module update. This >> can mess up some tooling we have. Can I ask that you bump this >> at least once before final publication? >> >> === >> >> Section 7 >> >> I'm not a YANG doctor, but I see formatting inconsistencies in >> this module. It would benefit from running it through pyang -f >> yang to normalize the formatting. >> >> === >> >> Section 8.3 >> >> The same is true here. A pyang -f yang will normalize the >> formatting. >> >> === >> >> Section 9 >> >> Suggestion to add documentation to your example MUD file just to >> hint at this being a good behavior for the benefit of admins. >> >> === >> >> Section 13 >> >> s/To insure that/To ensure that/ >> >> === >> >> Section 13.2 >> >> s/that the verification step match/that the verification step >> matches/ >> >> === >> >> Section 15 >> >> s/alloewed/allowed/ >> >> === >> >> Section 16 >> >> s/occured/occurred/ >> >> === >> >> Section 17.1 >> >> s/registred/registered/ >> >> === >> >> Appendix B >> >> s/overriden/overridden/ >> >> Joe >> >> >>> Eliot >> >> >>> * Small edits to the abstract * Clarity in the introduction >>> that the focus is on protecting the device. * Many >>> grammatical/wording improvements * Clarity when MUD is most >>> effective. * MUD controller -> MUD manager * Normative language >>> boiler plate change * Clarity on what should happen when a MUD >>> manager can't reach a MUD file server * A few reference updates >>> * Clarity on the validity time of a MUD file * Added references >>> to RFCs 5911 and 5912 for SMI changes * one additional data >>> element (documentation) * one change based on an update to the >>> ACL model during its last call * Subsection numbering for node >>> descriptions. * Improved text around "controller", >>> direction-initiated. * Simplified MUD-URL text. * Optional >>> reserved space added to DHCP, LLDP options * Simplified DHCP >>> processing. * A new certificate field to bind the manufacturer >>> certificate to the mud signer. * A content type definition for >>> the SMI. * Updated security considerations. >> >> >> >> > -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWv20UwAKCRBvaI+K/hTP h9CoAJ0ToJFtclUQPo0OIIfz6USb4H/qTQCfQKsQnmWgOCStESflVHOC6Uma1j4= =vgCN -----END PGP SIGNATURE----- _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
