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
>>> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
