Subject: RE: Named Profiles for notification configuration (unofficial issue #16)

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 27 Mar 2006 11:31:59 -0500

hi

Access control is something the working group should definitely get to,
but I'm not sure how it specifically applies to this issue.

The named profile is intended to be a standard way for people to hook in
proprietary filtering. It is not intended to specified in an
interoperable way, other than how you hook the name in. The more
standardized approach is what the Xpath and subtree (defined
consistently with other Netconf commands) is intended for.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Monday, March 27, 2006 10:59 AM
To: Netconf (E-mail)
Subject: Named Profiles for notification configuration

Hi,

IMO, the entire concept of the 'named-profile' configuration option in
the draft is broken.  From a standards POV, it is broken because there
is no way for 1 vendor to set a profile and another to use it.  The
content is unspecified.

More importantly, this is "just another data model".
We already have an architecture for defining, naming, and manipulating
data with standard RPC methods (e.g., <edit-config>). IMO, adding a new
'opaque' label-based configuration model on top of that is a bad idea.

As Wes would say, "Have you fully considered the access control
implications of this design?"  I don't think so.

Andy

--
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: Andy Bierman <[email-masked]>
Date: Mon, 27 Mar 2006 09:27:03 -0800

Sharon Chisholm wrote:
> proprietary filtering. 

Not sure how access control applies to opaque parameters? Yikes!

There aren't going to be any blatant proprietary hooks in NETCONF.
This needs to be fully specified or removed.  Independent
implementations must be able to interoperate based on this
specification.  An opaque "named profile" that just somehow magically
appears on the device is not inter-operable or secure.

It is not intended to specified in an

Andy