Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt

From: [email-masked]
Date: Mon, 9 Mar 2009 16:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title           : NETCONF Monitoring Schema
	Author(s)       : M. Scott, et al.
	Filename        : draft-ietf-netconf-monitoring-04.txt
	Pages           : 46
	Date            : 2009-03-09

This document defines a NETCONF data model (in XML Schema) to be used
to monitor the NETCONF protocol.  The monitoring data model includes
information about NETCONF datastores, sessions, locks, subscriptions,
and statistics.  This data facilitates the management of a NETCONF
server.  This document also defines methods for NETCONF clients to
discover data models supported by a NETCONF server and defines a new
NETCONF <get-schema> operation to retrieve them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Mark Scott" <[email-masked]>
Date: Fri, 13 Mar 2009 16:44:43 -0400

Hello,

The updated draft below addresses the comments received in the WGLC of
draft-ietf-netconf-monitoring-03.

I have attached a document containing the responses to all comments
indicating:
- updated in v04 where applicable
- open item to be discussed at IETF74
- item to be followed up on the mailing list

If any comments on v03 were (unintentionally) missed please raise them
to my attention again.

They will be addressed in v05 along with others comments received on v04
(incl. those already raised by Andy - thanks!).

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, March 09, 2009 7:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network Configuration Working Group of
the IETF.

This document defines a NETCONF data model (in XML Schema) to be used to
monitor the NETCONF protocol.  The monitoring data model includes
information about NETCONF datastores, sessions, locks, subscriptions,
and statistics.  This data facilitates the management of a NETCONF
server.  This document also defines methods for NETCONF clients to
discover data models supported by a NETCONF server and defines a new
NETCONF <get-schema> operation to retrieve them.

---

From: WashamFan <[email-masked]>
Date: Sat, 14 Mar 2009 08:40:52 +0800

Hi,

It seems this thread has been ignored
http://www.ietf.org/mail-archive/web/netconf/current/msg04272.html

PS: Mark, please update my address to [email-masked]

washam

> to
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 16 Mar 2009 11:17:20 +0100

Hello Mark,
Some comments to your file.
Balazs

18) It should be mentioned that for non-netconf lock the session id contains ...
Do it for both global and partial locks and for YANG too

[Question]  Are non-NETCONF locks covered by 4741 or the partial-locking draft?

BALAZS: 4741 or partial-lock does not define any non-Netconf locks. However both 4741 and 
partial-lock discuss and handle the case of foreign locks. All our locks are multiprotocol 
locks. In RFC4741 there is a specific eror code for foreign locks.
So IMO we definitely should include them here. As some devices might not be able to provide 
this information, we should include something like:

Information about non-NETCONF locks SHOULD also provided. The session ID should follow RFC4741:
Session ID of session holding the lock, for non-NETCONF sessions this maybe zero.

19) TransportType must no be restricted to a fixed set of values. It must include
SOAP, BEEP and TLS. Same comment for YANG.

[Response] Done.  Data type remains an enum though.

BALAZS: MUST not be enum. One well known vendor uses TSP. So thats a violation of the standard.

20) ProtocolType must no be restricted to a fixed set of values. Same comment for
YANG.

[Response] Done.  Data type remains an enum though.

BALAZS: So you allow WebUIs but not JavaGUIs?  MUST not be enum.

21) The description clause of objects using the
             domainName type MUST describe how (and when)
             these names are resolved to IP addresses.

We do not describe whats required here !

[Question]  Not clear on what is being asked for here?  Do you mean describe how
something like DNS would be used to determine hostname?

BALAZS: Then remove your own text, that demands the description!

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Mar 2009 13:33:59 -0700

> (incl. those already raised by Andy - thanks!).

Thank you for your extensive summary of changes.
Definitely counts as 'extra credit'.

The only response I will make now is regarding per-session
statistics.  The argument that somebody could use a Sniffer
(or RMON2) to monitor the NETCONF agent traffic instead,
could be used to eliminate almost any 'monitoring MIB'.

It does not hold in this case, because each <subscription> entry
has an <outNotifications> counter.  There is a global
counter for <outNotifications> as well.  The same feature
is needed for the rest of the global counters.

There are only 8 more counters in the <statistics> set that
apply to every session. These should be maintained in
each <session> entry.

> Mark

Andy