Lyle, sorry for my late response. > [...]
> Type of the accompanying value. Ah, okay. > 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 It sounds reasonable for me, define a type of value instead of a concrete value. So do we agree to change “Descriptor/Action-Value” to “Descriptor/Action-Value-Type” in Descriptor/Action-Definition set? > > 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). I think so too. cheers, --satoru > > > > -----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
