Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

2017-11-20 Thread Bertz, Lyle T [CTO]
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 

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

2017-11-20 Thread Satoru Matsushima
Thank you Marco for capturing my proposal.

My intention is that the agent should define descriptor/action-definition 
without concrete value so that rules can use them and the rules can define 
concrete values.
Otherwise the agent should define descriptor/action-definitions for each rules 
which seems no make sense to me.

So descriptor and action instantiation with concrete value should be defined in 
Rule definition subtree. So deleting Descriptor-Value from 
Descriptor-Definition subtree, deleting Action-Value from Action-Definition 
subtree and move them under Descriptor-Reference and Action-Reference 
respectively, is my proposal.

If you think it seems weird that reference tree has not just reference, I’d 
propose like following:

OLD:
  +-[Policy]
  |  +-[Policy-Definition] 
  |  | +-[Policy-Id]  (M)
  |  | +-[Rule-Reference] Set (M)
  |  | +-[Precedence]  (M)
  |  | +-[Rule-Id-Reference] (M)
  |  +-[Rule-Definition] 
  |  | +-[Rule-Id]  (M)
  |  | +-[Descriptor-Match-Type] (M)
  |  | +-[Descriptor-Reference] 
  |  | |+-[Descriptor-Id-Reference]
  |  | |+-[Direction] (O)
  |  | +-[Action-Reference] 
  |  |  +-[Action-Id-Reference]
  |  |  +-[Action-Order]
  |  +-[Descriptor-Definition] 
  |  | +-[Descriptor -Id]  (M)
  |  | +-[Descriptor-Type]
  |  | +-[Descriptor-Value]
  |  +-[Action-Definition] 
  |+-[Action-Id]  (M)
  |+-[Action-Type]
  |+-[Action-Value]
  |

NEW:
  +-[Policy]
  |  +-[Policy-Definition] 
  |  | +-[Policy-Id]  (M)
  |  | +-[Rule-Reference] Set (M)
  |  | +-[Precedence]  (M)
  |  | +-[Rule-Id-Reference] (M)
  |  +-[Rule-Definition] 
  |  | +-[Rule-Id]  (M)
  |  | +-[Descriptor-Match-Type] (M)
  |  | +-[Descriptor-Instance] 
  |  | |+-[Descriptor-Id-Reference]
  |  | |+-[Descriptor-Value]
  |  | |+-[Direction] (O)
  |  | +-[Action-Instance] 
  |  |  +-[Action-Id-Reference]
  |  |  +-[Action-Order]
  |  |  +-[Action-Value]
  |  +-[Descriptor-Definition] 
  |  | +-[Descriptor -Id]  (M)
  |  | +-[Descriptor-Type]
  |  +-[Action-Definition] 
  |+-[Action-Id]  (M)
  |+-[Action-Type]
  |

Cheers,
--satoru

> 2017/11/17 0:41、Marco Liebsch のメール:
> 
> Another proposal: 
> To not disrupt descriptors and actions by removing attributes that belong 
> together (ID-Type-Value), what about keeping the current format and apply a 
> new attribute 'x-value-settings' to Descriptor-Reference and Action-Reference 
> respectively?
> This should follow define once- use many paradigm.
>  
> Ending up in this:
>  
>   +-[Policy]
>   |  +-[Policy-Definition] 
>   |  | +-[Policy-Id]  (M)
>   |  | +-[Rule-Reference] Set (M)
>   |  | +-[Precedence]  (M)
>   |  | +-[Rule-Id-Reference] (M)
>   |  +-[Rule-Definition] 
>   |  | +-[Rule-Id]  (M)
>   |  | +-[Descriptor-Match-Type] (M)
>   |  | +-[Descriptor-Reference] 
>   |  | |+-[Descriptor-Id-Reference]
>   |  | |+-[Direction] (O)
>   |  | |+-[Descriptor-Value-Settings] (O)
>   |  | +-[Action-Reference] 
>   |  |  +-[Action-Id-Reference]
>   |  |  +-[Action-Order]
>   |  |  +-[Action-Value-Settings] (O)
>   |  +-[Descriptor-Definition] 
>   |  | +-[Descriptor -Id]  (M)
>   |  | +-[Descriptor-Type]
>   |  | +-[Descriptor-Value]
>   |  +-[Action-Definition] 
>   |+-[Action-Id]  (M)
>   |+-[Action-Type]
>   |+-[Action-Value]
>  
>  
> marco
>  
>  
>  
>  
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
> Sent: Donnerstag, 16. November 2017 16:33
> To: dmm@ietf.org
> Subject: [DMM] FPC: Move Descriptor-/Action-Value into Rule
>  
> Proposal from Satoru: Move Action-Value to 
> [Rule-Definition]->[Action-Reference]. Same