[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf FW: request for feedback: Policy requirements drafts
Below are comments I sent to the Policy list on the usage scenarios.
> From: Jon Saperia <email@example.com>
> Date: Mon, 26 Jun 2000 10:29:03 -0400
> To: Hugh Mahon <firstname.lastname@example.org>, <email@example.com>, Jon
> Saperia <firstname.lastname@example.org>
> Subject: Re: request for feedback: Policy requirements drafts
> on 06/19/2000 3:43 PM, Hugh Mahon at email@example.com wrote:
> Hugh some comments about:
> 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-
> 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-
>> 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
>> 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
> 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.