Subject: Re: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 2 Feb 2009 18:03:13 +0100

I had reviewed earlier versions of this document a few times.
Last time was in 2007 (possibly early 2008).

I believe the document has improved A LOT since those revuiews.
Thanks for the effort that must have gone into that.

I still wonder if the document is not too long. That may deter potential
new readers. At the other hand, I also would not be able to tell you what 
to remove or how to organize. I sympathize a lot with the comments that
Juergen Schoenwaelder made (a week ago or so).

At the other hand... maybe we should just go ahead and publish and see
if the intended users will find this helpful or not. 

Bert
  ----- Original Message ----- 
  From: Scott O. Bradner 
  To: [email-masked] 
  Sent: Sunday, January 25, 2009 5:40 PM
  Subject: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management

  This is a (hopefully final) WGLC for draft-ietf-opsawg-operations-and-management

  there was not enough respose to the last one back in October

  please let the list know what you think of the draft

  thanks

  Scott & Ted

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

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 4 Feb 2009 20:09:45 -0800 (PST)

Dan R. asked me to provide comments.  I am not able to do a detailed 
review of the document, but based on a quick reading I have to say 
that I am in general agreement with Juergen Schoenwaelder's 
high-level comments.

On Tue, 27 Jan 2009, Juergen Schoenwaelder wrote:
> My review of draft-ietf-opsawg-operations-and-management-05.txt:
> 
> I find this a difficult document to review and I like to state clearly
> upfront that I very much appreciate the efforts spend on putting this
> document together. The reason for starting with this diclaimer is that
> I find it difficult to provide constructive comments in the form of
> concrete suggestions for changes. While reading, I observed the
> following:
> 
> - The document makes a distinction between "Operational
>   Considerations" (section 3) and "Management Considerations" (section
>   4) and I am not sure where the difference really is. I appears that
>   section 4 is much more management technology oriented and organized
>   following the FCAPS model but in general, I do not really see why
>   some issues are operational considerations and others management
>   considerations. Perhaps the document can be streamlined by merging
>   these two sections together. (For example, 3.6 and 4.3.1 do in my
>   view pretty much belong together.)

+1

> - I am not sure the discussion what the "IETF Management Framework"
>   means (historically and today) is that useful for designers of new
>   protocols and it might raise controversial discussions.

+1

One specific example of "might raised controversial discussions"::

   For years the IETF has stressed the use of the IETF Standard 
   Management Framework and MIB modules [RFC2578] for managing new 
   protocols.  The IETF designed these to permit multiple protocols 
   to utilize the MIB data [RFC1052], but it became a common 
   misunderstanding that a MIB module could only be used with the 
   SNMP protocol (described in [RFC3410] and associated documents).

With what other protocols have MIB modules ever been used???

>   Why not replace this material with a section that provide a 
>   high-level summary of the management technologies that can be 
>   considered by protocol designers? In terms of structure, this 
>   could mean that the document should have this structure (in 
>   terms of top-level sections):
> 
>   1. Introduction
>   2. Available Management Technologies
>      (briefly mention SNMP, SYSLOG, RADIUS/DIAMETER, NETCONF, IPFIX,
>      CLIs, GUIs, ...  and outline where they are particularly strong
>      and where not; this should be short and not a long elaboration)
>   3. Operational and Management Considerations
>   4. Documentation Guidelines
>   .. ...
> 
>   This would lift some of the text currently in section 4 into section
>   2. I also killed the current section 2 since the core of this is
>   already discussed in the introduction. As an alterntative, one could
>   keep a section "Design for Operations and Management" but then some
>   of the discussion currently in the introduction should be moved.

+1

> - The "Terminology" section explains why RFC 2119 language is not used
>   and then defines the terms "new protocol" and "protocol designers".
>   The document later has quite some text related to terminology (e.g.
>   the discussion of information model vs. data model). One option to
>   consider is to move all text discussing or clarifying terminology
>   into this "Terminology" section (including the text fragments
>   pointing to RFC 3198 and RFC 3444).

+1

//cmh