[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OPS-AREA] [OPSAWG] Comments on draft-ietf-opsawg-operations-and-management-04
Thanks Dan,
I will incorporate these comments into the next revision.
dbh
> -----Original Message-----
> From: opsawg-bounces at ietf.org
> [mailto:opsawg-bounces at ietf.org] On Behalf Of Romascanu, Dan (Dan)
> Sent: Tuesday, July 22, 2008 12:51 PM
> To: opsawg at ietf.org
> Cc: ops-area at ietf.org
> Subject: [OPSAWG] 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
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG at ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
_______________________________________________
OPS-AREA mailing list
OPS-AREA at ietf.org
https://www.ietf.org/mailman/listinfo/ops-area