Re: notification-07 issue list

[Andy Bierman <ietf@andybierman.com>]

Balazs Lengyel wrote:
> Hello,
> I believe defining _any_ XML as configuration data in a datastore is 
> saying: "Vendor specific, unspecified". I don't like that. A workaround 
> could be to restrict the _any_ using plain english. However specifying 
> XML in plain english sounds bad.

This sounds like even more special-case (hack) code to deal
with NETCONF's version of XML, instead of "real XML".

> I would rather delay named profiles then have _any_ as part of a 
> standard data model.

I agree, if it means (and it does) backing into an important
data modeling decision without thinking it through or specifying any of
the details.

> As an alternative we could refer to named profiles without actually 
> defining them like we do with eventStreams. This would be a cleaner way 
> to say: vendor specific.

I disagree.

1) The eventStreams are defined well enough to be used within
the notification system.  How they get there in the first place
is outside the standard.  Without specifying the contents of
the named profile, there are missing pieces (like the filter).
The way subtree filtering is defined, the only data type that
works is 'any'.  Well-formed junk is just no-match, nothing more.

2) It is not vendor-specific.
The 'any' node (filter) has a conceptual definition
and there are standard algorithms for determining
the filter output.

The real problem is that <edit-config> itself is not fully
specified for all possible data-model related corner-cases.
IMO, the NETMOD specification should fill in those gaps,
not the protocol spec.

I am definitely in favor of creating standard data models
whenever possible, but a data model containing a template
for every conceivable data model is problematic, and perhaps
not that important in our notification delivery system.
Passing the <filter> as an RPC parameter places
it immediately into the 'internal format', not available
to <edit-config>.


> Balazs

Andy

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>