[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notification Decision Point: Named Profiles

tom.petch wrote:

----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Friday, June 22, 2007 4:18 PM
Subject: Notification Decision Point: Named Profiles


Let's see if we can reach some decisions on named profiles on the
mailing list.
They were originally added as a way for sessions to store and share static
filters on the agent, instead of passing the filter directly in the
<create-subscription>  RPC.

The use of the 'any' data type is problematic for <edit-config>, and there
is not consensus on any deterministic algorithm for processing this
operation on a data node like this, such as <filter>.  Two people
have strongly objected to usage of the 'any' data type at all
in NETCONF data models.

Top Level Options:

  * Keep Named Profiles in this document and fix the problems
  * Defer named profiles until data modeling issues with <any> resolved
  * Remove named profiles from this document


If decision is to keep named profiles:

Clear Consensus:
 * add a <key> definition identifying 'name' as the index

Proposed Consensus:
 * remove no-op 'stream' element
 * declare the <edit-config> operation on the contents of the <filter>
   parameter to be 'undefined'

Comments?


Since you asked:-)

I think that named profiles are good to have and that we should fix the problems
now.  But what are the problems?  Trouble is, as your knowledge of XML has
increased over the past two years - which it markedly has - so has, for me, the
opacity of your comments.  I do not know what problems you mean by any; I seem
to recall a post about this a while back saying that probably only Martin and
you would be interested - I read no further.

I know of anyType as the root of the XML type hierarchy but do not know XML well
enough to know if any also exists as something else or if it is anyType that you
mean.

And if anyType is meant, what is the problem?  I imagine it is to do with
coercion, the refinement of the type of a variable by its context, so that a
consecutive number of characters could be a string, an array, an integer, float,
struct ref
etc depending on the context.  I am a believer in coercion when the language has
weak typing (as XML has) so I believe that such problems can be solved.

But here, as yet, I am unclear what needs solving.



The problem is processing the <edit-config> operation consistently
for child nodes of the 'anyType'.  For indexed data, it is clear
which node is being created, deleted, merged, or replaced.
Since 'any' could mean multiple unnamed instances of arbitrary nodes,
all entries are different.  For example, the way subtree filtering works,
an agent can tell if the manager is deleting a leaf or a row,
based on the data model.

For 'anyType', the operations would not work the same as if the
manager was doing an <edit-config> on the actual data model
(not the filter for the data model), since there is no data model for 'anyType'.
This is not what the manager wants, but that's too bad.

Martin suggested treating 'anyType' special and perhaps
ignoring the operation attribute within this node type.
Balazs and I think NETCONF Configuration Databases should not
contain data using this 'untyped type', rather than create special
processing rules -- e.g., treat this as a simple type (leaf node)
even though it isn't.




Tom Petch


Andy




thanks,
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/>







--
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/>