Re: none

[Scott Lawrence <scott-xmlconf@skrb.org>]

Margaret Wasserman <mrw@windriver.com> writes:

> A number of us have drafted a proposal for an XML-based
> configuration protocol that can be found at:
> 
> http://www.ietf.org/internet-drafts/draft-enns-xmlconf-spec-00.txt
> 
> Please feel free to comment to the authors or to this
> list.

Overall, a very interesting proposal, and though I don't at present
expect to be able to attend in San Francisco, I think a BOF would be a
good idea.

My initial comments on the draft itself:

==

  An organizational suggestion: I'd move the description of
  capabilities (how they are named and the capability exchange) closer
  to the front, along with the definition of the initial handshake on
  the management channel.  I think this would make the overall
  management model clearer and make it easier to discuss how
  capabilities affect other elements in the rest of the document.

== 

  Several examples include empty elements using as an empty element
  <foo/>, but Canonical XML [RFC 3076] requires that they be expressed
  as a start/end element pair <foo></foo>.  

  Personally, I think either should be allowed and that a requirement
  that both MUST be supported by a receiver would be reasonable, but
  one could also make the case that it's easier to just use 3076 to
  the letter.

==

  In a few elements, the attribute name 'id' is used to associate the
  element with some earlier element that had the same value for it's
  'id' (as in the elements <rpc id='x'> and <rpc-abort id='x'>).  I
  think that it would be better to reserve 'id' to always identify the
  element itself, and use a different attribute to refer to it.   So,
  for example, correct usage would be:
       <rpc id='x'> ...
       <rpc-abort target='x'> ... 
  where the 'target' attribute identifies the rpc element whose id has
  the same value.  

==

  Misuse of xmlns 

  In the definition of the config element used in the get-config
  operation (and perhaps elsewhere), the examples misuse the xmlns
  attribute.  In this one:

     <rpc id="101" xmlns="http://ietf.org/xmlconf/1.0/base";>
       <get-config>
         ...
         <config xmlns="http://example.com/schema/1.2/config";>
           <users></users>
         </config>
         ...

  the 'xmlns' attribute modifies the namespace of the config element
  itself, not just that of its contained elements, which is not what
  you meant, I think.  I think that it should be either:
   
     <rpc id="101" xmlns="http://ietf.org/xmlconf/1.0/base";>
       <get-config>
         ...
         <config foo:xmlns="http://example.com/schema/1.2/config";>
           <foo:users></foo:users>
         </config>
         ...
 
  or
    
     <rpc id="101" xmlns="http://ietf.org/xmlconf/1.0/base";>
       <get-config>
         ...
         <config>
           <users xmlns="http://example.com/schema/1.2/config";></users>
         </config>
         ...
 
==

  Section 2.2 Security and Privacy

  The term "security" as used here is not precise enough.  I think
  that what you mean to say in this paragraph is something like:

   The transport used to carry XMLCONF must provide the appropriate
   level of integrity and confidentiality protection.  For example,
   connections may be encrypted in TLS [4] (or SSH [11]) depending on
   the underlying protocol.

  I would suggest adding an explicit indication by which an XMLCONF
  implementation may indicate to a peer that the underlying transport
  does not provide the level of protection which its own policy
  requires (this might take the form of some indication in the
  greeting message that additional profiles may be available using a
  more secure transport).  

== 

  Section 2.3 should be titled "Authentication and Access Control",
  since it discussed both; access control is not part of
  authentication. 

==

  Section 3.2 <rpc> says:

    The <rpc> operation has an optional attribute "id".  The "id"
    attribute is an arbitrary string chosen by the sender of the RPC.
    This will commonly encode a monotonically increasing integer.  The
    receiver of the RPC doesn't decode or interpret this string but
    simply saves it to use as an "id" attribute in any resulting
    <rpc-reply>, <rpc-abort-reply> or <rpc-progress> messages.

  I find that in specs, statements like "This will commonly ..." are
  often misinterpreted as being prescriptive, and that if you really
  want to ensure that the value is treated as opaque, then it is best
  not to suggest a means of constructing it.  I would leave this out,
  or at least move it to after the sentence which follows and
  incorporate it into the introduction of the example: "In the
  following example, the implementor has chosen to use a monotonically
  increasing integer to construct id values..."

==

  Section 3.4 <rpc-abort> says:

     The <rpc-abort> operation is encoded as an element with no
     subelements or data. 

  Better to just say that the rpc-abort element is defined to be EMPTY
  (and include a reference to EMPTY as a keyword, using the definition
  from XML Schema).

  With respect to responses to this element, the draft says:

    If there is no pending operation matching the "id" attribute, then
    the abort operation completes without error.   

  I don't like the indeterminacy of that - I would prefer to have a
  way to respond that indicate the server could not find an
  outstanding rpc with a matching id.  This shouldn't be fatal, but
  lets the client know that it may have an internal error in its
  operation tracking.  I guess I'd rather see <rpc-abort-reply>
  defined to contain either an 'ok' or an 'rpc-error' element.

-- 
Scott Lawrence        
  Actively seeking work 

  http://world.std.com/~lawrence/    [<lawrence@world.std.com> is deprecated]


--
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/>