Hi Med,

On 24.01.18 10:52, [email protected] wrote:
>
> Hi Eliot,
>
>  
>
> Some quick comments:
> * Please note that "acl-type" should be “type” and "rule-name" should
> be changed to “name”. This can be easily fixed in the examples.

My understanding from draft-ietf-netmod-acl-model-14 is that acl-type
remains acl-type.  acl-name became name.  But you're right- rule-name
became name as well.  I will adjust the text accordingly.

> * This sentence should be carefully updated as well: “With the
> exceptions of "name", "acl-type", "rule-name", and TCP and”.
> * I guess the examples should be checked to align with the new ACL
> structure. For example,
>  - “ipv6-acl” entries should be updated to “ipv6”.

Which is the text I adjusted ;-)

> - add “l3” entry before “ipv4” and “ipv6”.

I think this is done in the normative text but you're right- it needs to
be corrected in the examples.

> * It would useful to add a justification why it is not recommended to
> support 'reject' action.

Ok, I'll add some text.

> * Unless I’m mistaken, the mud use case does not require the support
> of interfaces as an attachment point. It may be useful to add
> something among those lines:  
>
>  
>
>    Given that MUD does not deal with interfaces, the
>
>    support of the "ietf-interfaces" module [RFC7223
> <https://tools.ietf.org/html/rfc7223>] is not
>
>    required. Specifically, the support of interface-related
>
>    features and branches (e.g., interface-attachment and interface-stats)
>
>    of the ACL YANG module is not required.
>

ok.


In addition, I have received the following requests for data elements to
be added to the core model:

  * Manufacturer-Name
  * Device-Type
  * Model-Number
  * Software-version


Unless I hear objections, I am disposed to add these as non-mandatory
leaf-nodes as strings underneath the top-level MUD object.

Eliot
>
>  
> Cheers,
> Med
>
>  
>
> *De :*OPSAWG [mailto:[email protected]] *De la part de* Eliot Lear
> *Envoyé :* mercredi 24 janvier 2018 09:34
> *Cc :* Mahesh Jethanandani; [email protected]; Mark Nottingham
> *Objet :* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt
>
>  
>
> This update primarily focuses on two elements that were agreed during
> WGLC:
>
>   * The update to the ACL model.  That update has taken longer than I
>     would have liked, but it is now at least close to finished.  Note:
>     the MUD model does not yet match the published ACL model, but it
>     does match the agreed changes that will be produced in the next
>     ACL draft.
>   * Mark Nottingham had commented that it is not appropriate to have
>     versioning information in the MUD-URL itself, but that it should
>     be in the model.  We agreed on this change, as well as some
>     wording around how HTTP is handled.
>
> Based on these changes, I would like to move this document forward to
> IETF LC.
>
> Eliot
>
>  
>
> On 24.01.18 09:29, [email protected]
> <mailto:[email protected]> wrote:
>
>      
>
>     A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>     This draft is a work item of the Operations and Management Area Working 
> Group WG of the IETF.
>
>      
>
>             Title           : Manufacturer Usage Description Specification
>
>             Authors         : Eliot Lear
>
>                               Ralph Droms
>
>                               Dan Romascanu
>
>      Filename        : draft-ietf-opsawg-mud-14.txt
>
>      Pages           : 56
>
>      Date            : 2018-01-24
>
>      
>
>     Abstract:
>
>        This memo specifies a component-based architecture for manufacturer
>
>        usage descriptions (MUD).  The goal of MUD is to provide a means for
>
>        Things to signal to the network what sort of access and network
>
>        functionality they require to properly function.  The initial focus
>
>        is on access control.  Later work can delve into other aspects.
>
>      
>
>        This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
>
>        LLDP TLV, a URL suffix specification, an X.509 certificate extension
>
>        and a means to sign and verify the descriptions.
>
>      
>
>      
>
>     The IETF datatracker status page for this draft is:
>
>     https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>      
>
>     There are also htmlized versions available at:
>
>     https://tools.ietf.org/html/draft-ietf-opsawg-mud-14
>
>     https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14
>
>      
>
>     A diff from the previous version is available at:
>
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-14
>
>      
>
>      
>
>     Please note that it may take a couple of minutes from the time of 
> submission
>
>     until the htmlized version and diff are available at tools.ietf.org.
>
>      
>
>     Internet-Drafts are also available by anonymous FTP at:
>
>     ftp://ftp.ietf.org/internet-drafts/
>
>      
>
>     _______________________________________________
>
>     OPSAWG mailing list
>
>     [email protected] <mailto:[email protected]>
>
>     https://www.ietf.org/mailman/listinfo/opsawg
>
>      
>
>  
>

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to