Subject: RE: Proposed Update to Netconf Charter

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 11 Jul 2005 08:00:57 -0400

hi

I'm in the process of updating the proposed charter updates based on all
the comments that have been received. I have a few comments which I
guess I will make here.

Previous guidance from the working group chairs is that they wanted to
see fully-baked solutions to various proposed problems, so as a result
of that they will be seeing a string of individual submissions which
below Andy was indicating he did not want to see.

I think the goal with access control should be to try to integrate with
existing deployed security solutions, not specifically with SNMP. If
SNMP succeeds in ISMS, then it will all be integrated without turning
the netconf access control mechanisms into VACM.

Given the layering model in Netconf and the wide selection of
application protocols and flavours of those application protocols that
are available, I don't think it unreasonable that not all of these will
be optimized for all netconf operations. Of course we don't want
something to be precluded in a particular flavour of an application
protocol, but if we limit ourselves to only what works very well over
http, I think we will be in trouble.

I think XML Schema needs to form the basis of our specifications. I hope
we don't spend too much time debating it. I'd rather move forward and
build upon that to define what we need to define to get interoperable
netconf content.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, July 05, 2005 12:27 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: [email-masked]
Subject: Re: Proposed Update to Netconf Charter

Sharon Chisholm wrote:

<chair-hat-on>
I have some real concerns with the wording of this charter text, but
rather than focus on that, let's just try to agree on a bullet list form
of the charter.

I would much rather see agreement on specific features first, (and then
let people propose solutions, from which the WG may select starting
points for 1 or more standard documents), rather than have the WG deal
with an ad-hoc array of individual submissions, as they come in.
</chair-hat-on>

[In the interest of transparency,  I am posting my
personal preferences for charter extensions]

<chair-hat-off>
Clearly, the addition of notifications is important to many people, and
its already in the charter, so that seems like a no-brainer. However, a
clean solution across all application mappings was not achieved in the
first attempt, so let's see what new ideas come in this time around..

I also think that core data types are critical.
There is actually no reason whatsoever this document couldn't have been
published years ago -- it has no coupling to NETCONF at all -- it is
just more XSD types to NETCONF.

Access control is also critical to get in place early on.
I prefer to start simple and evolve the complexity over time. IMO, a
mapping to ISMS should be a separate work effort, and probably in that
WG.

NETCONF AC is unique because it is both "RPC method" and document
oriented. IMO, old approaches like VACM will be clumsy and/or bloated if
applied to NETCONF.  Some new innovation is required  here.

I am also interested in the "SW image load" channel that has been
discussed in the past.  Often config reloads are coupled with image
reloads, and it would be nice if NETCONF could integrate some SW image
management features to support this requirement. </chair-hat-off>

Andy

>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/>
>
>
>  
>

--
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: Mon, 11 Jul 2005 14:11:06 +0200

> the netconf access control mechanisms into VACM.

I have no clue what you are trying to convey here - the ISMS charter is
pretty clear in saying that ISMS is not supposed to touch access control 
issues. Perhaps you just wanted to say that NetConf access control should
not be constrained by the way VACM works - something I do agree with.

/js

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