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

From: [email-masked] (Scott O. Bradner)
Date: Sun, 25 Jan 2009 11:40:13 -0500 (EST)

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Jan 2009 09:37:43 +0100

On Sun, Jan 25, 2009 at 11:40:13AM -0500, Scott O. Bradner wrote:
 
> 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

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.)

- At times, the document reads like a collection of text fragments
  taken from other documents without a very clear story line. I
  sometimes had the feeling that things were not developing in a
  "natural way" (but it is difficult for me to say what such a
  "natural way" would look like without going through the whole
  exercise to dissect the document into its fragments and reassembling
  the puzzle again).

- 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. 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.

- 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).

Some editorial nits:

- Define the acronym CLI the first time it is used.

- Is "later/never phase" a typo or there by intention?

- I am not sure this sentence is correct:

    This document sets forth a list of subjective guidelines and a list
    of objective criteria by which a protocol designer can evaluate
    whether the protocol that he/she has developed addresses common
     operations and management needs. 

  I am actually not sure whether the distinction between "subjective
  guidelines" and "objective criteria" is worth to have. What I
  believe is valuable is the checklist phrased as a collection of
  questions to consider.
  
- The first paragraph in 2.1 should in my opinion cite RFC 3410. But
  as mentioned above, I am not a big fan of this discussion at all.

- s/algoithms/algorithms

- Some text on top of page 8 that looks scratch pad text.

- s/should there be/Should there be

- s/gyaranteed/guaranteed

- garbaled sentence

     or can the right
     counters that can be polled as needed?

- s/desoigners/designer

- s/For example, Sometimes/For example, sometimes

- s/should they stop counting/Should they stop counting

- A.1: Make it clear that scalability in terms of operations and
  management is meant, not in terms of the primary protocol functions.

  OLD

  Does the solution scale well?

  NEW

  Does the solution scale well from the operational and management
  perspective?

- A.1: Capitalize the sentences with the questions consistently.

- A.1: Add the following:

    Are there any coexistance issues?

- A.1: Add some more detailed questions for the items refering to 3.5,
       3.6 and 4.1.

- Appendix A tries to make a distinction between Operational
  Considerations and Management Considerations and I am not sure this
  is a clear cut line. Earlier, the document talks about a single
  "Manageability Considerations" section. See also my more general
  comments above.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 27 Jan 2009 10:13:37 +0100

Scott & Ted,

This is in my opinion one of the most important documents currently in
works in the OPSAWG and in the whole area. I would recommend that as
many people as possible review and comment it. 

Clarification question - what is date for the WGLC to expire?  

Thanks and Regards,

Dan

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

---

From: [email-masked] (Scott O. Bradner)
Date: Tue, 27 Jan 2009 07:49:45 -0500 (EST)

> Clarification question - what is date for the WGLC to expire? =20

good question :-)

feb 9

Scott & Ted