xmlconf discussions

[Phil Shafer <phil@juniper.net>]

Here's some thoughts on areas in xmlconf where discussion is needed,
and some of my opinions. Please jump in and let me know what you
think. It's a bit long and I've probably gotten too far into
details in some spots, but, hey, I like details. ;^)

Thanks,
 Phil




* XMLCONF Areas of Discussion

The following seem like key areas, where the choice of technologies
and their tradeoffs need discussed and explored:

Transport Protocol
Session Management
Security/AAA
RPC Technology
Operations
Encoding Conventions
Content Specification
Target Solution Space

These areas can be thought of as building blocks, independent
decision points that must be connected to build a complete
solution. 

** Target Solutions Space

What solutions space are we addressing? What problems are we out to
solve? How can we bound the problem domain with narrow enough scope
that something useful can be delivered within an acceptable
time-frame?

This effort is driven by a desire to advance the current state of
deployed network management solutions, particularly in the area of
configuration management and provisioning. This advancement must
solve practical problems and address real-world environments.

The best path is a building block approach. Assemble the right blocks
in the right order to allow progress and visible, demonstrable
functionality. Declare a direction, sketch out the plan, ponder the
glorious future, sure, but get some rubber on the road.

The simplest solution space to target is getting full and partial
configurations from a provider configuration database to the
device. At the simplest end of this space is simple archival and
restoration. At the complex end is provisioning requests triggered by
database changes (change a link) or network events (customer
login/out).

Proposal: Set our bounds as follows:

 Provider oriented:
  - Don't do something that blocks the management of VCRs, but
    don't hobble the effort with too broad a target problem domain.

 Automation oriented:
  - Network management requires quality network management
    applications, which require device support for automation.

 Aim for the 'back end' technology:
 - Define a reasonable infrastructure (databases, NOCs, call centers,
   etc). Detail simple requirements for this infrastructure,
   but place it outside the immediate product of the effort.
 - Work on the back end: getting data to and from the device.

** Content

There seem to be three schools of thought regarding content. One
school wants to leverage the standard information defined in existing
MIBs. The second envisions a mix of standard data augmented by
vendor-specific data. The third sees the device as communicating with
vendor-specific content, with management scripts doing the conversion
between vendor-neutral and vendor-specific data.

The first camp is mostly snmp-in-xml, which will have many of
the same problems that are currently affecting SNMP.

    <ifEntry ifIndex="1">
      <ifDescr>POS2/0</ifDescr>
      <ifType>ppp</ifType>
      <ifMtu>4470</ifMtu>
      <ifSpeed>155000000</ifSpeed>
      <ifAdminStatus>up</ifAdminStatus>
      <ifOperStatus>up</ifOperStatus>
      ...
    </ifEntry>

The second camp suffers from the same problem SNMP has, where a
posthumous MIB will not gain enough momentum to overcome deployed
vendor-specific solutions. The model for MIB creation remains a
problem. 

    <bgp>
      <peer name="10.1.2.3">
        <generic-config/>
        <v1:vendor-specific>...config...</v1:vendor-specific>
        <v2:vendor-specific>...config...</v2:vendor-specific>
      </peer>
    </bgp>

Another problem comes when an application wants to discover which
parts of a standard is supported by any particular device. 

I'm squarely in the third camp, since getting exact information on and
off the device increases the power of management applications,
simplifies the on-device requirements, lowers the costs of processing
the information, and allows timely implementation in the API of new
features.

Eliot said it well in draft-lear-config-issues:

  "It remains unproven that configuration information could be
  sufficiently divorced from implementation that complex configuration
  tasks can in fact be standardized."

Abstractions are important for modeling and monitoring, but in
configuration, the devil is in the details.  Configuring concrete
configuration through an abstract model requires knowledge of both the
abstract and the concrete. An excellent abstract is also required, but
the more generic and extensible the abstract is, the more difficult it
becomes to deal with.

One of the prime motivations for screen scraping is the wealth of data
available in the CLI that is not exposed in SNMP. The API must expose
as much information as possible in as timely a manner as possible,
preferably in the release in which it ships.

New features should not languish for lack of network management
support. Syntax and some degree of semantic information can be
published by the vendor in an XML Schema, where an application can at
least display it hierarchically. More importantly, the syntax can be
exposed to rules engines and used to check data destined for the
device.

Proposal: Start with vendor-specific content for configuration.
Proposal: Explore using namespaces to allow mixing of standard and
vendor-specific content, especially for operational content.

** Encoding Conventions

This area is meant to address questions related to how content is
encoded in XML. As a general technology, XML offers numerous
mechanisms for doing similar tasks. In a particular problem domain,
some choices are more appropriate than others.

