Subject: [dispatch] Getting discussion going on draft-ietf-sipping-profile-datasets-03

From: "Dale Worley" <[email-masked]>
Date: Wed, 10 Jun 2009 16:36:45 -0400

This is the list of discussion points that I've assembled.  The first 5
are from the last IETF, and the last 3 are ones that have come to mind
when I reviewed the draft:

DP 1:  Merging rules are specified in the schema.

Everyone agrees that the merging rules for each property are to be
specified in the profile schema.  The only interesting merge rule now
used is "intersection", for combining values that are sets of an
underlying data type.

DP 2:  Devices containing sub-devices that are separately configured

The device will obtain one device profile and one local network
profile.  The device profile will specify the set of users, each user
implying one sub-device.  Each sub-device obtains its own user
profile.

DP 3:  Relax NG schema

Everyone prefers Relax NG schema language to XML schema language.

DP 4:  Versioning

A schema is extended by defining a new schema whose properties augment
or supersede the properties of the original schema (in a way defined
in the new schema).  This method avoids extending the set of values of
an existing property.  It also makes clear how the policy server
intends to configure a device that does not support the extension:
Such a device uses the dataset of the original schema.

DP 5:  Visibility

Each property in a dataset can specify its visibility separately.  We
need to merge visibility values to determine the visibility in the
merged "working profile".  Should the working visibility be copied
from the visibility of the value that was selected, or should the
working visibility be the AND of the visibility valuses?

DP 6:  The policy attributes

sipping-profile-datasets contains a rather messy mechanism for
specifying sets of values, tagging each value as "allowed" or
"disallowed", and then providing a policy for values that are not
mentioned.  It seems to me that this could be made much simpler by
having a mechanism that specifies either sets of allowed values or
sets of disallowed values, along these lines:

   <datum-name>
      <set>
         <value>1</value>
         <value>2</value>
         <value>3</value>
      </set>
   </datum-name>

   <datum-name2>
      <exclude>
         <value>1</value>
         <value>2</value>
         <value>3</value>
      </exclude>
   </datum-name2>

As long as we have an equality test for base type (that is, the
strings that can appear in the <value> elements), <set> and <exclude>
can be intersected and only generate <set> and <exclude> results.
(That is important because of the "intersection" merge rule.)  And we
assume that the base type is specified via Relax NG, which provides
such an equality test.

DP 7:  The direction attribute

sipping-profile-datasets provides for tagging values with a
"direction" attribute, which has values recvonly, sendonly, and
sendrecv.  The implication is that each property has two values, one
for incoming traffic and one for outgoing traffic.  Is this a good
model, since some values aren't specific for traffic direction?

DP 8:  The q attribute

sipping-profile-datasets provides a "q" attribute that can be
specified for elements of sets, so that the choices from a set can be
prioritized.  Is this facility needed?  And if we keep it, how are q
values to be combined when values are merged?

Dale