From: Michael Richardson Sent: Monday, October 17, 2022 14:24 To: tom petch; Mahesh Jethanandani; [email protected]; [email protected] Subject: Re: [OPSAWG] Augmenting ACLs in mud-tls
tom petch <[email protected]> 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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
