I can give you my take on these questions.With regard to the intended use, to some degree there is a primary use and some additional / alternative uses. The primary use for XCAP is to allow individual users of a service to configure the properties of their usage. This would, for example, include a user on a cell phone updating his preferences or his buddy list, or his privacy policy, or ... On the other hand, I had used XCAP to manipulate the configuration of a deep packet inspection device. It was easy to do. I could get it running. It gave me a state oriented view of the configuration of the device, rather than an operation oriented view. Which matched what I needed.
The access control model for XCAP is implicit. That is, it is expected that one is using HTTPS, that one has logged in as a specific user, and normally the documents one has visibility to are those for that user (see primary use case above.) For device configuration, the userid that was logged in would restrict the visibility / write permission for the configuration.
With regard to persistence, in the normal use case it is assumed that the change is applied to the users documents, and takes effect immediately and permanently. The SIP working group has not (and would not) discuss running vs startup config. I made some choices when I abused XCAP for that purpose. (I believe that if that usage actually mattered one would distinguish using different file identifiers after the application usage.)
There are significant differences in perspective between NETCONF and XCAP. While I note that I presonally like XCAP for configuration, there are some definite issues with using it. There are some very good reasons for using NETCONF, among them a much easier adoption path. So I don't think anyone is asking that NETCONF stop and switch to XCAP. At the same time, the primary XCAP problem is quite different from NETCONF's, and derailing work in that direction likely makes as little sense.
Yours, Joel At 05:21 PM 7/4/2006, Andy Bierman wrote:
Romascanu, Dan (Dan) wrote:The XML Configuration Access Protocol (XCAP) - http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-11.txt developped in the simple WG is on the agenda of the 7/6 IESG telechat.I looked this document over, which is not a review of any sort, but I have a few questions: 1) Is this intended only for use with SIP? 2) Is there any access control model for securing data? (What is the security model?) 3) Is there a persistence model for data? (IMO there are problems with trying to abstract a NE device configuration as an XML document, and this is one of them) 4) The examples would be easier to read if the XML was pretty-printed. 5) In a general sense there is clearly overlap between NETCONF and XCAP. I think NETCONF tries to be more content and transport independent, and the RPC-based architecture is more suited to standard and vendor "specialized RPC" extensions, which provide a more natural programming paradigm than a model based on XML document manipulation. Andy2.1.2 Returning Item Area Date RAI The Extensible Markup Language (XML) Configuration Access Protocol(XCAP) (Proposed Standard) - 1 of 1 draft-ietf-simple-xcap-11.txt [Open Web Ballot]Note: Note that this document was pulled from the RFC Editor queueand is returning with some changes, which are recorded in the tracker. Token: Jon Peterson Please let me know if there any questions or concerns until Wednesday7/5 COB. Dan -- 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/>
-- 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/>