Subject: few quick comments on notification-07

From: Andy Bierman <[email-masked]>
Date: Tue, 15 May 2007 16:31:48 -0700

Hi,

Reading quickly through the new draft, I noticed a few things:

1) the namedProfile has an element called stream and the create-subscription
   RPC has a parameter called stream (in addition to named-profile 
parameter).

   The stream element in the namedProfile does not have any meaning,
   according to the create-subscription text.  The stream parameter is used,
   and the stream element in the namedProfile is ignored.  What is the point
   of having the stream element in the namedProfile?

2) There is nothing in the XSD that would indicate to an XSD tool that
   the read-only timestamp in the namedProfile must not be sent as part
   of the <edit-config> to configure a named profile.  I don't think
   this object should be in the data model, but if others think this
   is important, then I guess it will stay.  The value of this object
   is not explained anywhere -- it is just assumed that read-only
   timestamps should be mixed with config data without even mentioning 
it at all.

3) The replayComplete notification contains an eventClass element.
   The WG agreed that this notification will not have any content.
   This element must be removed.

4) The XSD for the replayCompleteNotificationType and the notification
   element are wrong.  The schema in the draft does not
   represent the normative text in the rest of the draft.

   The following notifications are valid, but this is not what the XSD 
allows:

    <notification>
      <replayComplete/>
    </notification>

    <notification>
     <blah xmlns="example.com"/>
    </notification>

I believe the XSD actually described the following XML:

   <replayComplete>
     <data/>
     <eventClass>blah</eventClass>
   </replayComplete>

which is completely wrong.

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 May 2007 11:49:32 +0200 (CEST)

>    timestamps should be mixed with config data without even mentioning 

It is mentioned in the description clause.

But I think that there are more serious issues with this data model,
and I have pointed it out before.   The intention is that this DM can
be modified with an edit-config.  But there is nothing in the schema
that says what the key for a namedProfile is.  So how do you modify
one?

Also, it says that the 'name' paramater (which I would guess is
supposed to be the key) is modifiable.  How is this done using an
edit-config?

filter has minOccurs=0.  What exactly does that mean?  Can I create a
namedProfile w/o filter?  I.e. does the minOccurs=0 apply to the
contents of the device's datastore, and not an instance document?

