Re: XCAP to Proposed Standard

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.
>
>
>Andy
>
>
>
>>2.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 queue
>>and 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 Wednesday
>>7/5 COB.
>>Dan
>>
>>--
>>to unsubscribe send a message to [email protected] 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 [email protected] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/netconf/>