NETCONF Event Notifications
Note: This ballot was opened for revision 14 and is now closed.
(Dan Romascanu) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Lars Eggert) (was Discuss) No Objection
(Pasi Eronen) (was No Record, Discuss) No Objection
The restrictions "[replayLogCreationTime] MUST be present if replay is supported" could be expressed in XML schema, instead of just documentation. Ditto for "[stopTime] must be used with startTime".
(Russ Housley) No Objection
(Chris Newman) (was Discuss) No Objection
Notification Architecture We don't have a notification architecture in the IETF. It's unfortunate but true and in my book that limits the extent to which the IESG should constrain notification sub-systems. We do have two standardized publish/subscribe/notification mechanisms (SIP and XMPP) and the extent to which it's a good idea to create additional such mechanisms is unclear. While I am not opposed to netconf having a netconf-embedded notification subsystem despite the redunancy of that subsystem with SIP & XMPP, it will be important for netconf events to be visible in general-purpose notification systems. I don't expect the typical cell phone to ever have a Netconf client that keeps a connection to the Netconf server open, but such devices will have SMS, SIP and/or XMPP clients for general purpose notifications. I would be a lot more comfortable with this specification if it at least recognized some of these events need to be made available outside the Netconf session. Section 3.6.1 Nit: > parameter. A Filter only exist as a parameter to the subscription. s/exist/exists/ Section 7: > that it is viewed only by authorized users. If a user does not have > permission to view content via other NETCONF operations, it must not > have access that content via Notifications. s/it/she/ s/access that/access to that/