An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources
draft-ietf-simple-xcap-diff-14

[Ballot comment]
1.  Introduction

  The Extensible Markup Language (XML) Configuration Access Protocol
  (XCAP) [RFC4825] is a protocol that allows clients to manipulate XML
  documents stored on a server.  These XML documents serve as
  configuration information for application protocols.  As an example,
  resource list [RFC4662] subscriptions (also known as presence lists)
  allow a client to have a single SIP subscription to a list of users,
  where the list is maintained on a server.  The server will obtain
  presence for those users and report it back to the client.  This
  application requires the server, called a Resource List Server (RLS),
  to have access to the list of presentities.

I think the first use of a term like "presentity" needs an Informative Reference.


3.  Structure of an XCAP Diff Document

  The  element has one mandatory attribute, "sel", and a two
  optional attributes, "new-etag" and "previous-etag".  The "sel"
  attribute of the  element identifies the specific document
  within the XCAP root for which changes are indicated.  Its content
  MUST be a relative path reference, with the base URI being equal to
  the XCAP root URI.  The "new-etag" attribute provides the entity tag
  (ETag) for the document after the application of the changes,
  assuming the document exists after those changes.  The "previous-
  etag" attribute provides an identifier for the document instance
  prior to the change.  If the change being reported is the removal of
  a document, the "previous-etag" MUST only be included and the "new-
  etag" attribute will not be present.

I suggest rewording the last sentence:

"If the change being reported is the removal of
a document, only the "previous-etag" MUST be included and the "new-
etag" attribute MUST NOT be present."

  In a corner case where the
  content of this element cannot be presented for some reason, although
  it exists in the XCAP document, the  element MUST NOT have
  any child nodes.

Can you please elaborate more on the corner case?

  Each  element indicates the existing attribute content of
  an XCAP document.  It has one mandatory attribute, "sel", and one
  optional attribute, "exists".  The "sel" attribute of the
  element identifies an XML attribute of an XCAP document.  It is a
  percent endoced relative URI following XCAP conventions when

typo: encoded

  selecting attributes.

[Ballot comment]
1. The OPS review asked about the need for a mechanism to specify which levels of related configurations must be present similar to the one in configuration control systems. This diff format specification does not provide a mechanism for doing versioning and coordination of incremental changes. Although it is not clear that this is a mandatory requirement for xcap it is certainly good practice, and it would be good to have this addressed (or explain why it is not needed).

2. The XCAP and XCAP-diff documents do not specify how to manage the underlying XML documents, or how to reflect incremental changes in a management interface.

XCAP is a type of application-specific HTTP, and the XCAP spec discusses the difficulty of differentiating XCAP traffic from other HTTP traffic, such as at a firewall. As a result, it would seem to be difficult to monitor XCAP-specific faults and performance by doing stream analysis; this would seem to call for having the server and client include support for providing management information, since the XCAP server and XCAP client CAN easily determine which traffic is XCAP related.

An information model describing the data needed for monitoring the XCAP protocol, measuring protocol performance, measuring any impact on network performance, and standardization of operational configuration for the XCAP protocol are simply not discussed. There is no discussion in the XCAP spec or the XCAP-diff spec that explains why management is not needed for XCAP or XCAP-diff.

I am not satisfied with the response provided by one of the editor that this is an implementation issue. It may be true that manageability may be addressed in a different place but some reference that the issues were considered and how they are addressed or why they need not be addressed would be useful to be included.

[Ballot discuss]
The Security and OPS review performed by David Harrington raised a couple of issues which were not answered completly in the discussion that followed. I would like to discuss them further before approving this document and decide whether text should be added to warn about the potential issues in deployment.

1. What happens if multiple diffs are applied in different orders? Especially it is not clear what happens if many notifiers (diff-generators) apply changes for the same document - would the different clients be able to read these changes in a consistent manner?

2. It looks (and the authors seem to acknowledge) that deployment on large scale is a problem. This can also be a potential source of DOS attacks, with a client sending repeated small changes that each needs to be propagated to all the other clients. I do not know if there is any solution on this respect but I think that some warning text on this respect should be added.

