> On 16 Jul 2015, at 10:19, Jan Lindblad <[email protected]> wrote: > > 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
I think the number of “objects” in either case is implementation-specific. YANG
has no notion of objects.
>
> Constraints:
> + must stmt on upper-port
> 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
>
>
> 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
>
>
>
>
>
>>>> 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
>>>
>>> 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
>
>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
