[OPS-NM] Some comments on http://www.ietf.org/internet-drafts/draft-harrington-operations-and-management-00.txt

["Romascanu, Dan \(Dan\)" <[e-mail]>]

I would suggest to as many folks as possible to red and provide comments
on
http://www.ietf.org/internet-drafts/draft-harrington-operations-and-mana
gement-00.txt prior to the meeting in Prague. This is an important
document for the OPS area, that could impact the work in other area of
the IETF in the future. 

Here are a few of my observations: 

1. Section 1

o  "new protocol" includes new protocols, protocol extensions, data
      models, or other functionality being designed.

I would include in this definition also 'the entities and functional
components implementing the protocol'

2. Section 2 - I believe that instead of 'Protocol designers typically
do not like to look at the management aspects of their new protocol.' we
should rather say 'Protocol designers typically do not take into
considerations the operational and management aspects of their new
protocol at the time of the protocol definition'

3. Section 2 - s/aspects of a protocol design that is unfamiliar to
them/aspects of a protocol design that are unfamiliar to them

4. Section 2 -   'This document is not about requiring all
internet-drafts to include a new "Operations and Management
Considerations" section.' I would add '... although it does not preclude
the addition of such a section either'. 

5. Section 2.1 

The IETF has indicated a desire to have operations and manageability
   considered during the development of new protocols, using a proactive
   "design for operability and manageability" approach that documents
   how a new protocol is expected to be operated and managed.

I do not believe that there was any IETF-wide discussion on this issue.
Did you mean the IESG? 

6. It would help if the last paragraph in 2.1 would be edited as a list
of bullets. 

7. Section 3.4 - 

  These considerations should generally remain illustrative to avoid
   creating restrictions or dependencies, or potentially impacting the
   behavior of existing protocols, or restricting the extensibility of
   other protocols, or assuming other protocols will not be extended in
   certain ways.

I am not sure what 'considerations should remain generally illustrative'
- maybe what we mean here is that the goal of such considerations would
be to identify existing restrictions and dependencies, but avoid
introducing new ones. 

8. Section 4

Some product designers and protocol designers assume that if a device
   can be managed individually using a command line interface or a web
   page interface, that such a solution is enough.  But when equipment
   from multiple vendors is combined into a large network, scalability
   of management becomes a problem.  It is important to have consistency
   in the management interfaces so network-wide operational processes
   can be automated.

I think that we should add to the last phrase '... and to minimize to
the possible extent the number of components of a complete management
solution' 

9. Figure 1 should mention data models at plural and represent them
under different names DM1, DM2 ...

10. The discussion of the data models should also take into
consideration the issues related to the implementability of data model
in network devices - we can use the example of the multiport bridges
with thousands of VLANs modeled as entries of tables per port - is such
a model implementable? 

11. I believe that we should add to 4.2.3 Fault Determination the case
where faults are determined by comparing increases of counters in a
given time interval vs. a threshold, as in the RMON Alarms mechanism

12. Section 4.3 -  The phrase ' Network wide configurations are ideally
stored in central master databases ...' seems to recommend a certain
management model or architecture, which may not be appropriate for all
cases. I do not believe that there is any 'ideal' here and I would
reformulate

13. It is not clear to me what 4.3.2 is meant to say - I believe that
there is a need for more clarity in this section.

14. Section 4.5 should state that for a given protocol the metrics that
characterize the performance of the protocol need to be defined as part
of the manageability considerations information. 

15. I think that it would be good to mention that the content in Section
5 is of informational nature, and reflects the status of the management
protocols at the time of the editing of this document 

16. Should we not include also COPS in Section 5? We refer only to
COPS-PR. CLI also deserves a separate sub-section, even if not standard
it is widely used. I would also mention CAPWAP and ANCP as 'other
protocols'

17. Section 6.4 should also mention IPPM and RTCP XR (RFC 3611) 


Dan





 


_______________________________________________
OPS-NM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ops-nm