Subject: [netmod] ACL model problem

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 14 Jul 2015 15:26:11 +0200

Hi,

the module ietf-packet-fields.yang in draft-ietf-netmod-acl-model-03
still has the problem that I discovered in the previous revision:

- Containers "source-port-range" and "destination-port-range" are both
  mandatory because the child leaf "lower-port" in each is mandatory. I
  think this wasn't intended. One solution would be to make both of them
  containers with presence.

(see
https://mailarchive.ietf.org/arch/msg/netmod/ShROtXH7aMNDs5HoIiTUa99X0JY)

Even though the tree in sec. 3.1 displays "lower-port" as optional, in
reality ietf-packet-fields.yang still has this leaf as "mandatory true;"
in both "source-port-range" and "destination-port-range".

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 15 Jul 2015 15:50:44 +0200

Lada,

Our original intention was to be able to define wild cards for source and destination ports, but what you are suggesting is also an option and I agree your suggestion is better, so adding presence statement to port containers, as in example below, would be the right solution

grouping acl-transport-header-fields {
    description
      "Transport header fields";
    container source-port-range {
      presence “Enables source port range”;
      description
        "Inclusive range representing source ports to be used.
        When only lower-port is present, it represents a single port.";
      :
      :

Have fixed it in the model and will update on Monday the draft

Dean

> On Jul 14, 2015, at 3:26 PM, Ladislav Lhotka <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 15 Jul 2015 17:49:10 +0200

Lada, Dean,

> Have fixed it in the model and will update on Monday the draft

Another alternative is to leave the container as np-container, and make the elements optional instead. This reduces the number of elements in the configuration database and number of constraints the operator has to abide by (might forget) and the system has to check. The expressiveness is the same.

container source-port-range {
  description "Specification of source port or port range.";
  leaf lower-port {
    type inet:port-number;
    description "When set, specifies the specific port or lower bound of the port range this ACE rule applies to.";
  }
  leaf upper-port {
    type inet:port-number;
    description "When set, specifies the upper bound of the port range this ACE rule applies to. The lower-port must also be set.";
    must ". > ../lower-port" {
      description "This expression is only true if lower-port exists and is less than this element.";
      error-message "Lower-port is required, and must be less than upper-port";
    }
  }
}

/jan

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Jul 2015 10:00:16 +0200

Jan Lindblad <[email-masked]> writes:

> Another alternative is to leave the container as np-container, and
> make the elements optional instead. This reduces the number of
> elements in the configuration database and number of constraints the
> operator has to abide by (might forget) and the system has to
> check. The expressiveness is the same.

I don't see why the presence container should increase the number of
elements in the configuration database. Either way, the
"source-port-range" container may be present or not.

The constraints should also be the same: If "source-port-range"
specification is present, then "lower-port" is mandatory, and
"upper-port" (if present) must be greater than "lower-port".

I think the setup with presence container is the most logical one, and
"mandatory true" on "lower-port" is a schema constraint which can be
checked even in candidate.

Lada

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 16 Jul 2015 10:19:39 +0200

Lada,

This is no big deal, both solutions would work. Let me anyhow demonstrate the difference I'm pointing at.

Presence-solution:

Objects that have a footprint in the data store:
+ p-container source-port-range
+ leaf lower-port
+ leaf upper-port
i.e. 3 objects for an operator and system to track

Constraints:
+ mandatory true stmt on lower-port
+ must stmt on upper-port
i.e. 2 constraints for operators to abide by and systems to check.

Must-solution:

Objects that have a footprint in the data store:
+ leaf lower-port
+ leaf upper-port
i.e. 2 objects for an operator and system to track

Constraints:
+ must stmt on upper-port
i.e. 1 constraint for operators to abide by and systems to check.

This means the must-solution takes less space and less time to check. More importantly it has one failure mode less than the presence-solution. The operator might create source-port-range, but not set lower port. This is not possible in the must-solution. Nit pick differences, I know. I can live with either solution, but lean slightly towards the must-solution. In my mind it's simpler.

/jan

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Jul 2015 13:09:59 +0200

> On 16 Jul 2015, at 10:19, Jan Lindblad <[email-masked]> wrote:
> 
> Lada,
> 

I think the number of “objects” in either case is implementation-specific. YANG has no notion of objects.

> i.e. 1 constraint for operators to abide by and systems to check.

But we have in fact two constraints: if upper-port exists, then
- lower-port must also exist
- upper-port > lower-port

It is just the way XPath works that both are covered by one expression.

Of course, I am biased towards schema-based validation, and for it “mandatory true” is much more valuable. Actually, one could argue that the “mandatory” statement can be replaced with “must” constraints entirely.

Lada