Subject: [OPSAWG] draft-harrington-operations-and-management

From: Ron Bonica <[email-masked]>
Date: Thu, 21 Jun 2007 17:15:50 -0400

Folks,

The following are a few comments on
draft-harrington-operations-and-management. As this is a version-00
draft, the comments are somewhat general.

- This document seems to be just as concerned with the protocol
designer's "mind-set" and the protocol development process as it is with
the protocol as a finished product. While we all agree that it would be
a good thing to imprint operational sensitivities into the consciousness
of the protocol developer, I do not think that this is a practical goal.
The best that we can do is to set forth a list of objective criteria by
which a protocol designer can evaluate whether the protocol that he/she
has developed is manageable.

- Objective criteria might take the form of a checklist. Questions would
be of the following nature:

. are configuration parameters clearly identified?
. are configuration parameters normalized?
. does each configuration parameter have a reasonable default value?
. is protocol state information exposed to the user? How?
. is protocol performance information exposed to the user? How?
. are significant state transitions logged?
. etc etc etc

- Finally, the document may attempt to cover too much ground. Maybe it
will develop into a framework document, supported by documents of the
following sort:

. what makes a MIB usable?
. how much protocol state information needs to be exposed and how?
. how much performance information needs to be exposed and how?

                                    Ron
                                  /speaking as individual contributor

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsawg

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 24 Jun 2007 18:03:34 +0200

See in-line. 

Dan
(speaking as a contributor)

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]] 
> Sent: Friday, June 22, 2007 12:16 AM
> To: [email-masked]; [email-masked]
> Subject: [OPSAWG] draft-harrington-operations-and-management
> 
> Folks,
> 
> draft-harrington-operations-and-management. As this is a 
> version-00 draft, the comments are somewhat general.
> 
> - This document seems to be just as concerned with the 
> protocol designer's "mind-set" and the protocol development 
> process as it is with the protocol as a finished product. 
> While we all agree that it would be a good thing to imprint 
> operational sensitivities into the consciousness of the 
> protocol developer, I do not think that this is a practical goal.
> The best that we can do is to set forth a list of objective 
> criteria by which a protocol designer can evaluate whether 
> the protocol that he/she has developed is manageable.

Agreed, but this is also about documenting the minimal information about
manageability that a protocol document published by the IETF should
contain. 

> 
> - Objective criteria might take the form of a checklist. 

Yes. This checklist would have two categories of users. Writers of
protocol documents and reviewers of protocol documents. Both categories
of contributors will have a common set of criteria for the information
to be included and looked in a protocol document. 

> Questions would be of the following nature:
> 

What do you mean by normalized?

> - Finally, the document may attempt to cover too much ground. 

Do you have specific proposals about sections or items that should be
taken out? 

> Maybe it will develop into a framework document, supported by 
> documents of the following sort:
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 Jun 2007 10:23:48 -0400

> What do you mean by normalized?

I borrowed the term from database technology. For details see
http://en.wikipedia.org/wiki/Database_normalization .

> Do you have specific proposals about sections or items that should be

Not so much taken out as split into separate documents. For example, we
might be able to write a document on syslog requirements for a new
protocol. That document might talk about logging levels, what should be
logged, what should not, and how to deal with log chattiness.

The base document might provide a pretty good framework for all of those
more specific documents.

                                  Ron