[Ballot comment]
1.  Introduction

  The Extensible Markup Language (XML) Configuration Access Protocol
  (XCAP) [RFC4825] is a protocol that allows clients to manipulate XML
  documents stored on a server.  These XML documents serve as
  configuration information for application protocols.  As an example,
  resource list [RFC4662] subscriptions (also known as presence lists)
  allow a client to have a single SIP subscription to a list of users,
  where the list is maintained on a server.  The server will obtain
  presence for those users and report it back to the client.  This
  application requires the server, called a Resource List Server (RLS),
  to have access to the list of presentities.

I think the first use of a term like "presentity" needs an Informative Reference.


3.  Structure of an XCAP Diff Document

  The  element has one mandatory attribute, "sel", and a two
  optional attributes, "new-etag" and "previous-etag".  The "sel"
  attribute of the  element identifies the specific document
  within the XCAP root for which changes are indicated.  Its content
  MUST be a relative path reference, with the base URI being equal to
  the XCAP root URI.  The "new-etag" attribute provides the entity tag
  (ETag) for the document after the application of the changes,
  assuming the document exists after those changes.  The "previous-
  etag" attribute provides an identifier for the document instance
  prior to the change.  If the change being reported is the removal of
  a document, the "previous-etag" MUST only be included and the "new-
  etag" attribute will not be present.

I suggest rewording the last sentence:

"If the change being reported is the removal of
a document, only the "previous-etag" MUST be included and the "new-
etag" attribute MUST NOT be present."

  In a corner case where the
  content of this element cannot be presented for some reason, although
  it exists in the XCAP document, the  element MUST NOT have
  any child nodes.

Can you please elaborate more on the corner case?

  As the result XML element is typically namespace qualified, all
  needed namespace declarations MUST exist within the
  document.  The possible local namespace declarations within the
  result element exist unmodified as in the source document, similar to
  XCAP conventions.

I can't quite parse this sentence. Can you elaborate?

  Other namespace references MUST be resolved from
  the context of the  or its parent elements.  The prefixes of
  qualified names (QName) [W3C.REC-xml-names-20060816] of XML nodes
  also remain as they exist originally in the source XCAP document.


  Each  element indicates the existing attribute content of
  an XCAP document.  It has one mandatory attribute, "sel", and one
  optional attribute, "exists".  The "sel" attribute of the
  element identifies an XML attribute of an XCAP document.  It is a
  percent endoced relative URI following XCAP conventions when

typo: encoded

  selecting attributes.



I would like to know what is the use case for ?

[Ballot comment]
I greatly appreciated the thorough treatment of the semantics for previous-etag and
new-etag when they appear in combination and when each appears alone.  I am afraid
I missed something subtle with respect to new-etag appearing alone, though.  I understand
the scenario where the document was just created, but when would the "document exists"
scenario be invoked?  In this case, the document hasn't changed, so why would there
be a diff document at all?

[Ballot discuss]
The security considerations are clear and factual, but may leave the reader with the wrong
impression regarding the importance of protecting XCAP diff documents.  This document
states:

    [....]                    if the document itself is sensitive and requires
  confidentiality, integrity or authentication, then the same applies
  to the XCAP diff format.  Therefore, protocols which transport XCAP
  diff documents must provide sufficient security capabilities for
  transporting the document itself.

This is all true, but does not indicate whether XCAP documents are likely to be sensitive,
or what the typical transport capabilities are likely to be.

The Security Considerations of the XCAP spec (RFC 4825) are very clear about this:

  Frequently, the data manipulated by XCAP contains sensitive
  information.  To avoid eavesdroppers from seeing this information, it
  is RECOMMENDED that an administrator hand out an HTTPS URI as the
  XCAP root URI.  This will result in TLS-encrypted communications
  between the client and server, preventing any eavesdropping.  Clients
  MUST implement TLS, assuring that such URIs will be usable by the
  client.

