Subject: RE: Notification Decision Point: Named Profiles

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 3 Jul 2007 10:54:20 -0400

inline 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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>

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

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?
</sharon>
Comments?

thanks,
Andy

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

--
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, 03 Jul 2007 08:40:24 -0700

> do it would be good to resolve the expected behaviours

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.

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

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 3 Jul 2007 13:14:56 -0400

Hi,

I think this is relevant to the question,
 
> There is nothing in the draft (or the design) that makes this 
From the minutes of the Montreal interim meeting:
"h) Notification suppression filtering is data-model and 
   stream dependent."

My interpretation of this is that a filter might be (might need to be)
designed to apply to a particular (type of) stream. If, for example,
the SIP community developed a new stream format, then some
SIP-specific filters might only make protocol-sense with that stream.
Therefore, one might want to define the relevant stream as part of the
namedProfile.

dbh

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 3 Jul 2007 13:54:07 -0400

Hi

Putting them in the same named profile does not make them related. It
says that when applied to a subscription, that I apply some filters
against the contents of the stream, just like it does when I do it
directly against the create-subscription.

It is a collection of stuff that allows someone to easily reproduce a
particular subscription.

Sharon 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2007 1:15 PM
To: 'Andy Bierman'; Chisholm, Sharon (CAR:ZZ00)
Cc: 'Netconf (E-mail)'
Subject: RE: Notification Decision Point: Named Profiles

Hi,

My interpretation of this is that a filter might be (might need to be)
designed to apply to a particular (type of) stream. If, for example, the
SIP community developed a new stream format, then some SIP-specific
filters might only make protocol-sense with that stream.
Therefore, one might want to define the relevant stream as part of the
namedProfile.

dbh

---

From: Andy Bierman <[email-masked]>
Date: Tue, 03 Jul 2007 19:33:45 -0700

> Therefore, one might want to define the relevant stream as part of the

Why?

In XML, a QName completely identifies the content.
The SIP-specific filters would be for a SIP-specific
data model, which would have a targetNamespace and a top-level element.

We don't need to reinvent XML.
There is nothing special about a stream, such that it's name
always indicates exactly one namespace and top-level element.
So is this name field kind of a one word description clause?

Andy

---

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Jul 2007 18:08:56 +0200

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Netconf (E-mail)" <[email-masked]>
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:

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.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jul 2007 10:41:10 -0700

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

Andy