Subject: snmpconf FW: request for feedback: Policy requirements drafts

From: Jon Saperia <[email-masked]>
Date: Mon, 26 Jun 2000 10:39:10 -0400

Below are comments I sent to the Policy list on the usage scenarios.
/jon
----------
> From: Jon Saperia <[email-masked]>
> Date: Mon, 26 Jun 2000 10:29:03 -0400
> To: Hugh Mahon <[email-masked]>, <[email-masked]>, Jon
> Saperia <[email-masked]>
> Subject: Re: request for feedback: Policy requirements drafts
> 
> on 06/19/2000 3:43 PM, Hugh Mahon at [email-masked] wrote:
> 
> Hugh some comments about:
> 
> ~hmahon/draft-mahon-policy-use-00.txt
> 
> First, I find it helpful for work items that are the result of or intended
> products of an active WG to be published on the WG page. Helps with
> references and keeping current.
> 
> Page 4. 
> 
>> Policy Management is a way for the Network Administrator to
>> pro-actively manage the network, not simply  react  to  how
>> users  use  the network.  The intent is to ensure the value
>> of a shared resource, which is what the network is, not  to
>> take anything away from the users.
> 
> The second sentence could use a bit of rewording for clarity. I also have an
> issue with what is not included here. Policy is also to cause a consistent
> behavior or configuration. For example, I want to have all systems from XYZ
> vendor that are model 2's running release 4.4. I want to make sure we
> support they type of shared resource provisioning for 'quality of service'
> type examples but we should also include examples such as the one I
> describe. as well.
> 
> Page 7 - 8.
> 
>> Once the administrator has authored these rules they  would
>> be  committed  to  a repository.  How the Policy Management
>> Application chooses to order operations  is  implementation
>> dependent, but the Policy Rules must be grouped together to
>> form a Policy Group.  Once grouped the Policy  can  option-
>> ally  be  run  through tools to determine if there are con-
>> flicts between Policy Rules within the Policy.
>> 
> 
> It may not be obvious to unfamiliar readers what is meant by a policy group
> here. I think the document would benefit from a table of terms for rule,
> condition, etc. I am aware of the terminology work that has been done in
> other documents, but think importing a few terms here would be helpful.
> 
> Page 10.
> 
>> Once the Policy Rules based configuration has been  sent
>> to  the Policy Target(s) the Policy Consumer will deter-
>> mine the success of the deployment and provide  feedback
>> to  the  Policy  Management  Application.   In  order to
>> determine the success, for this example, the Policy Con-
>> sumer  will query the device and examine the information
>> relating to the configuration of the Policy Target(s) to
>> determine if the configuration now matches what the Pol-
>> icy Consumer expects based on the Policy  Data.
> 
> This is one way of confirming correctness of the configuration operation
> which is quite reasonable. Another way would be via exception reporting or
> an ack. from the target. That is, an ack confirms correct reciept, i.e.,
> success. Error messages can be sent back with what when wrong.
> 
> Page 11.
> 
>> As  described  above, at the start or end of a time/date
>> period expressed in  a  condition  the  Policy  Consumer
>> would re-evaluate the Policy Rules for the Policy Target
>> and perform the necessary translations,  check  existing
>> configuration,  perform  any  necessary clean-up, deploy
>> the  corresponding  configuration,  and  report  status.
>> (Alternatively  the  Policy  Consumer could generate the
>> appropriate information for any given time period speci-
>> fied in the Policy Rules and simply download them at the
>> appropriate times rather than filter at each time bound-
>> ary.)
> 
> Also reasonable. Some policy consumers can send to the policy target the
> schedule for policy execution. Perhaps this is for a 'policy aware' device?
> The point is some devices under policy control will have scheduling
> capability locally and all the need is that the policy information contain
> this when deployed. This facility does not prevent the other type of
> distribution where the policy consumer reloads policy when needed.
> 
> Page 16.
> 
>> bilities.   A  well implemented Policy Consumer will detect
>> any problems with a Policy before deploying it on a  Target
>> (if  the  problem  wasn't detected in an automated way ear-
>> lier).  If a Policy Consumer does detect such a problem  it
>> will provide feedback to the Administrator through the Pol-
>> icy Management Repository.
> 
> I understand policy consumer to be management application. In this context I
> agree that such software should check before deploying a policy. In some
> cases only the managed element will know at the time the request is made if
> the policy will work or not - this should be the exception.
> 
> That said, the exception, that is to say the failed policy deployment should
> in my view be stored somewere - the repository is fine. The the event
> enunnciation is not via the repository it is via some enunciation software
> such as a gui, email, pager, etc.
> 
> Page 18.
> 
>> Scenario 1 allows for minimal change to the  Core  Informa-
>> tion  Model.  It would, however, cause Policies to be clut-
>> tered with Policy Rules (or condition lists  within  Policy
>> Rules) which only exist to handle contingencies.  Such con-
>> ditions which deal with state likely would not be evaluated
>> on  the  Policy  Targets  (using  existing  devices  as the
>> model), rather they would be evaluated on the  Policy  Con-
>> sumer.
>> 
>> An example of such a state condition could be:
>> 
>> condition type name: deviceDown
>> attributes: device address: 192.168.14.12
>> considered down if no contact after: 30
>> seconds
>> 
>> To enable such a  condition,  either  the  Policy  Consumer
>> would  need  to poll each of the devices named in each such
>> condition, or would need to be notified by some third party
>> monitoring  the condition of each device named in each pol-
>> icy condition.
>> 
>> 
> 
> I have a bit of a problem with this model in that it is too restrictive. I
> have no problem if people want to deploy policy in the fashion you describe
> here for failures and architectures should support this - but believe there
> is a better approach. Sure, the managed element should keep it's manager
> posted as to its status. This can be achieved via asynchronous or polling
> methods or a combination of both. In some cases, however; the managed
> element (policy target) should have the policy to apply in the case of a
> failure and is in the right place to do so rapidly. In SONET networks change
> over as a result of failure can take place fairly rapidly (that is the goal
> at least). These machines should have the policy to employ locally in the
> case of the failure due to time constraints, a polling based approach when
> rapid correction is desired would be problematic.  My other concern about
> the example is that it is on a device basis. While it is true that entire
> devices can fail, it is more true that parts fail or the network
> infrastructure that connects them has a failure. so the condition is not
> deviceDown, but interface down.
> 
> Page 19.
> 
>> Scenario  2  would require a change to the Core Information
>> Model.  On the association between a Policy and Policy Tar-
>> get, there would be conditional associations to other Poli-
>> cies.  In the association would be  conditions  similar  to
>> those  described  in  Scenario 1, which describe conditions
>> under which the Policies for unusual circumstances would be
>> deployed.   If  the current indirect model for distribution
>> is followed, all of the policies would  be  placed  in  the
>> directory  and  the Policy Consumer would obtain all of the
>> policies, then change which Policy is deployed to the  Pol-
>> icy  Target  on a status change as described in Scenario 1.
>> If a more direct model for Policy distribution  were  used,
>> then  the Policy Management Application could be enabled to
>> change Policy distribution based on state  not  related  to
>> traffic based conditions.
>> 
> 
> This is a bit closer to what I had in mind, except that it assumes that the
> policy management application is watching over everything and knows enough
> what to do in the case of a failure condition and then loads the correct
> policy to the devices it needs to. There is no problem in an architecture
> allowing for this type of approach but believe it to be insufficient in many
> circumstances. For this reason, a policy application may send to a managed
> device the policy to use when things are ok, and the policy to use (perhaps
> more than one) when there is a failure.
> 
> Page 21.
> 
>> 2.6.2.  Snooping Signaling Messages to Glean Classification
>> Information
> 
> There is no problem in principle with a management application collecting
> data from the network and using that for policy setting. My objection is
> that the example is RSVP specific and should be in this type of document, I
> think more broadly worded. For example, a management application could learn
> a lot from other types of instrumentation in the network about who is using
> the net, what type of traffic is being sent, etc. Both these examples have
> some interesting security implications though.
> 
> Page 22.
> 
>> 2.6.3.  Offering High Quality Guarantees
> 
> My comment about this section is that is why policy is most usefully
> expressed in terms of amount of traffic, capacity of a device and
> utilization. A device might be configured to deliver a maximum of X voice
> over IP sec. I like some of the examples but again find that they are too
> restrictive. A policy manager can send information to devices under some
> circumstances. In other cases the policy should contain what to do if a
> resource is exceeded, or alternatively a second policy would be triggered in
> the event of 'oversubscription'. This is not to say that the centralized
> policy manager would not have a function in this area since it may monitor
> for aggregate usage and cause policies to changes based on state or usage
> information from many places in the network.
> 
> Page 33.
> 
>> 3.  Security Considerations
> 
> My problem is not with what is there, but what is missing. Either the list
> should be complete or a pointer to other documents provided.  I believe that
> user authentication is important for example.
> 
> /jon
>