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