Re: [netmod] [OPSAWG] Augmenting ACLs in mud-tls

[tom petch <[e-mail]>]

From: Michael Richardson
Sent: Monday, October 17, 2022 14:24
To: tom petch; Mahesh Jethanandani; [e-mail]; [e-mail]
Subject: Re: [OPSAWG] Augmenting ACLs in mud-tls

tom petch <[e-mail]> wrote:
    > draft-ietf-opsawg-mud-tls augments RFC8519 but while the RFC
    > structures its matches as a series of choices, the augmentation
    > does not.  Should it?

What in practice does this mean for the YANG?

<tp>
RFC8519 has
container matches {
  choice l2 { container eth
...
  choice l3 {
and so on.

This I-D has
  augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
    container client-profile {

By contrast, when
  draft-ietf-teas-yang-te-30
is augmented by
  draft-ietf-ccamp-flexigrid-tunnel-yang-01
then the augment is
  augment "/te:te/te:globals/te:named-path-constraints/" +
  "te:named-path-constraint/" +
  "te:explicit-route-objects-always/" +
  "te:route-object-exclude-always/te:type/te:label/" +
  "te:label-hop/te:te-label/te:technology"
     case flexi-grid {
     uses l0-types:flexi-grid-label-hop;

where te:technology from RFC8776 is
  choice technology { default "generic";
     case generic {
ie a case is being augmented to a choice alongside other cases and there are many such instances in CCAMP and TEAS of adding case for different technology.

This I-D augments 'container matches' with a YANG container so the choice/case as used in other uses of ACLs is not used; legal YANG but I do not know if that is the intent of the authors of RFC8519.

Tom Petch



    > The I-D has passed WGLC but has been delayed by me making
    > editorial comments.  AFAICT the I-D has not had a YANG Doctor
    > review.

Seems that this should have happened.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-