Subject: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-08

From: "Mark Scott" <[email-masked]>
Date: Mon, 28 Sep 2009 13:05:15 -0400

Hello,

A new version (v8) of the NETCONF Monitoring Schema draft has been posted.

This version addresses action items from IETF75 and mailing list comments.  Most significant is the decision to adopt YANG as normative for this draft.

As a result the publication of this draft depends on:
 - WGLC updates (if required)
 - updates to the normative model as result of netmod YANG (if required)
 - data organization changes if WG adopts a new data hierarchy for netmod (this draft uses "/netconf-state/")

The XML Schema of the monitoring model and IP host definition have been removed.

Please direct any comments on this version to the mailing list.

cheers,
Mark

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Monday, September 28, 2009 12:42 PM
To: Scott, Mark (CAR:2N00)
Cc: [email-masked]
Subject: New Version Notification for draft-ietf-netconf-monitoring-08 

A new version of I-D, draft-ietf-netconf-monitoring-08.txt has been successfuly submitted by Mark Scott and posted to the IETF repository.

Filename:	 draft-ietf-netconf-monitoring
Revision:	 08
Title:		 NETCONF Monitoring Schema
Creation_date:	 2009-09-28
WG ID:		 netconf
Number_of_pages: 30

Abstract:
This document defines a NETCONF data model to be used to monitor the
NETCONF protocol.  The monitoring data model includes information
about NETCONF datastores, sessions, locks 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.

The IETF Secretariat.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Sep 2009 21:04:18 +0200

On Mon, Sep 28, 2009 at 07:05:15PM +0200, Mark Scott wrote:
 
> This version addresses action items from IETF75 and mailing list
> comments.  Most significant is the decision to adopt YANG as
> normative for this draft.

I still do not like the capitalized identifiers. Furthermore, we
should import relevant types from ietf-netconf (SessionId can clearly
be imported). The NETCONFDatastoreType should probably be provided by
ietf-netconf (after renaming).

I am wondering why you use zero-based-counter32 and not just
counter32.  Do we worry about the fact that this might rollover and
become ambiguous?

I think all definitions should have proper descriptions. Not all have
them.

What is the reason to define groupings inline?

It is unclear what the "NETCONF server process" is on implementations
that use multiple server processes working together, e.g. one frontend
forked from sshd and a backend interfacing to potentially even more
processes.

I would appreciate a more detailed description which counters I can
derive from the counters in the YANG module.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Oct 2009 08:43:05 +0200 (CEST)

Hi,

I will comment on some of your issues, and let Mark reply to the
others.

Juergen Schoenwaelder <[email-masked]> wrote:
> I still do not like the capitalized identifiers.

+1

> Furthermore, we

I agree in principle, but that would mean that this document will wait
not only for YANG, but also for rfc4741bis.  Do we want to do that?

> counter32.  Do we worry about the fact that this might rollover and

This way you can easily see if e.g. any errors has happend in a
session.  You know that it starts from 0 when the session starts.

> What is the reason to define groupings inline?

Do you prefer to export all groupings?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Oct 2009 08:55:28 +0200

> session.  You know that it starts from 0 when the session starts.

This is true only under the assumption that the counter did never roll
over in a session. Is this assumption reasonable to make for the
counters?
 
> Do you prefer to export all groupings?

So you defined groupings inline so they can't be used elsewhere? I am
just trying to understand; personally I have no problem with exporting
groupings by default since you never know what a vendor extension
wants to reuse.

/js