Subject: RE: Netconf Event Message as Working Group Document

From: "Glenn Waters" <[email-masked]>
Date: Tue, 8 Nov 2005 14:07:06 -0500

I support this working being adopted in the Netconf WG to support the
line in the charter that says:

"- Provides support for asynchronous notifications"

Further comments inline.

Regards, /gww 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Andy Bierman
> Sent: Monday, November 07, 2005 19:59
> To: Chisholm, Sharon [CAR:5K50:EXCH]
> Cc: [email-masked]
> Subject: Re: Netconf Event Message as Working Group Document
> 
> Sharon Chisholm wrote:
> 
> >hi
> >
> >I'd like to request that we add the Netconf Event Messages ID
> >(draft-chisholm-netconf-event-01.txt) as a working group document for
> >the Netconf working group. As previously discussed, it does not
require
> >an update to the charter.
> >
> >
> 
> The AD and NETCONF co-Chairs have already decided that there needs
> to be some implementation experience with NETCONF before we
> standardize extensions.
> 
> Has this event-01 draft been implemented and used in any operational
> or even test networks?  Are there a large number of WG members
> that think the NETCONF WG should focus on designing a new event
> management system at this time?

12 people were at the ad hoc editing session yesterday. These days in
the IETF that should be characterized as overwhelming support.

> Remember that our focus is configuration.

I disagree. From the charter:

"- Provides retrieval mechanisms which can differentiate between
    configuration data and non-configuration data"

It seems to me that we are considering data other than just config data.
We also had many discussions around how to distinguish config from other
data in the protocol. Read section 1.3 of the proto document.

> Even when we had notifications in the protocol,
> it was by reference to RFC 3195 (syslog over beep).
> There are some people in the WG (including me) that
> would rather not reinvent syslog or SNMP notifications.

I agree that the reasons for adding events to Netconf should be made
clear especially with respect to syslog. 

If Netconf is the replacement for SNMP, as many people are thinking
about, then SNMP notifications need a replacement. However, this just
brings up another work item that should be tackled -- transporting SNMP
managed objects over Netconf -- but this work item does not gate doing
events.
 
> I would rather that the WG focus on an access control model for
NETCONF.
> (Design it. Implement it. Refine it. Then bring it to the IETF for
> standardization.)

We have a draft for events that is being edited for its third revision,
seems like there is support and work going on.

With respect to access control we have zero drafts. I too would like to
see access control worked on but I don't see the work.

> >Sharon Chisholm
> >Nortel
> >Ottawa, Ontario
> >Canada
> Andy

Glenn.

--
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: Tue, 08 Nov 2005 11:39:32 -0800

>line in the charter that says:

I don't think charter word-picking really helps here.

Ultimately,  this is a decision for Bert and David to make.
I personally do not think the NETCONF WG should invent a new
notification information model at this time.  I could support a plan
to transport syslog and SNMP notifications over NETCONF,  but
spending major energy on 'events' before finishing the
security work (access control) is something I can't really support.

BTW, solving access control also solves the partial lock problem.
If AC is done correctly, that feature will fall out for free.

I can't imagine the IESG will prioritize re-invention of syslog/SNMP
over configurable access control for NETCONF RPC methods and
data models either, but who knows.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Nov 2005 12:09:06 -0800

>"- Provides support for asynchronous notifications"

2 more comments:

1) The charter text above is very vague.  From the XMLCONF days on
    through the time notifications were taken out of the NETCONF protocol,
    our entire (phase 1) work effort related to this charter item was to
    add a sentence pointing to the BEEP profile for RFC 3195. 

   IMO, adoption of Sharon's document is not covered by this charter item,
   and would require better charter text, WG approval, and AD approval.

 >....

>see access control worked on but I don't see the work.

I would like to see "rough consensus AND RUNNING CODE", not just a draft.
IMO, we should get back to that in the IETF. 

Andy