This is probably obvious to a reader with sufficient XCAP expertise, but I
believe that the first paragraph needs to supplemented with a note that
TLS-encrypted communications are commonly employed for transporting
XCAP documents, and point to 4825 for further discussion of the security
requirements for XCAP documents.

In the following paragraph, it would be helpful if this document suggested
a SIP baseline for providing a similar of security attributes.  Some warning
about hop-by-hop vs. end-to-end security would be helpful as well.

[Ballot discuss]
Section 9.1., paragraph 6:
>    [RFC2648]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
>              August 1999.

  DISCUSS: This is a downref. To me, it looks like the ref can become
  Informative; otherwise call it out during a LC.

[Ballot comment]
Figure 1 isn't entirely clear to me.  What do the "-" and "*" symbols mean?

In the sentence immediately before Figure 1, s./how corresponding/how the corresponding/ ?

There are no instructions to IANA in section 7.1.  Will IANA know what to do with that section?

IANA comments:

Action 1 (Section 7.1):

Upon approval of this document, IANA will make the following
assignment in the "Application Media Types" registry located at
http://www.iana.org/assignments/media-types/application/

xcap-diff+xml [RFC-simple-xcap-diff-13]


Action 2 (Section 7.2):

Upon approval of this document, IANA will make the following
assignment in the "ns" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template Reference
-------- ------------------------------- ------------------- -------------
xcap-diff urn:ietf:params:xml:ns:xcap-diff xcap-diff [RFC-simple-xcap-diff-13]


Action 3 (Section 7.3):

Upon approval of this document, IANA will make the following
assignment in the "schema" registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename Reference
--------- ----------------------------------- -------- -------------
xcap-diff urn:ietf:params:xml:schema:xcap-diff xcap-diff
[RFC-simple-xcap-diff-13]

We understand the above to be the only IANA Actions for this document.

Technical Summary
This specification defines a document format that can be used to
indicate that a change has occurred in a document managed by the
Extensible Markup Language (XML) Configuration Access Protocol
(XCAP). This format indicates the document that has changed and its
former and new entity tags. It also can indicate the specific
change
that was made in the document, using an XML patch format.


Working Group Summary
This document reflects the consensus of the SIMPLE working group.
It is a companion document to a SIP Event package (xcap-diff)
defined
by the SIP working group, and leverages the xml-patch-ops work
from SIMPLE.

Document Quality
The document has received cross-WG review, including attention from
expert SIP-Events reviewers. A media type review was requested Oct
24,2008.

(1.a)
Robert Sparks is this document's shepherd and believes this document
is ready for consideration for publication as Proposed Standard.

(1.b)
This document has been fairly reviewed by members of both the SIMPLE
and SIP working groups.

(1.c)
The typical reviewers from SIMPLE and SIP do not tend to focus on the
quality of XML schema. However, the editor of this document has
considerable experience and skill in this area.

(1.d)
There is one issue related to this draft (but not affecting this
draft) to pay attention to.
Subscriptions (or other references) to lists of things described by
this draft may need to address some handling ambiguity.
This was discussed on the SIP list wrt the xcap-diff event package,
and on the sipping list with respect to sip-uri-list-subscribe.

(1.e)
There is solid consensus across both the SIP and SIMPLE working groups
around the contents of this document. Careful participation in its
development came from a relatively small subset of the normal
participants in those groups.

(1.f)
There is no history of extreme discontent with this document.

(1.g)
The document satisfies the ID-nits requirements except for one downref
to RFC 2648.

(1.h)
The document is split appropriately into normative and informative
references.
There is one downreference to RFC2648 as it adds "urn:ietf:params:xml:ns:xcap-diff
" as an XML namespace.

(1.i)
The document has an appropriate IANA consideration section.
The document requests registration of a new mime type, a URN sub-
namespace, and a schema.

(1.j)
The document contains one XML schema document and one instance document.
These validate using the tool at validate.laboratory.net
(you have to take the patch-ops schema out of RFC5261 and edit the
include
line in the schema from this document to match).
Note that the author of this draft and the author of the tool at
validate.laboratory.net are the same person.

(1.k)
see above