Subject: Proposed Update to Netconf Charter

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 29 Jun 2005 16:33:01 -0400

hi

As promised, here are the proposed updates to the  Netconf charter to cover
the work coming down the pipe:

"Additional phase 2 work including:

- Requirements and Guidelines for defining Netconf content to enable
interoperable, high-quality and usable netconf implementations. Requirements
will be defined around specification language,  access control, compliance,
backwards compatibility, depicting relationships, event specification, and
application error message specification.

- An initial set of application-level re-usable data types such as IP
Addresses, MAC addresses, etc. This definition would be compliant to the
above defined requirements and guidelines for Netconf content.

- An XML Schema for reporting information about the Netconf system. This
definition would be compliant to the above defined requirements and
guidelines for Netconf content.

- A netconf protocol specification for asynchronous messaging to enable the
sending of events. This must preserve the netconf layers."

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Jun 2005 23:09:12 +0200

> application error message specification.

I also would prefer to talk about "data models" rather than "Netconf
content". I would strike out "high-quality and usable" as it does not
really help in charter text. I am not sure what "backwards compatibility" 
means - I guess I know what you have in mind but this phrase can be 
read in several ways. I rank guidelines on how to write data models
high.

I think access control should not be lumped together with data model
specification guidelines. This is really a separate point and I am not
sure we are ready to agree how that should be done. I do not rank this
very high at the moment and could very well live with postponing this
to the 3rd phase once we start to have operational experience.
 
> above defined requirements and guidelines for Netconf content.

This is what I believe is really important to get done. My recent
study on the contents of some ~800 MIB modules shows quite clearly
how important some of these core data types have been in the SMI
world. So I would rank this point high.
 
> guidelines for Netconf content.

I would prefer "A concrete data model" over "An XML schema" to reduce 
the number of different terms for the same thing down to one. If we
have concensus to use XML schema, then I am also fine with using XML
schema terminology everywhere. I just dislike the mixture of terminology
here. I rank this medium high - I do believe that we need to write
concrete examples to see whether our guidelines work, but I am not
sure netconf itself has something of reasonable complexity to 
configure.
 
> sending of events. This must preserve the netconf layers."

Again, not totally clear. Are we talking about events related to a
netconf implementation itself or are we talking about the transport
of general notifications (aka syslog messages)? I do not rank this
very high - could live with postponing this to phase 3.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany