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

Re: Notification Decision Point: Named Profiles

Sharon Chisholm wrote:
inline 
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Friday, June 22, 2007 10:19 AM
To: Netconf (E-mail)
Subject: Notification Decision Point: Named Profiles

<clip>
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.
<sharon>
I think people are going to want to put filters in their own data models
do it would be good to resolve the expected behaviours
</sharon>



really?
where are they now?

I would love to hear from implementers who support <edit-config>
on the 'any' data type now, so we can feel reassured that
this is a reasonable design choice.

AFAIK, many 'implementers' have expressed the opposite opinion.



<clip>

Proposed Consensus:
 * remove no-op 'stream' element
<sharon> It is only a no-op because the stream in the create-subscription is 
mandatory. There are two paths to resolve this
   1. Make the streams in create-subscription mutually exclusive with
named profiles (like we have done with other filter parameters) and give
it a min-occurs of 0.
   2. Delete it from named Profiles.


So the algorithm would be:
  1) if namedProfiles are used, and <stream> is present in both
     the named profile and the RPC method, but they are different
     values, then generate an 'invalid-value' error
  2) else use the <stream> element in the <create-subscription>, if present
  3) else use the <stream> element in the <namedProfile>, if present
  4) else use the 'NETCONF' stream.

What use case does this complex option serve?
The rationale for sharing filters is that they could be complex,
take up lots of memory, and possibly even be generated by
a 'shared application component'.
The name of the stream to use hardly fits that use case.

Why is the filter coupled to a stream?
There is nothing in the draft (or the design) that makes this assumption.




I think option 1 makes more sense.
</sharon>
 * declare the <edit-config> operation on the contents of the <filter>
   parameter to be 'undefined'
<sharon>
I assume this is just for the merge operation, where the issue is?


Processing the operation attribute within the 'any' child nodes
is somewhat undefined, so all the operations could be implemented
in different ways, across agents.


</sharon>
Comments?

thanks,
Andy




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