Ok, I take it back. Ranga found a problem with an example, and Russ found a glitch with the SMI. Nothing serious either, but I now propose to do one more update, once EKR and Ben have had a chance to review and comment.
Eliot On 17.05.18 18:56, Joe Clarke wrote: > 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. > >> > >> > >> > >> > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
