Type of the accompanying value. There was a line continuation that made reading it awkward in some e-mail clients.
In Descriptors it is the type of Descriptor Value > Descriptor-Id = 222222 > Descriptor-Type = IPFilterRule > Descriptor-Value = in ip from any to assigned 22 In Actions it is the type of Action Value However, we gave an Action Type (Drop) where the value is unnecessary. The same would be for the type 'Permit'. In other standards we use a boolean value 'Gate' (True=Drop; False=Permit). -----Original Message----- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima Sent: Tuesday, November 28, 2017 7:32 PM To: Moses, Danny <danny.mo...@intel.com> Cc: dmm@ietf.org Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule 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 <danny.mo...@intel.com>のメール: > > I am OK with the current structure. > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch > Sent: Tuesday, November 28, 2017 23:45 > To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>; dmm@ietf.org > 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:lyle.t.be...@sprint.com] > Sent: Dienstag, 28. November 2017 19:42 > To: Marco Liebsch; dmm@ietf.org > 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:marco.lieb...@neclab.eu] > Sent: Tuesday, November 28, 2017 9:54 AM > To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>; dmm@ietf.org > 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:lyle.t.be...@sprint.com] > Sent: Montag, 20. November 2017 15:15 > To: Marco Liebsch; dmm@ietf.org > 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:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch > Sent: Thursday, November 16, 2017 9:42 AM > To: Marco Liebsch <marco.lieb...@neclab.eu>; dmm@ietf.org > 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: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 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 > dmm@ietf.org > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7Clyle.t.bertz%40sprin > t.com%7Cda7368dfcd0d4abc0f9d08d536c91734%7C4f8bc0acbd784bf5b55f1b31301 > d9adf%7C0%7C0%7C636475159666617604&sdata=iFlTfWnkOV2crr22vt9gJHihnkTul > 1PS9xor7we8oQQ%3D&reserved=0 _______________________________________________ dmm mailing list dmm@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Cda7368dfcd0d4abc0f9d08d536c91734%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636475159666617604&sdata=iFlTfWnkOV2crr22vt9gJHihnkTul1PS9xor7we8oQQ%3D&reserved=0 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
