Subject: [OPSAWG] Some comments on draft-ietf-opsawg-operations-and-management-00

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 13 Nov 2007 15:35:49 +0100

Here are a few comments about
draft-ietf-opsawg-operations-and-management-00. They are 'high-level'
meaning that I am dealing more with the structure of the document and
giving my take on a some of the open questions. All are contributor
opinions. I am leaving nits and smaller editorial comments for a later
phase.

1. >  [DISCUSS - 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.]

I would add here that a target audience is also the group of reviewers
that evaluate the protocol in phases of approval

2. >    [DISCUSS: - 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?]

I am concerned about too much fragmentation. Let us agree that this is
the framework document plus guidelines information, and we can debate
how much needs to make it in the framework. Out of the example you give
the first two do not seem to belong here, but the third does. 

3. The last paragraph of section 2.1 dealing with the need of an
operational model and analysis is very important but does not seem to
belong here. I think that it should be moved into 3.1 and that it should
be re-written in bullets format to make the list of issues to look at as
part of an operational model clear.  

4. Section 3.5 seems to limit the impact on network operation only to
network traffic or devices. I believe that it should consider also
impact on applications and registries, for example DNS entries, or size
of routing tables. 

5. Section 4.3 should start with a short discussion about the need to
provide information in documents about how faults information is being
propagated (asynchronous notifications, polling of health indicators,
hierarchy of faults)

6. Section 4.3.4 needs clarification and more details. 

7. I believe that some of the issues raised in 4.6 go to a level of
detail beyond the other classes of management  operations and should be
left for appropriate data models or protocol design documents. Unless
there are some generic recommendations issues like maximal values of
counters, behavior at rollout, persistency and discontinuities should be
out of scope. I would rather expect from a protocol document to identify
what are the principal performance factors that need to be looked at
when measuring the efficiency of the protocol implementations. 

8.  I agree to a large extent to Juergen's DISCUSS. It may be better to
shorten this section, provide a crisp recommendation to look at the
existing standard track MIB modules, and move the rest of the section in
an Annex. 

9. It may be useful to include in Section 7.1 a bulleted list of the
issues that may be included in the Manageability and Operations sections
of IETF documents with the observation that this list is provided for
guidance and document authors may pick what is relevant for their
document. 

Thanks and Regards,

Dan

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 13 Nov 2007 16:48:15 -0500

discussions inline.

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Tuesday, November 13, 2007 9:36 AM
> To: [email-masked]
> Subject: [OPSAWG] Some comments 
> ondraft-ietf-opsawg-operations-and-management-00
> 

done.

> the first two do not seem to belong here, but the third does. 

This DISCUSS text captured somebody else's wording; that was not my
example. I would like to see a succinct set of guidelines. I think
fragmentation would hurt the utility of such guidelines. I can see
separating the survey of existing protocols and data models from the
guidelines to keep the size down, and to distinguish the purpose of
the "considerations" from the "survey of existing".

(Boy, am I the wrong editor for succinct ;-) Suggestions highly
welcome for how to make the guidelines and discussions more succinct.

> part of an operational model clear.  

done.

> impact on applications and registries, for example DNS 

I added your comment about what should be considered. Additional text
and detail welcome.

