Hi Balazs,
good comments, see below.
Cheers,
Mehmet
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of ext Balazs Lengyel
Sent: Monday, December 10, 2007 3:29 PM
To: Netconf (E-mail)
Subject: Comments on Netconf Monitoring
Hello Mark,
General)
Netconf related performance counters are needed. Eg.g.
- number of sessions
- number of current sessions
[Mehmet:
You differentiate here between 'sessions' and 'current sessions'. I assume you mean with 'number of sessions' a historic count of sessions. This has been precluded in the current document. The general questions
is whether we need historical information as monitoring data, at least one step back, e.g. "last faulty session" or "last session duration" would make sense.
Please add also "operations started per session".
- number of messages, per operation type
- number of faults (authentication, XML, etc.)
[Mehmet:
If historical data is relevant following data would be interesting:
"last fault"
"last session duration"
"maximum session duration"
"maximum # of parallel sessions per configuration store" ]
The data model is described in XML schema which is just one possibility. At the momwent it is
missing real references for session and stream. I think a Yang model shall be added at least as
a non-normative appendix (see attachment). Anyway we should clarify the content of the data
model now, and hopefully by the next IETF we will know more about the modeling methodology.
Chapter 1)
Do we need this? I propose to remove it.
[Mehmet:
I think we need an introduction, but the information here is mainly available in base documents.]
Ch 1.1) Remove the last sentence for operation.
Ch.1.2)
Netconf state should not be the root level element, rather we
should have something like
netconf/netconfState.
[Mehmet:
Agree fully.]
It is possible to have zero sessions in the datastore. However when we read it out we will
always have the reading session. Still I would rather see minOccurs=0
How do we represent CLI/GUI/etc. sessions? If we are speaking about locking the session can be
an internal process like backup or restart.
What is a sourceIdentifier? Some description is needed. Or should we just call it
sessionSourceAddress which does not need an explanation?
Partial locking shall be included in the schema.
[Mehmet:
What about "running transactions"? ]
The sessionId
must be always present for the lock. A real reference (keyRef) to the session
object would be even better.
stream should have a type of ncEvent:streamNameType. A real reference to the stream in the
Notification Management Schema would be even better. (keyRef)
Remove namedProfile
The transportType enumeration is not complete, and not prepared for future new transports. It
should be extensible. Beep and SOAP missing. Console should be CLI via telnet or SSH. Add none
for internal processes.
SessionType: Change webui to GUI, add internal
srcIdentifier: rename to srcAddress. IPv6 and none for internal sessions should be included.
regards Balazs
--
Balazs Lengyel Ericsson Hungary Ltd.
TSP System Manager
ECN: 831
7320 Fax: +36 1 4377792
Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com