Andy Bierman wrote:
Cridlig Vincent wrote:Hi,merge is data-model specific.I just need a clarification on how merge is working, which I didn't find in the draft. I am not sure to understand what you mean by "merge is data-model specific. ". Is merge behavior up to the implementor, or are there some general guidelines on what the merge is doing ?This follows from the CLI. First, it is obviously important to know how multiple entries are distinguished and which fields need to be unique in a particular naming scope. A data model for access control lists may merge entries differently than a data model for assigning MAC addresses to an IP address.It is data model specific. Do you have suggestions for changing it?It would help a lot to explicitely state what data is to be created, deleted or replaced. I think one of these three operations must be explicitely present in each request.Specifying the key elements in the edit-config can help also.I understand "merge" as a way to hide the real operations (create, replace, delete). But it is ambiguous in some cases, even if you define a strict data model (see the examples).Agreed. That's why I'm creating my own "internal" data modeling language that deals with all these netconf details. Merge could be automated with some additional data.Standard algorithms like "first, last, natural-order, dont-care, user-defined"can help.
What would be great is an edit-config operation that is self-sufficient to update the XML config. Just like XSLT is doing to transform a document to an XML output without worrying about keys.
You are using a nice clean XPath expression. Unfortunately, this is a small subset of the entire language. I think there are huge problems with setting or locking data items based on arbitrary Xpath expressions.The XPath that I used is simple but it can be as complex as you want to. I don't see the problems that it could create. Can you explain more ?What if the expression can resolve to more than one node in the data model?Do you pick one at random? Is the purpose of this to save space? Using a path expression instead of the XML sub-tree does save space.
If the number of selected nodes is higher than 1, they will be replaced all (in case the operation is replace). This can happen also with edit-config if the matching nodes match several nodes in the config. Not only it saves bandwidth, but it addresses a set of nodes unambiguously and many people understand XPath.
Vincent
You understand that the instance documents will not likely carry instance naming and other semantic meta-data, along with the data itself. This has been raised in the WG before. The schemas for those instance documents are needed to implement netconf correctly. It has never been a design goal of the WG for applications to be able to do real work with netconf with no understanding of the underlying data models.
___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com -- 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/>