> propagated (asynchronous notifications, polling of health
indicators,

Done. I understand the distinction between notifications and polling.
However, I am not sure what you had in mind with the hierarchy of
faults. I wrote some text, but it may not be what you had in mind.

> 6. Section 4.3.4 needs clarification and more details. 

I beleve this text was submitted by somebody without details. I am
open to proposed text to expand this section. Alternately, I am open
to eliminating this section.

> when measuring the efficiency of the protocol implementations. 

I eliminated some text and expanded other text. I do think that
discussing persistence of the information (not necessarily just
counters) is something the protocol designers should consider if it is
relevant to the managed protocol. I think this is part of the
information model, not just the data model.

> existing standard track MIB modules, and move the rest of the 

The Juergen discuss you reference I assume is the one in section 6:
[DISCUSS: JS: The weakest part of the document is IMHO section 6. It
is not clear to me what David's intention were here; sometimes he
gives general advise while at other places he kind of surveys data
models and such things. I am also not sure all the stuff listed there
is actually useful to list; for example, has anybody ever deployed the
technology which came out of the snmpconf working group? So we need to
be more selective and probably also organize our pointers based on the
protocol layer people are working on (transmission specific MIB
modules are kind of widely used, people managing application servers
usually do not use much of SNMP; the IETF application management MIBs
we have produced have not gained large deployments as far as I can
tell). ]

Juergen commented in Section 5: "what I really like, the text
discusses for which applications they were designed or already
successfully deployed. I like to perhaps see even stronger
guidelines;"

My intention in Section 6 is similar. I think we should identify which
data models exist already, what they were designed for, and whether
they have been implemented and deployed. I said in section 6 that
Section 6 should only include data models that have reached Draft
Standard or better, and Proposed Standard should be listed in an
appendix. Some of the data models in Section 6 are only PS, and need
to be moved. Unfortunately, we stopped advancing MIB modules through
the standards-track, so the DS vs. PS is no longer a valid indicator
of implementation and deployment.

I think it is very important to identify which data models we
recommend and which we do not, and if not, then why they are not
recommended. 

I tried sorting by FCAPS to reflect their purpose; JS suggests sorting
by layer.
I tried sorting by layer when creating recommendations for Enterasys,
and not all MIB modules are layer-specific, just as all MIB modules
are not purpose-specific either. I am certainly willing to try to sort
by layer.

You suggest a crisp recommendation to look at standards-track data
models. I think that is way inadequate. 

We offer a tremendous number of MIB modules, most of which are at PS,
and we have no further recommendations about which are widely
implemented and deployed, which are not recommended, and which are
simply too new to know if they are useful. The many MIB modues we
offer model many different things, and even "experts" in SNMP don't
know what is in every MIB module without research. If somebody that is
not a management expert wants to know if there is a MIB module that
provides the ability to monitor or control some feature such as
memory, they cannot search for "MIB memory" in the RFC search engine
and find the HOST-RESOURCES-MIB. If they do manage to find it through
other means, they cannot tell whether this is a good MIB to use to
model the types of memory they are considering (such as blade-specific
memory in a router chassis).

I think we should provide some real **guidance** about which existing
data models cover which features, and whether the data model is
recommended.

> guidance and document authors may pick what is relevant for their

I don't understand the edits. What bullets did you have in mind?
The appendix is intended to contain a checklist. Would that be the
same as your bulleted list?
I think the observation that authors may pick what they consider
relevant should be an observation of the IESG or of an agreed-to
review requirements document, not this document. This document gives
guidelines for what to consdier, and I think every aspect should be
considered, even if they choose not to include discussion of every
aspect.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 Nov 2007 13:50:50 +0100

In-line. 

A lot of good and agreed text was deleted. 

Dan

> From: David Harrington [mailto:[email-masked]] 
> This DISCUSS text captured somebody else's wording; that was 
> not my example. I would like to see a succinct set of 
> guidelines. I think fragmentation would hurt the utility of 
> such guidelines. I can see separating the survey of existing 
> protocols and data models from the guidelines to keep the 
> size down, and to distinguish the purpose of the 
> "considerations" from the "survey of existing".
> 
> (Boy, am I the wrong editor for succinct ;-) Suggestions 
> highly welcome for how to make the guidelines and discussions 
> more succinct.

One possible suggestion was made already I believe - keep the core of
the recommendations in the body of the RFC and move the survey of
existing protocols and data models to Annexes. This has the advantage of
keeping all in one document. 

> I added your comment about what should be considered. Additional text

The impact on performance may also be noted - increased delay or jitter
in real-time traffic applications, or response time in client-server
applications when encryption or filtering are applied. 

I am sure there are other examples which operators may point to. 

> faults. I wrote some text, but it may not be what you had in mind.

I need to see that text :-) What I had in mind is fault propagation and
aggregated status indicators based on concatenation of propagated faults
from a given domain or device. 

> to eliminating this section.

I would not mind eliminating rather than leaving in something which is
not clear enough. 

> data models cover which features, and whether the data model is

I was probably not clear enough, my 'crisp' recommendation was not for
all MIB documents that happened to reach standards track but for a
selected handful of useful ones. We are probably in agreement. 

> same as your bulleted list?

Yes, I missed the appendix. It's good as it is.