Re: FPC: Move Descriptor-/Action-Value into Rule
"Moses, Danny" <[email protected]> Tue, 28 Nov 2017 22:11:29 +0000
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <F0CF5715D3D1884BAC731EA1103AC2813EA34CC2@HASMSX106.ger.corp.intel.com> |
--===============8991252185859988025== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813EA34CC2HASMSX106gercor_" --_000_F0CF5715D3D1884BAC731EA1103AC2813EA34CC2HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 opi= nions? From: Bertz, Lyle T [CTO] [mailto:[email protected]] Sent: Dienstag, 28. November 2017 19:42 To: Marco Liebsch; [email protected]<mailto:[email protected]> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule I intentionally left out my opinion from the analysis. I am against both a= s the reusability for a value of a Descriptor/Action (especially descriptor= ) does not meet the define once, use many objective for Descriptors. The d= efine 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]<mailto:Lyle.T.Bertz@sprint= .com>>; [email protected]<mailto:[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 p= reference 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 a= re 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 shortco= mings. 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]<mailto:[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 re= sponse but I wanted to provide concrete examples based upon the existing da= ta types. Summary, see below for examples and details: - Satoru's Proposal (Proposal 1) - the use of only ID/Type could b= e 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 n= ot be in any of the existing Settings, i.e. it is a setting that MUST NOT b= e tied to the Mobility-Context, DPN Interface or the fact that a DPN was as= signed 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 set= tings can be placed in other settings locations. I cannot think of an exam= ple at this time but I am just one person and hope the team can provide suc= h examples. Lyle >>>>>>>>>> Detail <<<<<<<<<<< Let's take a step back. Consider the IPFilterRule (RFC 6733) to block inb= ound 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 add= resses assigned to the terminal." If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am maki= ng 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 'assigne= d'. In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor= example as Descriptor-Definition Descriptor-Id =3D 222222 Descriptor-Type =3D IPFilterRule Action-Definition Action-Id =3D 111111 Action-Type =3D deny (or drop) Rule-Definition Rule-Id =3D 21231 Descriptor-Match-Type =3D AND Descriptor-Reference Descriptor-Id-Reference =3D 222222 Descriptor-Value =3D in ip from any to assigned 22 Action-Reference Action-Id-Reference =3D 111111 We see the tradeoffs clearly in this example, when the value is directly de= termined by the type as in the deny Action-Type, the Action Reference is qu= ite small. In the case of the Descriptor we see the value is still incompl= ete and the setting 'assigned' is applied. For Marco's proposal, we will call it Proposal 2: Descriptor-Definition Descriptor-Id =3D 222222 Descriptor-Type =3D IPFilterRule Descriptor-Value =3D in ip from any to assigned 22 Action-Definition Action-Id =3D 111111 Action-Type =3D deny (or drop) Rule-Definition Rule-Id =3D 21231 Descriptor-Match-Type =3D AND Descriptor-Reference Descriptor-Id-Reference =3D 222222 Descriptor-Value-Settings =3D [ assign =3D ... ] Action-Reference Action-Id-Reference =3D 111111 For Proposal 1, the use of only ID/Type could be replaced by making the Typ= e a U-Key (similar to a registry or identity in YANG). In any arrangement t= hough 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 'Descripto= r-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 e= ach Descriptor and compound key of Rule-Id / Descriptor-Id <L-Key> in the e= ntry. 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 o= ccur within the Rule components. In the I-D we have settings in the follow= ing 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 us= ed 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 MUL= TIPLE Mobility-Contexts (Mobility Sessions). * Within a Mobility Context we have * DPN-Settings-Complementary in the DPN-References - Settings appli= cable 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 s= ame 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 enfo= rce 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 can= not think of one but if we can Proposal 2 makes sense but not necessarily f= or 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]<mailto:[email protected]>>= ; [email protected]<mailto:[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 t= ogether (ID-Type-Value), what about keeping the current format and apply a = new attribute 'x-value-settings' to Descriptor-Reference and Action-Referen= ce 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]<mailto:[email protected]> Subject: [DMM] FPC: Move Descriptor-/Action-Value into Rule Proposal from Satoru: Move Action-Value to [Rule-Definition]->[Action-Refer= ence]. Same for Descriptor-Value, which may go to [Rule-Definition]->[Actio= n-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 sol= e 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. --_000_F0CF5715D3D1884BAC731EA1103AC2813EA34CC2HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Courier New";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma",sans-serif;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:36.0pt; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:"Calibri",sans-serif;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma",sans-serif;} span.EmailStyle24 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:windowtext;} span.EmailStyle25 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle26 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle27 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle28 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle29 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;} span.EmailStyle30 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:70.85pt 70.85pt 2.0cm 70.85pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">I am OK with the curre= nt structure.<o:p></o:p></span></p> <p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"color:#1F= 497D"><o:p> </o:p></span></a></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><a name=3D"_____replyseparator"></a><b>From:</b> dmm= [mailto:[email protected]] <b>On Behalf Of </b>Marco Liebsch<br> <b>Sent:</b> Tuesday, November 28, 2017 23:45<br> <b>To:</b> Bertz, Lyle T [CTO] <[email protected]>; [email protected]= g<br> <b>Subject:</b> Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule<o:p>= </o:p></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">So, then I don’t= see the point of changing the current structure. Other opinions?<o:p></o:p= ></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma",sans-serif">From:</span></b><span style=3D"font-size:10.0pt;f= ont-family:"Tahoma",sans-serif"> Bertz, Lyle T [CTO] [<a href=3D"= mailto:[email protected]">mailto:[email protected]</a>] <br> <b>Sent:</b> Dienstag, 28. November 2017 19:42<br> <b>To:</b> Marco Liebsch; <a href=3D"mailto:[email protected]">[email protected]</a><= br> <b>Subject:</b> RE: FPC: Move Descriptor-/Action-Value into Rule<o:p></o:p>= </span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"DE"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">I intentionally left o= ut my opinion from the analysis. I am against both as the reusability= for a value of a Descriptor/Action (especially descriptor) does not meet t= he define once, use many objective for Descriptors. The define once, use many for Rule re-use is already present in Policy.<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b>From:</b> Marco Liebsch [<a href=3D"mailto:Marco.= [email protected]">mailto:[email protected]</a>] <br> <b>Sent:</b> Tuesday, November 28, 2017 9:54 AM<br> <b>To:</b> Bertz, Lyle T [CTO] <<a href=3D"mailto:[email protected]= m">[email protected]</a>>; <a href=3D"mailto:[email protected]">[email protected]</a><br> <b>Subject:</b> RE: FPC: Move Descriptor-/Action-Value into Rule<o:p></o:p>= </p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Lyle,<br> <br> I see the analysis you brought, thanks for that. My proposal #2 is not my p= reference as it was<br> only an attempt to extend and match what Satoru had in mind without losing = the value in current<br> descriptors/actions. Maybe it did not help ;-)<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">I just see that an act= ion value belongs to an actions type. Clearly there are types which donR= 17;t require<br> a value, e.g. drop. Here value is void and re-usability is ensured, IMO.<br> But moving the value entirely out of action / descriptor I just saw shortco= mings.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">So, you brought exampl= es and arguments against proposal #1 and proposal #2. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">But I could not conclu= de if there are any preferences or alternative? Do we leave it as it is now= ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">marco<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma",sans-serif">From:</span></b><span style=3D"font-size:10.0pt;f= ont-family:"Tahoma",sans-serif"> Bertz, Lyle T [CTO] [<a href=3D"= mailto:[email protected]">mailto:[email protected]</a>] <br> <b>Sent:</b> Montag, 20. November 2017 15:15<br> <b>To:</b> Marco Liebsch; <a href=3D"mailto:[email protected]">[email protected]</a><= br> <b>Subject:</b> RE: FPC: Move Descriptor-/Action-Value into Rule<o:p></o:p>= </span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"DE"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Marco,<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thank you for the writ= e up of both proposals. Forgive the length of the response but I want= ed to provide concrete examples based upon the existing data types.<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Summary, see below for= examples and details:<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= color:#1F497D">-</span><span style=3D"font-size:7.0pt;font-family:"Tim= es New Roman",serif;color:#1F497D">  = ; </span><span style=3D"color:#1F497D">Satoru’s Proposal (Proposal 1) -= the use of only ID/Type could be replaced by making the Type a U-Key (simi= lar to a registry or identity in YANG). In any arrangement though only the = Type could be use. The downside for Proposal 1 is reusability. <o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= color:#1F497D">-</span><span style=3D"font-size:7.0pt;font-family:"Tim= es New Roman",serif;color:#1F497D">  = ; </span><span style=3D"color:#1F497D">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 Interfa= ce or the fact that a DPN was assigned to enforce a Rule. Does such an example exist?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">>>>>>&g= t;>>>> My Opinion <<<<<<<<<<<&= lt;<<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">I would not pursue Pro= posal 1 due to the loss of reusability which is a key benefit of entities u= nder the Policy Model.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">I would not pursue Pro= posal 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.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Lyle<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">>>>>>&g= t;>>>> Detail <<<<<<<<<<<<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Let’s take a ste= p back. Consider the IPFilterRule (RFC 6733) to block inbound p= ort 22 traffic (even from itself)<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:36.0pt"><span style=3D"color:#1= F497D">“deny in ip from any to assigned 22”<o:p></o:p></span></= p> <pre style=3D"page-break-before:always"><span style=3D"font-family:"Ca= libri",sans-serif;color:#1F497D"><o:p> </o:p></span></pre> <pre style=3D"page-break-before:always"><span style=3D"font-family:"Ca= libri",sans-serif;color:#1F497D">Recall that from 6733, “The key= word "assigned" is the address or set of addresses assigned to th= e terminal.”<o:p></o:p></span></pre> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">If I use a ‘IPFi= lterRule’ Descriptor Type (it is not in the spec; I am making up a ne= w type here) and provide a value of descriptor “in ip from any to ass= igned 22” you will note the only Setting to deal with here is ‘assigned’.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">In Satoru’s prop= osal, we will call it Proposal 1, we could see a Descriptor example as <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Descriptor-Definition<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Descri= ptor-Id =3D 222222 <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Descri= ptor-Type =3D IPFilterRule<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Action-Definition<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Action= -Id =3D 111111<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Action= -Type =3D deny (or drop)<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Rule-Definition <o:p><= /o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Rule-I= d =3D 21231<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:36.0pt"><span style=3D"color:#1= F497D">Descriptor-Match-Type =3D AND<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:36.0pt"><span style=3D"color:#1= F497D">Descriptor-Reference<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span style=3D"color:#1F497D"> &= nbsp; &nb= sp; = Descriptor-Id-Reference =3D 222222<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt;text-indent:36.0pt"><spa= n style=3D"color:#1F497D">Descriptor-Value =3D in ip from any to assigned 2= 2<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Action= -Reference<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; &= nbsp; &nbs= p; Action-Id-Reference =3D 111111<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">We see the tradeoffs c= learly in this example, when the value is directly determined by the type a= s in the deny Action-Type, the Action Reference is quite small. In th= e case of the Descriptor we see the value is still incomplete and the setting ‘assigned’ is applied.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For Marco’s prop= osal, we will call it Proposal 2:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Descriptor-Definition<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Descri= ptor-Id =3D 222222 <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Descri= ptor-Type =3D IPFilterRule<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:36.0pt"><span style=3D"color:#1= F497D">Descriptor-Value =3D in ip from any to assigned 22<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Action-Definition<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Action= -Id =3D 111111<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Action= -Type =3D deny (or drop)<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Rule-Definition <o:p><= /o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Rule-I= d =3D 21231<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:36.0pt"><span style=3D"color:#1= F497D">Descriptor-Match-Type =3D AND<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:36.0pt"><span style=3D"color:#1= F497D">Descriptor-Reference<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span style=3D"color:#1F497D"> &= nbsp; &nb= sp; = Descriptor-Id-Reference =3D 222222<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt;text-indent:36.0pt"><spa= n style=3D"color:#1F497D">Descriptor-Value-Settings =3D [ assign =3D …= ; ]<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; Action= -Reference<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"> &nbs= p; &= nbsp; &nbs= p; Action-Id-Reference =3D 111111<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For Proposal 1, the us= e 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 co= uld be used. The result would be the elimination of the Descriptor-Definition and Action-Defintion.<o:p></o:p><= /span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The downside for Propo= sal 1 is reusability. If I wanted to reuse the value “in ip fro= m any to assigned 22” with a different list of Descriptors then it mu= st be redefined in the model. This is due to the fact that ‘Descriptor-Id-Reference’ points to an entry in the Descr= iptors-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.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For Proposal 2, the id= ea is to permit settings (variable substitution) to occur within the Rule c= omponents. In the I-D we have settings in the following locations:<o:= p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= font-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7= .0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nb= sp; </span><span style=3D"color:#1F497D">Interface-Settings in the DPN - = Settings that are important for an interface but not required to be known d= uring DPN Selection.<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= font-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7= .0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nb= sp; </span><span style=3D"color:#1F497D">Interface-Settings in the DPN-Type = 211; Settings that are crucial to DPN interface suitability during DPN sele= ction.<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= font-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7= .0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nb= sp; </span><span style=3D"color:#1F497D">Interface-Settings in the DPN-Peer-Gro= up – Settings that MUST be used when the specified DPN-Peer-Group is = being communicated to. This is used for inter-operator or cross-border comm= unications. <o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= font-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7= .0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nb= sp; </span><span style=3D"color:#1F497D">Policy-Settings in Configurable-Policy= – Settings that apply to a Configurable-Policy on a DPN. Recal= l that Configurable-Policy affects MULTIPLE Mobility-Contexts (Mobility Ses= sions).<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= font-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7= .0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nb= sp; </span><span style=3D"color:#1F497D">Within a Mobility Context we have <o:p= ></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= font-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7= .0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nb= sp; </span><span style=3D"color:#1F497D">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.<o:p></o:p></span></= p> <p class=3D"MsoListParagraph" style=3D"text-indent:-18.0pt"><span style=3D"= font-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7= .0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nb= sp; </span><span style=3D"color:#1F497D">Context-Settings-Complementary –= Assigned at the Mobility-Context level and impacts one or more DPNs. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">In our example the val= ue of ‘assigned’ would be the Delegated-IP-Prefix and placed un= der the Context-Settings-Complementary.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For Proposal 2 to make= sense the setting MUST not be in any of the existing Settings locations.&n= bsp; 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.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b>From:</b> dmm [<a href=3D"mailto:dmm-bounces@ietf= .org">mailto:[email protected]</a>] <b>On Behalf Of </b>Marco Liebsch<br> <b>Sent:</b> Thursday, November 16, 2017 9:42 AM<br> <b>To:</b> Marco Liebsch <<a href=3D"mailto:[email protected]">Mar= [email protected]</a>>; <a href=3D"mailto:[email protected]">[email protected]</a><br> <b>Subject:</b> Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule<o:p>= </o:p></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Another proposal: <o:p= ></o:p></span></p> <p class=3D"MsoPlainText">To not disrupt descriptors and actions by removin= g attributes that belong together (ID-Type-Value), what about keeping the c= urrent format and apply a new attribute 'x-value-settings' to Descriptor-Re= ference and Action-Reference respectively?<o:p></o:p></p> <p class=3D"MsoPlainText">This should follow define once- use many paradigm= .<o:p></o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText">Ending up in this:<o:p></o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText"> +-[Policy]<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Pol= icy-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Poli= cy-Id] <G-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Reference] Set (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Prec= edence] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Id-Reference] (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Rul= e-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Match-Type] (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Reference] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; | &nbs= p; &= nbsp; +-[Descriptor-Id-Reference]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; | &nbs= p; &= nbsp; +-[Direction] (O)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; | &nbs= p; &= nbsp; +-[Descriptor-Value-Settings] (O)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Acti= on-Reference] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; = &nb= sp; +-[Action-Id-Reference]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; = &n= bsp; +-[Action-Order]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; = &nb= sp; +-[Action-Value-Settings] (O)<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Des= criptor-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor -Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Type]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Value]<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Act= ion-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> |  = ; &= #43;-[Action-Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> <span lang=3D"DE">|  = ; &n= bsp; +-[Action-Type]<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"DE"> |  = ; &n= bsp; +-[Action-Value]<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"DE"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE" style=3D"color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE" style=3D"color:#1F497D">marco<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE" style=3D"color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE" style=3D"color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE" style=3D"color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"DE" style=3D"color:#1F497D"><o:p> = ;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma",sans-serif">From:</span></b><span style=3D"font-size:10.0pt;f= ont-family:"Tahoma",sans-serif"> dmm [<a href=3D"mailto:dmm-bounc= [email protected]">mailto:[email protected]</a>] <b>On Behalf Of </b>Marco Liebsch<br> <b>Sent:</b> Donnerstag, 16. November 2017 16:33<br> <b>To:</b> <a href=3D"mailto:[email protected]">[email protected]</a><br> <b>Subject:</b> [DMM] FPC: Move Descriptor-/Action-Value into Rule<o:p></o:= p></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"DE"><o:p> </o:p></span></p> <p class=3D"MsoNormal">Proposal from Satoru: Move Action-Value to [Rule-Def= inition]->[Action-Reference]. Same for Descriptor-Value, which may go to= [Rule-Definition]->[Action-Definition].<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Reason: To make sure “Define once, use many= 221; throughout the models.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">What to change:<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Current Policy substructure looks as follows:<o:p></= o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoPlainText"> +-[Policy]<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Pol= icy-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Poli= cy-Id] <G-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Reference] Set (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Prec= edence] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Id-Reference] (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Rul= e-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Match-Type] (M) <o:p> </o:p></p> <p class=3D"MsoPlainText"> | |&nbs= p; +-= [Descriptor-Reference] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; | &nbs= p; &= nbsp; +-[Descriptor-Id-Reference]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; | &nbs= p; &= nbsp; +-[Direction] (O)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Acti= on-Reference] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; = &nb= sp; +-[Action-Id-Reference] <o:p></o:p></p> <p class=3D"MsoPlainText"> | |&nbs= p; &= nbsp; &nbs= p; +-[Action-Order]<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Des= criptor-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor -Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Type]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Value]<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Act= ion-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> |  = ; &= #43;-[Action-Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> |  = ; &= #43;-[Action-Type]<o:p></o:p></p> <p class=3D"MsoPlainText"> |  = ; &= #43;-[Action-Value] <o:p></o:p></p> <p class=3D"MsoPlainText"> <o:p></o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText">Proposed updated Policy substructure:<o:p></o:p><= /p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText"> +-[Policy]<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Pol= icy-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Poli= cy-Id] <G-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Reference] Set (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Prec= edence] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Id-Reference] (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Rule= -Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Rule= -Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Match-Type] (M) <o:p> </o:p></p> <p class=3D"MsoPlainText"> | |&nbs= p; +-= [Descriptor-Reference] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; | &nbs= p; &= nbsp; +-[Descriptor-Id-Reference]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; | &nbs= p; &= nbsp; +-[Direction] (O)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; | &nbs= p; &= nbsp; +-[Descriptor-Value]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; |<o:p></o:p= ></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Acti= on-Reference] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> <span lang=3D"DE">|  = ; | = &nb= sp; +-[Action-Id-Reference] <o:p></o:p></span></p> <p class=3D"MsoPlainText"> | |&nbs= p; &= nbsp; &nbs= p; +-[Action-Order]<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; = &nb= sp; +-[Action-Value] <o:p> </o:p></p> <p class=3D"MsoPlainText"> | |<o:p= ></o:p></p> <p class=3D"MsoPlainText"> | +-[Des= criptor-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor -Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> | | &nb= sp; +-[Desc= riptor-Type]<o:p></o:p></p> <p class=3D"MsoPlainText"> | +-[Act= ion-Definition] <Set><o:p></o:p></p> <p class=3D"MsoPlainText"> |  = ; &= #43;-[Action-Id] <L-Key> (M)<o:p></o:p></p> <p class=3D"MsoPlainText"> <span lang=3D"DE">|  = ; &n= bsp; +-[Action-Type]<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"DE"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti= mes New Roman",serif"><o:p> </o:p></span></p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"font-size:12.0pt;font-family:"Times New Roman",serif"> <hr size=3D"3" width=3D"100%" align=3D"center"> </span></div> <p class=3D"MsoNormal"><span style=3D"font-size:7.5pt;font-family:"Ari= al",sans-serif;color:gray"><br> This e-mail may contain Sprint proprietary information intended for the sol= e 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.</span><span style=3D"font-size:12.0pt;font-family:"Times = New Roman",serif"><o:p></o:p></span></p> </div> <p>---------------------------------------------------------------------<br> A member of the Intel Corporation group of companies</p> <p>This e-mail and any attachments may contain confidential material for<br> the sole use of the intended recipient(s). Any review or distribution<br> by others is strictly prohibited. If you are not the intended<br> recipient, please contact the sender and delete all copies.</p></body> </html> --_000_F0CF5715D3D1884BAC731EA1103AC2813EA34CC2HASMSX106gercor_-- --===============8991252185859988025== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm --===============8991252185859988025==--