Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-21.txt

[Joe Clarke <[e-mail]>]

-----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-----