Re: FPC: Move Descriptor-/Action-Value into Rule
"Bertz, Lyle T [CTO]" <[email protected]> Tue, 28 Nov 2017 18:42:15 +0000
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <a445225da96f491ba744c560db79d803__14393.968441482$1511894575$gmane$org@plswe13m04.ad.sprint.com> |
--===============8774361856001504375== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_a445225da96f491ba744c560db79d803plswe13m04adsprintcom_" --_000_a445225da96f491ba744c560db79d803plswe13m04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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]>; [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. --_000_a445225da96f491ba744c560db79d803plswe13m04adsprintcom_ Content-Type: text/html; charset="us-ascii" 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:0in; 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:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; 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:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma",sans-serif;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; 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-reply; font-family:"Calibri",sans-serif; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:70.85pt 70.85pt 56.7pt 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 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 0in = 0in 0in"> <p class=3D"MsoNormal"><b>From:</b> Marco Liebsch [mailto:Marco.Liebsch@nec= lab.eu] <br> <b>Sent:</b> Tuesday, November 28, 2017 9:54 AM<br> <b>To:</b> Bertz, Lyle T [CTO] <[email protected]>; [email protected]= g<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 0in = 0in 0in"> <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:-.25in"><span style=3D"c= olor:#1F497D">-</span><span style=3D"font-size:7.0pt;font-family:"Time= s 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:-.25in"><span style=3D"c= olor:#1F497D">-</span><span style=3D"font-size:7.0pt;font-family:"Time= s 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:.5in"><span style=3D"color:#1F4= 97D">“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:.5in"><span style=3D"color:#1F4= 97D">Descriptor-Match-Type =3D AND<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:.5in"><span style=3D"color:#1F4= 97D">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:.5in;text-indent:.5in"><span st= yle=3D"color:#1F497D">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"> &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:.5in"><span style=3D"color:#1F4= 97D">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:.5in"><span style=3D"color:#1F4= 97D">Descriptor-Match-Type =3D AND<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-indent:.5in"><span style=3D"color:#1F4= 97D">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:.5in;text-indent:.5in"><span st= yle=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:-.25in"><span style=3D"f= ont-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7.= 0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nbs= p; </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:-.25in"><span style=3D"f= ont-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7.= 0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nbs= p; </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:-.25in"><span style=3D"f= ont-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7.= 0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nbs= p; </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:-.25in"><span style=3D"f= ont-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7.= 0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nbs= p; </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:-.25in"><span style=3D"f= ont-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7.= 0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nbs= p; </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:-.25in"><span style=3D"f= ont-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7.= 0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nbs= p; </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:-.25in"><span style=3D"f= ont-family:Symbol;color:#1F497D">·</span><span style=3D"font-size:7.= 0pt;font-family:"Times New Roman",serif;color:#1F497D"> &nbs= p; </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 0in = 0in 0in"> <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 0in = 0in 0in"> <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> </body> </html> --_000_a445225da96f491ba744c560db79d803plswe13m04adsprintcom_-- --===============8774361856001504375== 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 --===============8774361856001504375==--