Marco,
Thank you for the write up of both proposals. Forgive the length of the
response but I wanted to provide concrete examples based upon the existing data
types.
Summary, see below for examples and details:
- Satoru's Proposal (Proposal 1) - the use of only ID/Type could be
replaced by making the Type a U-Key (similar to a registry or identity in
YANG). In any arrangement though only the Type could be use. The downside for
Proposal 1 is reusability.
- Marco's Proposal (Proposal 2) - To make sense the setting MUST not
be in any of the existing Settings, i.e. it is a setting that MUST NOT be tied
to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to
enforce a Rule. Does such an example exist?
>> My Opinion <
I would not pursue Proposal 1 due to the loss of reusability which is a key
benefit of entities under the Policy Model.
I would not pursue Proposal 2 if we cannot find clear examples that the
settings can be placed in other settings locations. I cannot think of an
example at this time but I am just one person and hope the team can provide
such examples.
Lyle
>> Detail <<<
Let's take a step back. Consider the IPFilterRule (RFC 6733) to block inbound
port 22 traffic (even from itself)
"deny in ip from any to assigned 22"
Recall that from 6733, "The keyword "assigned" is the address or set of
addresses assigned to the terminal."
If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am making
up a new type here) and provide a value of descriptor "in ip from any to
assigned 22" you will note the only Setting to deal with here is 'assigned'.
In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor
example as
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference
Descriptor-Id-Reference = 22
Descriptor-Value = in ip from any to assigned 22
Action-Reference
Action-Id-Reference = 11
We see the tradeoffs clearly in this example, when the value is directly
determined by the type as in the deny Action-Type, the Action Reference is
quite small. In the case of the Descriptor we see the value is still
incomplete and the setting 'assigned' is applied.
For Marco's proposal, we will call it Proposal 2:
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Descriptor-Value = in ip from any to assigned 22
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference
Descriptor-Id-Reference = 22
Descriptor-Value-Settings = [ assign = ... ]
Action-Reference
Action-Id-Reference = 11
For Proposal 1, the use of only ID/Type could be replaced by making the Type a
U-Key (similar to a registry or identity in YANG). In any arrangement though
only the Type could be used. The result would be the elimination of the
Descriptor-Definition and Action-Defintion.
The downside for Proposal 1 is reusability. If I wanted to reuse the value "in
ip from any to assigned 22" with a different list of Descriptors then it must
be redefined in the model. This is due to the fact that
'Descriptor-Id-Reference' points to an entry in the Descriptors-Definitions
List. If I made a local key then reuse is possible but now I need a local key
for each Descriptor and compound key of Rule-Id / Descriptor-Id in the
entry. This also becomes problematic when the Descriptors are smaller than
the Identifiers that reference them.
For Proposal 2, the idea is to permit settings (variable substitution) to occur
within the Rule components. In the I-D we have settings in the following
locations:
* Interface-Settings in the DPN - Settings that are important for an
interface but not required to be known during DPN Selection.
* Interface-Settings in the DPN-Type - Settings that are crucial to DPN
interface suitability during DPN selection.
* Interface-Settings in the DPN-Peer-Group - Settings that MUST be used
when the specified DPN-Peer-Group is being communicated to. This is used for
inter-operator or cross-border communications.
* Policy-Settings in Configurable-Policy - Settings that apply to a
Configurable-Policy on a DPN. Recall that Configurable-Policy affects MULTIPLE
Mobility-Contexts (Mobility Sessions).
* Within a Mobility Context we have
* DPN-Settings-Complementary in the DPN-References - Settings
applicable to the