xmlconf-spec-01 comments

[Wes Hardaker <wjhns1@hardakers.net>]

First off, let me start by saying this is one of the better written
IETF documents that I've ever read.  It's well thought out, stated,
organized and the extensive use of examples are wonderful! 

These comments are in reference to the previous version of the
document, but I don't think the changes since then were extensive in
these areas.  I'm sure the authors will correct me if I'm wrong ;-)

- Section 2.2 on Security and Privacy say that connections must
  provide "security" and privacy.  "security" is a very very vague
  term and is not suitable in this case to define anything concrete
  (for one thing, it means different things to different people).
  What is it that you're really trying to say here?  Authenticated
  connections?  Integrity protected connections?  You've already
  covered privacy, so...

- Also note that it's still illegal (I believe) in some countries to
  use and/or export products that enable encryption.  You should be
  careful when using the word 'MUST' in the future (it currently
  doesn't use capitalized terms)

- last p of section 2.3: So authorization must happen in a
  vendor-specific manner, possibly in addition to a standards-based
  manner (to be defined later).  What if the xmlconf session over some
  protocol X doesn't map to an internal user as the vendor had them
  defined?  This seems to bring on the requirement that all
  authentication mechanisms must map a connection to a real internal
  (vendor-specific) user?

- 3.1, 3.4: rpc-aborts on a given, non-unique, message-id will cause
  non-deterministic behavior.  3.4 states that the first request is
  aborted, but this isn't sufficient since the first request may have
  terminated at an agent before the manager receives the rpc-reply for
  the first then the second will be terminated when the manager
  expected the first.  How about just making the requirements that
  managers MUST send unique message-ids for all outstanding requests
  (IE, they can reuse strings iff [sic] they've received a response
  for a reused string already).

- 5.6: when a session is killed, is anything sent to the session that
  is being killed before it dies?  IE, to let the open session know
  why its being killed?  Also, I hope the session-id is always unique
  and picked by the managed device?  I probably missed this somewhere
  and don't have time to go search at the moment.


- locking: the way locking is done now, it locks all objects
  regardless of whether the user has access rights to a give object.
  This gives a great denial of service attack.  A bad user, eg:
  recently fired, can merely lock the configuration of all the routers
  and administrators would be unable to delete the user from the user
  base.  They can, of course, kill the session of the user and thus
  the lock, but the user could have easily written a script to
  immediately reconnect and/or relock and thus a race-condition would
  ensue.  To fix this, you would either need to make locks only lock
  objects for which permission was allowed to be modified, provide
  more granular locking, or to disallow locking entirely for a user
  that doesn't have global write privileges.

nits:

- The introduction states the contents of both the request and the
  response are fully described in XML DTDs, which is not true if text
  [vendor specific] transmission is being used.

- 3.1 Namespace: you should document (and decide) who controls the
      namespace in question.  IANA?

- 3.6:  - errors can also be sent in rpc-abort-reply messages.
        - edit-path probably should have its format described better.
- 3.8: using a percentage of time is hard to calculate and thus
  expensive.  I'd suggest a percentage of work load instead.
- 3.8: amount of work load out of what?  what are the units?  Just an
  amount by itself is useless unless the management app knowns what
  the amount corresponds to...  is it amount of the request text that
  has been processed?  amount of data being churned? amount of...
- 3.9: pipelining as is could be more efficient if the order of the
  responses were allowed to be returned in arbitrary order rather than
  strictly by the order sent.  If two non-conflicting requests (say
  "get" based)  were being processed at once, then the easier response
  could be returned first.  Ask me in person, sometime, how we do this
  today within the Net-SNMP SNMP agent.  Note that write-operations
  can't frequently be done in parallel, of course.
  (note that clients must check the message-id anyway in case of a
  broken agent or transport).
- 5.3 example: is "url" in the namespace in question?  I think it's in
      a different one, no?
- 6.1: you should state something about closing connections after N
  seconds of no input from the other side.  Same for 6.3.
- 6.3.4.1: confirmed-timeout should be specified in seconds, not
  minutes, for better granularity.
- 6.3.4.1: I suggest adding a "commit-at-time" optional parameter for
  doing synchronized commits across multiple devices.  IE, tell all
  devices to commit at a particular time (or at least seconds from now
  so a device doesn't need a synchronized clock)
- 6.3.5.1: locking a "target" to me makes more sense than the use of
  the word "source".


I have some more thoughts and concerns, but I'm out of time for the moment.  

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

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