[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[OPS-AREA] Comments on draft-ietf-opsawg-operations-and-management-04
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
OPS-AREA at ietf.org
https://www.ietf.org/mailman/listinfo/ops-area