Subject: [OPS-AREA] Comments on draft-ietf-opsawg-operations-and-management-04

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Jul 2008 18:50:33 +0200

Please find below my contributor comments on
draft-ietf-opsawg-operations-and-management-04. The comments are rather
in the text order than in importance. I tried to address also some of
the issues market for DISCUSS. 

1. Abstract - something is missing in the second phrase, maybe the word
'about' before 'covering aspects ...'

2. I would move to the introduction section some of the text in Section
5 or a clone of it. I believe it tells better about what this document
intents to be: 

  The purpose of this document is to provide guidance about what to
   consider when thinking about the management and deployment of a new
   protocol, and to provide guidance about documenting the
   considerations.  The following guidelines are designed to help
   writers provide a reasonably consistent format for such
   documentation.  Separate manageability and operational considerations
   sections are desirable in many cases, but their structure and
   location is a decision that can be made from case to case.

   We want to avoid seeming to impose a solution by putting in place a
   strict terminology - for example implying that a formal data model,
   or even using a management protocol is mandatory.  If protocol
   designers conclude that its technology can be managed solely by using
   proprietary CLIs, and no structured or standardized data model needs
   to be in place, this might be fine, but it is a decision that should
   be explicit in a manageability discussion, that this is how the
   protocol will need to be operated and managed.  Protocol designers
   should avoid having manageability pushed for a later/never phase of
   the development of the standard.

   Making a Management Considerations section a mandatory publication
   requirement for IETF documents is the responsibility of the IESG, or
   specific area directors, or working groups, and this document avoids
   recommending any mandatory publication requirements.  For a complex
   protocol, a completely separate draft on operations and management
   might be appropriate, or even a completely separate WG effort.

3. I would drop some of the existing text in the current introduction,
especially: 

   This document only provides guidelines; it does not specify how the
   guidelines provided should be used within the IETF.

4. Need to expand acronyms, even those who are very obvious in the
management community but may be obscure out of it like SMI or COPS-PR. 

5. the DISCUSS at page 6 - I would avoid giving more examples, lists of
protocols, etc. 

6. page 6 - I did not understand what is the intent of the paragraph
that mentions IPFIX

7. page 7 - [DISCUSS: would the
   example of inconsistency between MIB counters that cannot be reset
   and CLI counters that can be rest be useful here?] - yes, I think so

8. Section 3.3 - the second paragraph does not seem to deal with
protocols extensibility, but more to data models  and data model
languages design. I think that the protocol designers cannot do much
about this, and I would recommend to take this out. 

9. Section 3.4 - The example is from a functional component and not from
a protocol. I would emphasize the role of impact on functional elements
by saying s/document the requirements from other protocols/document the
requirements from other protocols and functional elements/ in the first
paragraph

10. page 9 - I believe that the content of the last paragraph in this
page is out of scope

11. Section 3.6 - we can add considering simple protocol status and
health indicators on network devices as a recommended mean to check
correct operation

12. Section 4 - We need some lose definition of what we mean by a
'service' (on the lines of network and operational functionality derived
from the implementation and deployment of a new protocol - or something
similar) 

13. page 11 - [DISCUSS: Is a section on P2P vs. central management
called for
   here?] - No, IMO

14, section 4.1 - when speaking about interoperability we should add the
management applications , emphasizing that interoperability allows for
usage or 3rd party applications and outsourcing of management services.

15. section 4.3 should start IMO with the need to document what are the
basic faults and health indicators that need to be instrumented for a
new protocol, as well as what alarms and events must be propagated to
management applications or exposed through a data model

16. page 14 - DISCUSS-what is reliable? The accurate delivery of the
event information is guaranteed within a given (high) margin of
confidence

17. 4.3.2 - the DISCUSSes go into too much details IMO 

18. 4.3.4 - same, I would consider taking out these section, they are
beyond protocol design and what is expected in protocol documents

19. Section 4.4 should start IMO with the need to document what are the
basic configuration parameters that need to be instrumented for a new
protocol, as well as default values and modes of operation

20. All the discussion in section 4.4 about backup configuration, gold
config, etc. seems to me to be out of scope - it is device centric and
is not covered in new protocol documents

21. Same with 4.4.1 - seems out of scope or mis-placed

22. page 19 -    What information should be maintained across reboots of
the device,  or restarts of the management system? - this is important
but mis-placed, should be in the configuration management section

23. DISCUSS: there are several parts to performance management.  Device
   monitoring (with the impact of the new protocol/service activation),
   protocol monitoring, and services monitoring.  This section might
   benefit from being broken into different pieces.] - 

   YES - maybe not breaking the section but mentioning the three
categories separately

24. The security management section may add a paragraph about security
threats that may be introduced by management operations. For example
CAPWAP breaks the structure of monolithic Access Points (AP) into Access
Controllers and Wireless Termination Points (WTP). By using a management
interface internal information that was previously not accessible is now
exposed over the network and to managers and my become a source of
potential security threats. 

25. I doubt that section A.1 is needed. In general I prefer that expert
reviews focus on expert information, while general reviews are left for
GenART

26. A2, first paragraph - add the question whether textual or graphical
UI are required, whether binary or text representation of management
information is preferred. 

27. add to A2 the question 'what is the minimal set of management
(configuration, faults, performance monitoring) objects that need to be
instrumented in order to manage the new protocol 

Thanks and Regards,

Dan

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ops-area

---

From: "David Harrington" <[email-masked]>
Date: Tue, 22 Jul 2008 13:32:15 -0400

Thanks Dan,

I will incorporate these comments into the next revision.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Tuesday, July 22, 2008 12:51 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OPSAWG] Comments on 
> draft-ietf-opsawg-operations-and-management-04
> 
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>