Now I seems I’m confused when I see what does the type define. Does the type define type of value, or type of action/descritor?
Cheers, --satoru > 2017/11/28 14:11、Moses, Danny <[email protected]>のメール: > > I am OK with the current structure. > > From: dmm [mailto:[email protected]] On Behalf Of Marco Liebsch > Sent: Tuesday, November 28, 2017 23:45 > To: Bertz, Lyle T [CTO] <[email protected]>; [email protected] > Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule > > So, then I don’t see the point of changing the current structure. Other > opinions? > > From: Bertz, Lyle T [CTO] [mailto:[email protected]] > Sent: Dienstag, 28. November 2017 19:42 > To: Marco Liebsch; [email protected] > Subject: RE: FPC: Move Descriptor-/Action-Value into Rule > > I intentionally left out my opinion from the analysis. I am against both as > the reusability for a value of a Descriptor/Action (especially descriptor) > does not meet the define once, use many objective for Descriptors. The > define once, use many for Rule re-use is already present in Policy. > > From: Marco Liebsch [mailto:[email protected]] > Sent: Tuesday, November 28, 2017 9:54 AM > To: Bertz, Lyle T [CTO] <[email protected]>; [email protected] > Subject: RE: FPC: Move Descriptor-/Action-Value into Rule > > Hi Lyle, > > I see the analysis you brought, thanks for that. My proposal #2 is not my > preference as it was > only an attempt to extend and match what Satoru had in mind without losing > the value in current > descriptors/actions. Maybe it did not help ;-) > > I just see that an action value belongs to an actions type. Clearly there are > types which don’t require > a value, e.g. drop. Here value is void and re-usability is ensured, IMO. > But moving the value entirely out of action / descriptor I just saw > shortcomings. > > So, you brought examples and arguments against proposal #1 and proposal #2. > But I could not conclude if there are any preferences or alternative? Do we > leave it as it is now? > > marco > > > From: Bertz, Lyle T [CTO] [mailto:[email protected]] > Sent: Montag, 20. November 2017 15:15 > To: Marco Liebsch; [email protected] > Subject: RE: FPC: Move Descriptor-/Action-Value into Rule > > 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 = 222222 > Descriptor-Type = IPFilterRule > Action-Definition > Action-Id = 111111 > Action-Type = deny (or drop) > Rule-Definition > Rule-Id = 21231 > Descriptor-Match-Type = AND > Descriptor-Reference > Descriptor-Id-Reference = 222222 > Descriptor-Value = in ip from any to assigned 22 > Action-Reference > Action-Id-Reference = 111111 > > 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 = 222222 > Descriptor-Type = IPFilterRule > Descriptor-Value = in ip from any to assigned 22 > Action-Definition > Action-Id = 111111 > Action-Type = deny (or drop) > Rule-Definition > Rule-Id = 21231 > Descriptor-Match-Type = AND > Descriptor-Reference > Descriptor-Id-Reference = 222222 > Descriptor-Value-Settings = [ assign = … ] > Action-Reference > Action-Id-Reference = 111111 > > 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 <L-Key> > 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 Embedded-Rule and/or Assigned-Policy-Reference of the DPN. > In this case these values are important to the assigned DPN but are not the > same value if another DPN was assigned to support the same rules. > · Context-Settings-Complementary – Assigned at the Mobility-Context > level and impacts one or more DPNs. > > In our example the value of ‘assigned’ would be the Delegated-IP-Prefix and > placed under the Context-Settings-Complementary. > > For Proposal 2 to make sense the setting MUST not be in any of the existing > Settings locations. Therefore it is a value that MUST NOT be tied to the > Mobility-Context, DPN Interface or the fact that a DPN was assigned to > enforce a Rule. My question is what example could we come up with that > meets this criteria that is not met by adding another Descriptor or Action? I > cannot think of one but if we can Proposal 2 makes sense but not necessarily > for both Actions and Descriptors. > > > From: dmm [mailto:[email protected]] On Behalf Of Marco Liebsch > Sent: Thursday, November 16, 2017 9:42 AM > To: Marco Liebsch <[email protected]>; [email protected] > Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule > > 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] <Set> > | | +-[Policy-Id] <G-Key> (M) > | | +-[Rule-Reference] Set (M) > | | +-[Precedence] <L-Key> (M) > | | +-[Rule-Id-Reference] (M) > | +-[Rule-Definition] <Set> > | | +-[Rule-Id] <L-Key> (M) > | | +-[Descriptor-Match-Type] (M) > | | +-[Descriptor-Reference] <Set> > | | | +-[Descriptor-Id-Reference] > | | | +-[Direction] (O) > | | | +-[Descriptor-Value-Settings] (O) > | | +-[Action-Reference] <Set> > | | +-[Action-Id-Reference] > | | +-[Action-Order] > | | +-[Action-Value-Settings] (O) > | +-[Descriptor-Definition] <Set> > | | +-[Descriptor -Id] <L-Key> (M) > | | +-[Descriptor-Type] > | | +-[Descriptor-Value] > | +-[Action-Definition] <Set> > | +-[Action-Id] <L-Key> (M) > | +-[Action-Type] > | +-[Action-Value] > > > marco > > > > > From: dmm [mailto:[email protected]] On Behalf Of Marco Liebsch > Sent: Donnerstag, 16. November 2017 16:33 > To: [email protected] > Subject: [DMM] FPC: Move Descriptor-/Action-Value into Rule > > Proposal from Satoru: Move Action-Value to > [Rule-Definition]->[Action-Reference]. Same for Descriptor-Value, which may > go to [Rule-Definition]->[Action-Definition]. > > Reason: To make sure “Define once, use many” throughout the models. > > What to change: > > Current Policy substructure looks as follows: > > +-[Policy] > | +-[Policy-Definition] <Set> > | | +-[Policy-Id] <G-Key> (M) > | | +-[Rule-Reference] Set (M) > | | +-[Precedence] <L-Key> (M) > | | +-[Rule-Id-Reference] (M) > | +-[Rule-Definition] <Set> > | | +-[Rule-Id] <L-Key> (M) > | | +-[Descriptor-Match-Type] (M) > | | +-[Descriptor-Reference] <Set> > | | | +-[Descriptor-Id-Reference] > | | | +-[Direction] (O) > | | +-[Action-Reference] <Set> > | | +-[Action-Id-Reference] > | | +-[Action-Order] > | +-[Descriptor-Definition] <Set> > | | +-[Descriptor -Id] <L-Key> (M) > | | +-[Descriptor-Type] > | | +-[Descriptor-Value] > | +-[Action-Definition] <Set> > | +-[Action-Id] <L-Key> (M) > | +-[Action-Type] > | +-[Action-Value] > > > > Proposed updated Policy substructure: > > +-[Policy] > | +-[Policy-Definition] <Set> > | | +-[Policy-Id] <G-Key> (M) > | | +-[Rule-Reference] Set (M) > | | +-[Precedence] <L-Key> (M) > | | +-[Rule-Id-Reference] (M) > | +-[Rule-Definition] <Set> > | | +-[Rule-Id] <L-Key> (M) > | | +-[Descriptor-Match-Type] (M) > | | +-[Descriptor-Reference] <Set> > | | | +-[Descriptor-Id-Reference] > | | | +-[Direction] (O) > | | | +-[Descriptor-Value] > | | | > | | +-[Action-Reference] <Set> > | | +-[Action-Id-Reference] > | | +-[Action-Order] > | | +-[Action-Value] > | | > | +-[Descriptor-Definition] <Set> > | | +-[Descriptor -Id] <L-Key> (M) > | | +-[Descriptor-Type] > | +-[Action-Definition] <Set> > | +-[Action-Id] <L-Key> (M) > | +-[Action-Type] > > > > > > This e-mail may contain Sprint proprietary information intended for the sole > use of the recipient(s). Any use by others is prohibited. If you are not the > intended recipient, please contact the sender and delete all copies of the > message. > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