The filter itself is also supposed to be modifiable.  Now, the filter
can contain _any_ XML (if it's a subtree filter), and we're supposed
to be able to use edit-config to modify parts of it...?

IMO, if we are going to include this DM, the text needs to describe
how this is supposed to work, otherwise we won't see interoperable
implementations.

I suggest that for the filter parameter, the XML should be treated as
an opaque data structure, which can be deleted, created and replaced
in its entirety only.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 May 2007 08:11:16 -0700

> an opaque data structure, which can be deleted, created and replaced

I am concerned about adding poorly understood CLRs on top of a poorly
designed data model as a band-aid, and ending up with a non-interoperable
standard.

Due to the nature of subtree filtering, it cannot be implemented
with 'conventional' XML parsers at all.  Invalid declarations are
just no-match conditions, not errors.  Applying the <edit-config>
operation attribute to the filter is difficult, if not impossible,
in such cases.

The real issue is having a data model object of type 'any' in a
configuration database.  The real issue is that we don't
have much common understanding of the differences between XML instance
documents and NETCONF configuration databases.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 May 2007 17:27:40 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> just no-match conditions, not errors.

Absolutely.

> Applying the <edit-config>

Suppose we have this filter stored in a namedProfile:

  <foo hoo="1">
    <bar>2</bar>
    <baz>3</baz>
  </foo>

And I do the following edit-config:

  <foo hoo="2" nc:operation="merge">
    <bar>3</bar>
    <baz>3</baz>
  </foo>

Are you saying that there's a single correct data-model agnostic
answer what the resulting config looks like?

> configuration database.

Yes.

> The real issue is that we don't

So what's your suggestion?  Do you agree that this is a problem?

I don't think this is a CLR - if the type is 'any', we do
delete/replace/create on the entire thing.   One alternative would be
to not allow 'any', which in this case means remove namedProfiles.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 May 2007 09:00:38 -0700

> answer what the resulting config looks like?

no -- it doesn't even make sense to apply the edit-config
operations to type 'any' in every case.

For your example, my code would produce the following result,
since type 'any' means zero or more instances of arbitrary
unnamed nodes. (As always, attributes are zero or one instance.)

   <foo hoo="2">
     <bar>2</bar>
     <bar>3</bar>
     <baz>3</baz>
     <baz>3</baz>
   </foo>

> So what's your suggestion?  Do you agree that this is a problem?

yes.
A giant red flag goes up when I see massive implementation complexity
for a loosely defined standard, since this always leads to interoperability
problems.

> to not allow 'any', which in this case means remove namedProfiles.

The concern I have is that the protocol defines the edit-config operations
and it doesn't say in RFC 4741 that if the agent identifies a sub-node
within the configuration contents of type 'any', then all 'operation'
attribute declarations within that subtree will be ignored, and a 'replace'
operation will be performed on the node of type 'any' instead.

This is a hack, not a CLR.

This is an important issue because these named profiles are
mandatory-to-implement.  They are completely redundant as well.
There are no interoperability problems possible when type 'any'
is passed as an RPC parameter, but this is not true for the
edit-config operation on configuration data of type 'any'.

We have nothing in SMIv2 like type 'any'.
IMO, it is an extremely bad idea to use this data type
in a NETCONF configuration database.  All data should
be named and strongly typed instead.  This is a case where
the protocol WG is getting into data modeling issues it
doesn't fully understand.

Perhaps named profiles should be removed (deferred) until NETMOD
figures out what rules should be defined for standard NETCONF data models.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 May 2007 18:42:15 +0200 (CEST)

> This is a hack, not a CLR.

The idea was that the agent would just *allow* these operations, not
silently convert a delete into a replace.  So if it receives a
'operation' attribute somewhere within the 'filter', it would raise an
error.

I think this is a clean way to handle 'any'.

> doesn't fully understand.

I agree, but I can see that it is useful in some circumstances,
e.g. a logging mib is much easier to define with an 'any' type.

> figures out what rules should be defined for standard NETCONF data models.

Unless we can agree on how 'any' should be handled (at least in this
case), I think it's best to defer this.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 May 2007 10:12:27 -0700

> I think this is a clean way to handle 'any'.

So an operation-not-supported error gets returned instead?
The actual edit-operation in effect at any node depends on
the operation attribute(s) and the default-operation parameter.
The default is 'merge'.  So a merge on type 'any' can silently
turn into a 'replace' instead?

I think the specification of this clean way to handle 'any'
needs much more thought around the corner-cases.

> e.g. a logging mib is much easier to define with an 'any' type.

Yes, but that is monitoring data that is not affected by edit-config.
I should of said "writable data".  This is not a problem for read-only data.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 May 2007 19:43:16 +0200 (CEST)

> So an operation-not-supported error gets returned instead?

I'm not sure that's the correct error code.  Compare with this case.
Suppose a 'service' has two keys, 'ip' and 'port'.  What error message
do you get if you send:

   <service nc:operation="create">
     <ip>10.0.0.1</ip>
     <port nc:operation="delete">80</port>
     ...
   </service>

> turn into a 'replace' instead?

In the same way as merge "silently turns into a replace" on an
integer:

   <ifMtu nc:operation="merge">1500</ifMtu>

vs.

   <ifMtu nc:operation="replace">1500</ifMtu>

> needs much more thought around the corner-cases.

Well, it's not even written down, so you're probably right.  We
currently do not support 'any' in this way, but this is the way I've
planned to support it.

> I should of said "writable data".  This is not a problem for read-only data.

Ok.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 May 2007 12:29:34 -0700

>....

Except 'any' can have child nodes, so the difference is noticeable.

   <foo>
     <a/>
   </foo>

merged with

   <foo>
     <b/>
   </foo>

results in

   <foo>
     <a/>
     <b/>
   </foo>

or

   <foo>
     <b/>
     <a/>
   </foo>

but not

   <foo>
     <b/>
   </foo>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 May 2007 21:57:51 +0200 (CEST)

Maybe this is getting off topic.

> Except 'any' can have child nodes, so the difference is noticeable.

I think I know one implementation where this is the case, if foo is
defined to have a <choice> of a or b as children.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 May 2007 13:39:12 -0700

> defined to have a <choice> of a or b as children.

If <foo> is type 'choice' then it isn't type 'any'.
The 'b' result would be correct if <foo> was defined
as a choice of <a> or <b>.

(Merging choices correctly is fairly painful if one or more
of the choices is a 'group' instead of an 'element',
especially when dealing with defaults.)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 May 2007 09:29:47 -0700

>      <port nc:operation="delete">80</port>

This should be operation-failed, not operation-not-supported error.

Andy