Subject: [Supa] BRIEF comments on draft-liu-supa-policy-based-management-framework-01

From: John Strassner <[email-masked]>
Date: Tue, 19 Jul 2016 17:37:58 +0200

Hi Will,

here are some brief comments on the above draft for your consideration:

Technical Changes
Page 8:
   (1) policy relies on and is able to adjust service
<jcs> policy manages and can adjust service behavior as necessary </jcs>

   (2) policy relies on network ability provided by resource and is
   able to adjust resource
<jcs> policy manages and can adjust resource behavior as necessary </jcs>

   (3) resource relies on network ability and is able to reserve and
   consume/occupy resource
<jcs> resource hosts service; changing resources may change
service behavior as necessary </jcs>

Page 10

(1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1')

   Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)=
   Implementation; (3')= update of YANG data models; (2')=update of
   EPRIM; (1') = update of GPIM

   The YANG module derived from the GPIM contains concepts and
   terminology for the common operation and administration of policy-
   based systems, as well as an extensible structure for policy rules
   of different paradigms. The YANG module derived from the EPRIM
   extends the generic nature of the GPIM to represent policies using
   an event-condition-action structure.

<jcs>
I suggest the following additional text:
   The above sequence allows for the addition of new, as well as editing
   of existing, model elements in the GPIM and EPRIM. In practice, the
   implementation sequence may be much simpler. Specifically, it is
   unlikely that the GPIM will need to be changed. In addition, changes
   to the EPRIM will likely be focused on fine-tuning the behavior
   offered by a specific set of model elements.
</jcs>

NITS!
Page 3
Please update [SUPA-info-model] to point to
draft-ietf-supa-generic-policy-info-model-01
Should we update [] to point to draft-ietf-netmod-rfc6020bis-14

Pages 3-4
I offer to redraw the figure, there are lines that are past the character
limit

regards,
John

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 19 Jul 2016 22:41:37 +0000

Dear John,

Many thx for your review and helpful comments. Inline.

From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, July 19, 2016 5:38 PM
To: [email-masked]
Cc: Liushucheng (Will)
Subject: BRIEF comments on draft-liu-supa-policy-based-management-framework-01

Hi Will,

Technical Changes
Page 8:

   (3) resource relies on network ability and is able to reserve and
   consume/occupy resource
<jcs> resource hosts service; changing resources may change service behavior as necessary </jcs>
[Will] Thanks for help. I understand what you mean here and will use your sentences in next version. However, there are still some concepts might need to express:

1)     policy need the parameters provided by service/resource, or maybe we can use other way to express the concept of “relies on”(policy need to know there is service created/resource exists before it manages service/resource?)

2)     policy is service-crossing/resource-crossing, in other words, one policy can manage multiple services/resources (1:N relationship)

3)     service is resource-crossing, in other words, one service can use multiple resources (1:M relationship)

Maybe some of they are not necessary to be fully written here. If some should, would you please help to add some words into your sentences?

Page 10

<jcs>
[Will] Agree, will add.

NITS!
Page 3
Please update [SUPA-info-model] to point to draft-ietf-supa-generic-policy-info-model-01
Should we update [] to point to draft-ietf-netmod-rfc6020bis-14
[Will] Yes, will update.

Pages 3-4
I offer to redraw the figure, there are lines that are past the character limit
[Will] Great! Many thanks!

Cheers,
Will (Shucheng LIU)

---

From: Fred Feisullin <[email-masked]>
Date: Tue, 19 Jul 2016 20:04:24 -0700 (PDT)

Well stated clarifications!

Fred

From: John Strassner [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2016 10:38 AM
To: [email-masked]
Cc: Liushucheng (Will)
Subject: [Supa] BRIEF comments on draft-liu-supa-policy-based-management-framework-01

Hi Will,

Technical Changes

Page 8:

Page 10

<jcs>

</jcs>

NITS!

Page 3

Pages 3-4

 

regards,

John

---

From: John Strassner <[email-masked]>
Date: Wed, 20 Jul 2016 15:04:08 +0200

Hi Will,

I'm responding inline, please see <jcs2>..</jcs2> below

*1)*     *policy need the parameters provided by service/resource, or maybe
we can use other way to express the concept of “relies on”(policy need to
know there is service created/resource exists before it manages
service/resource?)*
<jcs2>
Disagree. A Policy doesn't "need to know" that a service is created,
because it is specifying what the end state should be. Put another way, the
policy should be valid regardless of whether the service is currently
instantiated or not. If the service is not instantiated, then the policy
should not be run (or alternatively, the policy should give a benign error
(service does not exist) and not crash (that would be rude). If the service
is instantiated, then the policy runs. In either case, the policy doesn't
need to know if the service or resource is there to perform its function,
right?
</jcs2>

*2)*     *policy is service-crossing/resource-crossing, in other words, one
policy can manage multiple services/resources (1:N relationship) *
<jcs2>
Sure, but what needs to be changed? This is just an issue of the
multiplicity of the PolicyRule? Or am I missing something?
</jcs2>

