Subject: Comments on Netconf Monitoring

From: Balazs Lengyel <[email-masked]>
Date: Mon, 10 Dec 2007 15:29:09 +0100

Hello Mark,

General)
Netconf related performance counters are needed. Eg.g.
- number of sessions
- number of current sessions
- number of messages, per operation type
- number of faults (authentication, XML, etc.)

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.

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.

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.
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: [email-masked]
module netconf-state {

    namespace "urn:ietf:params:xml:ns:netconf:state:1.0";
    prefix "ns";

    import yang-types { prefix yang; }
    import inet-types { prefix inet; }

    organization
        "IETF";

    description
        "NetConf Monitoring Schema.
         All elements in this Schema are read-only.";

    revision "2007-11-12" {
        description
	    "Updated to match draft-scott-netconf-monitoring-00.txt";
    }
    revision "2007-07-22" {
        description "Initial revision.";
    }

    typedef SessionId {
        type uint32 {
            range "1..4294967295";
        }
        reference "rfc4741";
    }

    typedef ConfigName {
        type enumeration {
            enum "running";
            enum "candidate";
            enum "startup";
        }
        reference "rfc4741";
    }

    typedef transportType {
        type enumeration {
	    enum "console";
	    enum "tcp";
	    enum "ssh";
	    enum "ssl";
	}
    }

    typedef sessionType {
        type enumeration {
	    enum "cli";
	    enum "netconf";
	    enum "webui";
	}
    }

    grouping srcIdentifier {
        description 
	    "Information about source of the session.";
        leaf ipAddressTypev4 {
	    type inet:ipv4-address;
	}
      leaf nodeName {
	  type string;
	  description "Name of the node.";
      }
    }

    container netconfState {
        config false;

        container capabilities {
            description 
                "List of NETCONF capabilities supported
                 by this device.";
            leaf-list capability {
	      type yang:uri;
	      min-elements 1;
	    }
        }

        container sessions {
            description
                "List of NETCONF sessions currently
                 active on this device.";
            list session {
                key sessionId;
                leaf sessionId { type SessionId; }
  	        leaf transport { type transportType; }
                leaf username  { type string; }
	        container sourceIdentifier { uses srcIdentifier; }
                leaf loginTime { type yang:date-and-time; }
            }
        }

        container configurations {
            description
                "List of NETCONF configuration datastores (e.g. running,
                 startup, candidate) supported on this device and related
                 information.";
            list config {
                key name;
                leaf name { type ConfigName; }
                container lockStatus {
                    description
                        "An indication of whether a resource is locked or
                         unlocked.  If locked, additional information about
                         the locking such as user an time stamp is provided.";
                    leaf lock-state {
                        type enumeration {
                            enum "locked";
                            enum "unlocked";
                        }
                    }
                    leaf lockedBySession {
                        type SessionId;
                        description 
                            "The session ID of the session that has locked
                             this resource.";
                    }
                    leaf lockedTime {
                        type yang:date-and-time;
                        description
                            "The date and time of when the resource was
                             locked. If the resource is currently unlocked,
                             this element will not be present.";
                    }
                }
            }

            container subscriptions {
                description
                    "List of NETCONF notification subscriptions
                     active on this device and related information.";
                list subscription {
                    key session-id;
                    description
                        "Information about Netconf Notification Subscriptions.";
                    leaf session-id {
                        type SessionId;
                        description
                            "The session id associated with this subscription.";
                    }
                    leaf stream {
                        type string;
                        description
                            "The stream associated with this subscription.";
                    }
                    leaf filter {
                        type anyxml;
                        description 
                            "The filters associated with this subscription.";
                    }
                    leaf messagesSent {
                        type yang:zero-based-counter32;
                        description
                            "A count of event notifications sent along
                             this connection since the subscription was
                             created.";
                    }
                }
            }
        }
    }
}

---

From: Mehmet Ersue <[email-masked]>
Date: Wed, 12 Dec 2007 18:38:20 +0000 (GMT)

Hi Balazs,

good comments, see below.

Cheers, 
Mehmet 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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" ]

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.2)
[Mehmet:
Agree fully.]

Partial locking shall be included in the schema.
[Mehmet:
What about "running transactions"? ]

Remove namedProfile

regards Balazs

       __________________________________ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever