Subject: RE: Proposed Update to Netconf Charter

From: "Faye Ly" <[email-masked]>
Date: Wed, 6 Jul 2005 11:14:01 -0700

Andy,

I agree with 'defining common authentication scheme for access control'
and also would like to see 'define a way to multiplex channels over a
single secured connection between manager and agent'.  The latter is
needed to support multiple management channels like notification,
syslog, image/file management and/or regular netconf.  

This is to help lower the cost of configuring many secured connections
between manager and agent.  

-faye

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Tuesday, July 05, 2005 9:27 AM
To: Sharon Chisholm
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/>

--
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: "Tom Petch" <[email-masked]>
Date: Thu, 7 Jul 2005 12:43:28 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Faye Ly" <[email-masked]>
To: "Andy Bierman" <[email-masked]>; "Sharon Chisholm"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 06, 2005 8:14 PM
Subject: RE: Proposed Update to Netconf Charter

Andy,

-faye

Common authentication implies that you are authenticating the same thing.  SNMP,
because the operators wanted it, authenticates a 'principal' which may or may
not correspond to a human user, but is distinct from the platform which is
providing the other end of the connection.  I think it easy, and at times too
simplistic, to think in terms of setting up a secure channel with, and
authenticating, a 'client' (or server) without realising that one should be
authenticating at a finer level of detail.  The 'principals' for syslog, netconf
etc may be different even though they share a secure channel and platform.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Jul 2005 05:59:05 -0700

>etc may be different even though they share a secure channel and platform.

Good points.
I'll raise an even stronger concern...

SNMP has its own security model, which (IMO) is bloated and over-engineered.
I am strongly opposed to any integration between SNMP and NETCONF security
models because NETCONF is new and we should try not to ruin it so soon.
NETCONF is not SNMPv4 and never will be if I can help it, and its security
mechanisms should not be compromised to work well for SNMP (or SYSLOG or
anything else, other than NETCONF). 

Andy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 07 Jul 2005 15:15:41 +0200

Andy,

At this point, the only thing contemplated would be to make use of the
same authentication mechanisms - not authorization mechanisms.  And the
way that it is contemplated is through the use of BEEP, perhaps even
sharing a BEEP session.

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 Jul 2005 09:21:49 -0700

>way that it is contemplated is through the use of BEEP, perhaps even

I understand that -- the thought of making VACM or something like it
work for NETCONF is what concerns me.  Integrated authentication
sounds great until you get into the details, or until you read our charter.

It is going to be a tough sell to convince those of us in the WG that
don't care about integrating SNMP and NETCONF to compromise
or otherwise over-engineer a solution that accommodates other protocols
beyond NETCONF.

If somebody posted a draft containing a brilliant solution
to the problem I would probably change my mind.   But I
don't see any drafts (clueless or brilliant), so until then I don't
think integrated authentication is something this WG should do.

Andy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 07 Jul 2005 19:09:00 +0200

Andy,

We will post a draft.  We're not asking anything of the NETCONF working
group.  This is all going on in ISMS.

Eliot