Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
Wrt "So do we agree to change “Descriptor/Action-Value” to “Descriptor/Action-Value-Type” in Descriptor/Action-Definition set?" < I am okay with that. -Original Message- From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] Sent: Monday, December 11, 2017 8:37 PM To: Bertz, Lyle T [CTO] Cc: Moses, Danny ; dmm@ietf.org Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule 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 = 22 >>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 > 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 のメール: >> >> 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] ; 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] ; 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 NO
Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
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 = 22 >>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 > 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 のメール: >> >> 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] ; 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] ; 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 th
Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
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 = 22 > 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 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 のメール: > > 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] ; 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] ; 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.” > > I
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 のメール: > > 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] ; 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] ; 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 = 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 assign
Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
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] ; 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<mailto: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] mailto:lyle.t.be...@sprint.com>>; dmm@ietf.org<mailto: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<mailto: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 = 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-Ty
Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
d-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 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 mailto:marco.lieb...@neclab.eu>>; dmm@ietf.org<mailto: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] | | +-[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<mailto:dmm@ietf.org> Subject: [DMM] FPC: Move Descriptor-/Action-Value into Rule Proposal from Satoru:
Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
d. 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 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 mailto:marco.lieb...@neclab.eu>>; dmm@ietf.org<mailto: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] | | +-[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<mailto: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]
Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
ound 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 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 mailto:marco.lieb...@neclab.eu>>; dmm@ietf.org<mailto: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] | | +-[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<mailto: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] | | +-[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] | | |+-[Direc
Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
rable-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 ; 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] | | +-[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<mailto: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] | | +-[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] Proposed updated Policy substructure: +-[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] | | |
Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
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 Descrip
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] | | +-[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 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] | | +-[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] Proposed updated Policy substructure: +-[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] | | | | | +-[Action-Reference] | | +-[Action-Id-Reference] | | +-[Action-Order] | | +-[Action-Value] | | | +-[Descriptor-Definition] | | +-[Descriptor -Id] (M) | | +-[Descriptor-Type] | +-[Action-Definition] |+-[Action-Id] (M) |+-[Action-Type] ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[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] | | +-[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] Proposed updated Policy substructure: +-[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] | | | | | +-[Action-Reference] | | +-[Action-Id-Reference] | | +-[Action-Order] | | +-[Action-Value] | | | +-[Descriptor-Definition] | | +-[Descriptor -Id] (M) | | +-[Descriptor-Type] | +-[Action-Definition] |+-[Action-Id] (M) |+-[Action-Type] ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