*** Attributes versus Elements

One topic of debate in the XML community is the design choice of
attributes versus elements. The distinctions are minor, but can be
problematic.

Elements:
- contain attributes and elements in a hierarchy
- have order
- can appear multiple times within the same parent
- support namespaces
- can be expanded over time (new contents)

Attributes:
- have string contents
- have no order
- can appear at most once in any element
- are not fully integrated into namespaces (see below)
- cannot be expanded

A common rule of thumb is that something can be encoded in an
attribute if the name/value will never, ever, ever be expanded.
But how can one know this for certain?

Discussions on this point can be found at:

http://xml.coverpages.org/elementsAndAttrs.html
http://www.intelligenteai.com/XMLRepository/elements_versus_attributes.htm

Proposal: Don't use attributes where flexibility or exactness is
required, or where the content might expand or change forms in future
revisions.
Proposal: Use the attribute/element distinct in a well-defined way.

*** Mixed Content

http://www.w3.org/TR/REC-xml#sec-mixed-content defines mixed content as:

  An element type has mixed content when elements of that type may
  contain character data, optionally interspersed with child elements.

And adds:

  In this case, the types of the child elements may be constrained, but
  not their order or their number of occurrences.

Use of mixed content restricts the amount of specificity that can be
used in XML Schemas, and mixed content is generally less useful in the
realm of data content (versus generic documents).

Proposal: Mixed content should not be used.

*** Namespaces

One of the troubling spots for XML is the use of
namespaces. Namespaces provide a mechanism for scoping elements by
qualifying them with a prefix associated for a unique URI.

The chief problem with namespaces is that they were retrofitted on top
of XML without being fully incorporated into the XML spec. This
required that namespaces could not break the existing rules including
those of DTDs. This restriction in turn required that attributes not
be allowed to switch to the default namespace, as elements do.

  <?xml version="1.0"?>
  <!--
   - Each XML document contains exactly one top level element.
   - This element is in the default namespace.
   -->
  <outer>

    <!-- 
     - Use the 'xmlns' attribute to define new namespaces in one of
     - two ways. xmlns:prefix="uri" defines a mapping between the
     - unique uri and the local shorthand prefix.  This prefix can
     - then (beginning with the current element) be used to qualify
     - elements into this distinct namespace.
     -->
    <foo:one xmlns:foo="foo-uri">

      <!--
       - Unqualified elements remain in the default namespace.
       -->
      <two/>

      <!--
       - The second form of namespace definition affects the default
       - namespace. xmlns="uri" changes the default namespace for
       - the current element and all elements it contains.
       -->
      <three xmlns="goo-uri">

        <!--
         - Unqualified elements are now in the "goo-uri" namespace.
         -->
        <four/>

        <!--
         - Unqualified attributes remain in the default namespace.
         -->
        <five uno="This is in the default namespace, not goo"/>

        <!--
         - To refer to attributes in the current namespace,
         - attributes must be qualified with the prefix for
         - the current namespace.
         -->
        <six foo:dos="This one is qualified in the foo ns"/>
      </three>
    </foo:one>
  </outer>

The difference in behavior between elements and attributes here is
disturbing.

One easy mechanism for dealing with this inconsistency is to avoid the
use of unqualified attributes, either by always qualifying them or by
avoiding attributes wherever possible.

On the other hand, when dealing with a stream of SAX events, it is
often advantageous to use attributes, since the attributes are
delivered with the start element. This reduces the statefulness of
the associated software and hence the reliability of the system.

Proposal: Attributes should be used sparingly, especially where
their content has the possibility of expanding.
Proposal: Attributes should always be qualified.

*** Versioning

There are two versioning requirements, one for the protocol and one
for the contents. XML documents are commonly versioned using a
"version" attribute on the top-level element. Content versioning is
commonly done by placing a date or version string in the namespace
string: 

  <?xml version="1.0"?>
  <xsl:stylesheet version="1.0"
                  xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
                  xmlns:smil="http://www.w3.org/2001/SMIL20/";>
    <!-- ... -->
  </xsl:stylesheet>

This snippet uses both styles of versioning. The "version" attribute
identifies the version of the stylesheet, while the namespace
'xsl' is mapped to the specific namespace URI for this version of the
XSLT specification, which uses the year as a discriminator. The SMIL
2.0 specification uses the version ("SMIL20") as its discriminator.

Attributes are useful for applications that are not namespace aware,
but these are disappearing. Namespaces are useful, but require exact
matches.

Proposal: Use namespaces for versioning both protocol and content.

*** Lists

