Re: Notification Decision Point: Named Profiles

["tom.petch" <cfinss@dial.pipex.com>]

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

Tom Petch

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