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

[John Strassner <[e-mail]>]

Hi Will,

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

   (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) <[e-mail]
> wrote:

> Dear John,
>
>
>
> Many thx for your review and helpful comments. Inline.
>
>
>
>
>
> *From:* John Strassner [mailto:[e-mail]]
> *Sent:* Tuesday, July 19, 2016 5:38 PM
> *To:* [e-mail]
> *Cc:* Liushucheng (Will)
> *Subject:* BRIEF comments on
> draft-liu-supa-policy-based-management-framework-01
>
>
>
> 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>
>
> *[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
>
>
>
> (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>
>
> *[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)
>



-- 
regards,
John