Two types of list: ordered (where the order matters) and unordered
(where it does not). Traditionally lists were
left in the order supplied, but this makes individual manipulation of
list elements difficult. While ordered lists use the order of creation
as an initial order, operations should exist to adjust the
order. Unordered lists can be either left in their initial order or
sort by a key, making human and programmatic access simpler.

*** Naming of Instances

A naming scheme is required to discriminate between multiple instances
of the same data type.

For example two users are identified by their user names, but how is
this information encoded and referenced?

  <!-- Identifier as attribute -->
  <user name="foo">
    <!-- configuration for user 'foo' -->
  </user>
  <user name="bar">
    <!-- configuration for user 'bar' -->
  </user>

  <!-- Identifier as element -->
  <user>
    <name>foo</name>
    <!-- configuration for user 'foo' -->
  </user>
  <user>
    <name>bar</name>
    <!-- configuration for user 'bar' -->
  </user>

The first example looks fine, but since attributes do not follow
namespace scoping unless explicitly prefixed, it should look like:

  <!-- Identifier as qualified attribute -->
  <user v1:name="foo">
    <!-- configuration for user 'foo' -->
  </user>
  <user v1:name="bar">
    <!-- configuration for user 'bar' -->
  </user>

A related issue is whether a containing element is required for lists:

  <users>
    <user>
      <name>foo</name>
      <!-- configuration for user 'foo' -->
    </user>
    <user>
      <name>bar</name>
      <!-- configuration for user 'bar' -->
    </user>
  </users>

This makes more verbose XPath expressions:

  protocols/bgp/groups/group[name="foo"]/peers/peer[name="10.1.2.3"]

(This expression would need namespace prefixes also.)

On the other hand, having these sorts of containers make it easier to
perform operations like replacing all peers, users, etc.

Proposal: Encode identifiers as attributes.
Proposal: Use container elements for lists.

** Operations

The basic operations required are:

- Get Configuration
  - Full
  - Partial
- Load Configuration
  - Full
  - Partial
    - Merge
    - Replace
- Locking 
  - Lock
  - Unlock
- Rollback
- Commit
  - Confirmed

Plus access to operational information. 

Proposal: Take the above as a short list. Add to it.

** RPC Technology

The choice of RPC technology is painful. The main contenders are all
lacking in one or more important facets. Let's make a quick survey:

XMLRPC:
 PRO: simple
 CON: mixes schema information into the RPC content

SOAP:
 PRO: common
 CON: thick and growing spec, lack of standard "literalxml" encodingStyle,
      uses HTTP as tunnel, hitched to Web Services wagon

BEEP:
 PRO: simple, multi-channel, long-lived connection, profiles,
      chunking, use in other RFCs
 CON: lack of market-share, green implementations

Custom/New:
 PRO: you get what you want
 CON: no one else gets it

In addition, both XMLRPC and SOAP are normally short-lived
connections, making session management and failure recovery more
difficult than long-lived connections.

BEEP has a number of interesting characteristics and seems like a
natural match for XMLCONF.

Proposal: Develop a BEEP Profile for XMLCONF.

** Security/AAA

Many issues in the area of security are controlled by the choice of
RPC technology. For example, BEEP profiles can include TLS
bindings/requirements.

The larger issue of AAA does not need an exhaustive model. All devices
include native support for AAA on traditional terminal-oriented CLI
access methods. XMLCONF could simply build on these existing native
AAA implementations and their existing supporting infrastructure.

Proposal: Leverage existing CLI AAA mechanisms by defining login RPC
that passes user name and authentication credentials (password, etc)
to existing login modules.

** Session Management

Session management is required if XMLCONF is to support locking and
transactions. The simplest form binds the lock to the connection. This
leads to simple, deterministic session failure and recovery scenarios.

Proposal: Use a long-lived connection-oriented transport protocol.

** Transport Protocol

The key issues for the choice of transport protocol are:

- Security
- Connection-oriented?
- Longevity
- Overhead
- Availability/Support

One important scenario is when the device is accessed via the console
port. The console can be accessed directly through a serial cable
attached to a laptop or hand-held computer, or via a terminal server
attached to an out-of-band management network.

The two main transport protocols are HTTP and BEEP. HTTP is normally
used over port 80, which HTTP-ophiles like because it defeats
firewalls. This is not an attractive quality in a management
protocol. HTTP could be run on a different port, which would allow
firewalls to detect and handle the protocol correctly. As SOAP
deployment increases, firewalls will likely gain SOAP-specific
capabilities. This may or may not be good news.

BEEP is a framing protocol, but does not define a standard port. Any
management protocol using BEEP would define its own port.

Proposal: Use BEEP.
Proposal: Define a mechanism to use BEEP over a console port.

--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>