*3)*     *service is resource-crossing, in other words, one service can use
multiple resources (1:M relationship) *
<jcs2>
Sure, but what needs to be changed? This is just an issue of the
multiplicity of the PolicyRule? Or am I missing something?
</jcs2>

best regards,
John

On Wed, Jul 20, 2016 at 12:41 AM, Liushucheng (Will) <[email-masked]
> wrote:

> *From:* John Strassner [mailto:[email-masked]]
> *Sent:* Tuesday, July 19, 2016 5:38 PM
> *To:* [email-masked]
> *Cc:* Liushucheng (Will)
> *Subject:* BRIEF comments on
> draft-liu-supa-policy-based-management-framework-01
>
>
>
> Hi Will,
>
>
>
> *[Will] Thanks for help. I understand what you mean here and will use your
> sentences in next version. However, there are still some concepts might
> need to express:*
>
> *1)     **policy need the parameters provided by service/resource, or
> maybe we can use other way to express the concept of “relies on”(policy
> need to know there is service created/resource exists before it manages
> service/resource?)*
>
> *2)     **policy is service-crossing/resource-crossing, in other words,
> one policy can manage multiple services/resources (1:N relationship) *
>
> *3)     **service is resource-crossing, in other words, one service can
> use multiple resources (1:M relationship) *
>
>
>
> *Maybe some of they are not necessary to be fully written here. If some
> should, would you please help to add some words into your sentences? *
>
>
>
> Page 10
>
>
>
> *[Will] Agree, will add.*
>
>
>
> NITS!
>
> Page 3
>
> *[Will] Yes, will update.*
>
>
>
> Pages 3-4
>
> *[Will] Great! Many thanks!*
>
>
>
> Cheers,
>
> Will (Shucheng LIU)
>

-- 
regards,
John

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Thu, 21 Jul 2016 10:42:28 +0000

After a offline discussion with John, we agreed to put these sentences into our draft:
“Policies are used to manage behavior. Policies can be applied to services and resources. More importantly, policies can be used to manage how resources are allocated and assigned to services. This enables a single policy to manage multiple services and resources as well as their dependencies.”

Please let us know your thought, thanks!

Cheers,
Will (Shucheng LIU)

From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 3:04 PM
To: Liushucheng (Will)
Cc: [email-masked]
Subject: Re: BRIEF comments on draft-liu-supa-policy-based-management-framework-01

Hi Will,

   (1) policy relies on and is able to adjust service
<jcs> policy manages and can adjust service behavior as necessary </jcs>
1)     policy need the parameters provided by service/resource, or maybe we can use other way to express the concept of “relies on”(policy need to know there is service created/resource exists before it manages service/resource?)
<jcs2>
Disagree. A Policy doesn't "need to know" that a service is created, because it is specifying what the end state should be. Put another way, the policy should be valid regardless of whether the service is currently instantiated or not. If the service is not instantiated, then the policy should not be run (or alternatively, the policy should give a benign error (service does not exist) and not crash (that would be rude). If the service is instantiated, then the policy runs. In either case, the policy doesn't need to know if the service or resource is there to perform its function, right?
</jcs2>

2)     policy is service-crossing/resource-crossing, in other words, one policy can manage multiple services/resources (1:N relationship)
<jcs2>
Sure, but what needs to be changed? This is just an issue of the multiplicity of the PolicyRule? Or am I missing something?
</jcs2>

3)     service is resource-crossing, in other words, one service can use multiple resources (1:M relationship)
<jcs2>
Sure, but what needs to be changed? This is just an issue of the multiplicity of the PolicyRule? Or am I missing something?
</jcs2>

best regards,
John

On Wed, Jul 20, 2016 at 12:41 AM, Liushucheng (Will) <[email-masked]<mailto:[email-masked]>> wrote:
Dear John,

From: John Strassner [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 19, 2016 5:38 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Liushucheng (Will)
Subject: BRIEF comments on draft-liu-supa-policy-based-management-framework-01

Hi Will,

Technical Changes
Page 8:

Page 10

<jcs>

NITS!
Page 3

Pages 3-4

Cheers,
Will (Shucheng LIU)

--
regards,
John