Subject: RE: few quick comments on notification-07

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 28 Jun 2007 22:34:58 -0400

hi

Having read through this Martin & Andy thread, here are my thoughts

1) If there are ambiguities in the base protocol that the notification
draft brings up, it likely makes sense to clarify them in the base
document so that all capabilities can take advantage of them

2) In general, 'any' is viewed as something you want to avoid, but
seeing as we have it in subtree filtering, we should just clarify
whether merging is supported on the subtree object and if so what the
expected behaviour is. Were there any other issues with the edit-config
of the named profiles? 

3) Does the named profile really need a key? It is easy enough to add
one, but if we don't actually need it, then I'd say leave things as is.
The current XSD, based on earlier discussion, allows people to rename
named profiles and I don't know whether making name a key still allows
that.

4) It seems we have raised minor issues with named profiles, which in
the spirit of a second working group last call, it would seem that the
correct thing to do would be to fix them, not to make drastic changes to
the document.

Sharon

--
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: Thu, 28 Jun 2007 20:04:57 -0700

> expected behaviour is. Were there any other issues with the edit-config

The WG has to decide how important the "feature" of using
the 'any' data type in data models is to have.  Revising the
base protocol document is not easy, or something done lightly.

> named profiles and I don't know whether making name a key still allows

Yes, the namedProfile needs a key, which is the 'name'.
This allows interoperability wrt/ edit-config operation.
What use-case is served by renaming the profiles?
Why can't somebody just edit the XSD by hand if they want it
to represent some non-standard schema, unrelated to this document?

> correct thing to do would be to fix them, not to make drastic changes to

It depends how important people think this feature is.
It might be that there is no suitable fix to the 'any'
data type problem.  Perhaps the WG does not want
to hold up this draft to solve that problem.

> Sharon

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 30 Jun 2007 09:43:16 -0700

Sharon Chisholm wrote:
>...

I am still trying to understand this comment.
Imagine if we were writing a MIB, and decided to
leave the INDEX clause out of the 'namedProfileEntry'
OBJECT-TYPE macro, in case somebody wanted a different INDEX clause.

Priority 1 is multi-vendor interoperability.
The document should focus entirely on the standard mechanisms
agreed to by the WG.

Clearly, the 'name' of a named profile is its key.
Without a key, none of the edit-config operations
(create, delete, merge, replace) can be implemented.

I am unaware of any earlier discussion proposing a different INDEX
for this table.

>>...

Andy