proto-04 concerns

[Wes Hardaker <wjhns1@hardakers.net>]

[This is 1 out of 2 messages about the recent -04 document.  I tried
to separate my comments into concerns and nits, though a few of the
items due lie in gray areas.  Hopefully the split should still be
useful though.  I haven't read the appendixes nor the transport
documents recently.  Hopefully I can get through those by the
deadline, but the WG last call across both the IETF, DSOM and
Thanksgiving has made it a bit tough to read everything thoroughly]


1.1: "MUST support at least one, and MAY support more than one."  For
security I'd really rather see the MAY be a SHOULD in that sentence.

4.5: pipelining: "<rpc> request are processed serially"  This should
be a MUST.  Doing otherwise leads to indeterminate results.

section 6: I don't think this section is ready to go to the IESG yet.
It needs more review and editing.

section 6: I have a few concerns about the filtering as defined.
  1) I find it confusing that there is a subtle difference between
     selection of a particular set of values vs selecting a particular
     value.  The difference between:

       <user>
         <name/>
       <user>

     and 

       <user>
         <name>John</name>
       <user>

     Is very very subtle.  Definable, certainly, but subtle as well.
     This means people will get it wrong and get confused (especially
     for more complex examples).

  2) I don't think it's possible using the current filter system to
     select empty values.  IE, this:

       <user>
         <name><name/>
       <user>

     Will select all user's names, not a user with a blank name.
     (please don't tell me you're going to distinguish between <name/>
     and <name></name>)

  3) logical and vs logical or in selections

     In the document this example:

               <user>
                 <name>root</name>
                 <company-info/>
               </user>
               <user>
                 <name>fred</name>
                 <company-info>
                   <id/>
                 </company-info>
               </user>
               <user>
                 <name>barney</name>
                 <type>superuser</type>
                 <company-info>
                   <dept/>
                 </company-info>
               </user>

      Indicates that there is an implicit logical OR between the
      <user> tags and an implicit logical AND between the sub-tags
      (name/type in the third user selection).

      This is, again, subtle and subject to poor understanding by
      users which will lead to errors.

    One solution to some of these problems would be to separate the
    selected nodes from the value matched nodes using different
    groups.  Or add an attribute or something.  Anything that makes it
    more obvious what is going on and is desired.

7.2: default-operation: none...  "as well allowing a simple existence
     test for configuration data".  This statement should be stricken,
     IMHO.  If you want an existence test, you should write one into
     the protocol (get-config will do this now).  I don't think you
     should cobble in a feature this way.  It may be that it exists
     and can be used this way, but I don't think documenting it this
     way so it becomes officially supported practice is wise.

7.2 and others: Is it legal to specify config for non-existent
    devices.  IE, can I upload a config for a interface which I
    haven't physically inserted yet?  Or is this going to be
    implementation specific?  It should be at least mentioned one way
    or another.

7.2: I fail to see how these operations are going to work in some
  cases which I'm sure will come up in the future.  I'm going to use the
  examples enclosed in the section, but I don't think they're
  necessarily the right ones to use.  But you'll get the idea.

  The problem comes from the assumption of the data model that I'm not
  convinced will be true.  Take the case of messing with an interface.
  The examples all show various operations working on an interface named
  "Ethernet0/0", and only in the sentences above is it sort-of-mentioned
  in English text that the index when searching for things to modify are
  going to be based on the name.  There is no mention of this actually
  in the protocol.  Sure, in this particular case it is likely this may
  be the only selectable method in the resulting data model and that is
  yet to be determined and out of scope.  However, I think it is highly
  likely that we will end up with a data model(s) that will allow for
  separate indexes.  So, for the purposes of example, lets say that you
  could select an interface by address as well (very conceivable).  Is
  this legal for a replace:

               <top xmlns="http://example.com/schema/1.2/config";>
                 <interface xc:operation="replace">
                   <mtu>1500</mtu>
                   <address>
                     <name>1.2.3.4</name>
                   </address>
                 </interface>
               </top>

  Would that allow you to replace the MTU just as you would if you
  specified the name?  Or are you going to restrict data models in the
  future to only one set of unique indexes?  Can I set the MTU of all
  interfaces which are up using something like:

               <top xmlns="http://example.com/schema/1.2/config";>
                 <interface xc:operation="replace">
                   <status>up</status>
                   <mtu>1500</mtu>
                 </interface>
               </top>

  This is a solvable problem, obviously.  My only concern is that no
  where is this type of usage of the protocol discussed.  It does have
  implications on the resulting data models that are allowed to be
  defined.

  Fundamentally, this results from data to change and selectors being
  intermixed, which technically I think is a mistake (they should be
  marked by attributes or in a special section of the tree.  I'm sure
  that concept will die a horrible death and I'll get flamed for
  mentioning it.  So, let me just end by repeating: it needs
  discussion regardless if you don't want to explicitly talk about how
  to select particular values.

7.2 replace:  what happens if you replace a container with a set of
    elements (say A, B, and C) but the original object also contained
    a D element.  Does the new one get D as well, or is that nuked (I
    think is the case) if operation=replace is put on the high level
    object (as opposed to each element for A B and C).

7.3 copy from remote to remote is a "may choose not to support".  I
    think this is fundamentally a bad thing to ever allow.  netconf
    should not be a file transfer protocol.  The security issues
    surrounding such a notion haven't been discussed.  You can't
    easily specify access control rights for when you're allowed to do
    so.  It essentially lets any firewall implementing netconf (that
    implements URL to URL copying and has access to both an internal
    and external network) to be used as a transfer hole in a security
    domain.  I really think you should say that implementations MUST
    NOT support this.  It is well beyond the scope of what netconf
    should do.  It is highly suspect from a security point of view and
    will only add more work in the future as you'll have to write
    access control rights for when this is acceptable and when it is
    not and by what users.

7.3 example shows the use of ftp.  Can we use something more secure in
    the example please?

7.4: #url allows a url to appear as a delete.  doing remote file
    management using netconf is questionable at best.  From a security
    point of view, it makes me cringe.

8.8.5.1: so with #url capability supporting ftp I can force a netconf
client to remote edit files?  Is this really wise?

url summary: there are two types of urls:  local and remote.  Some
operations make sense for some of those, some for others.  Some
operations, IMHO, should not be allowed on remote types.

9: Implementators SHOULD also provide a well thought out authorization
   scheme with NETCONF.  => MUST

9: you need to discuss that global operations MUST disallow the
changing of information that an individual does not have authorization
to perform.  EG, if a user U is not allowed to configure an IP address
on an interface but someone else has configured an IP address for an
interface within the <candidate>, then the user U must not be allowed
to perform a copy-config or commit from <candidate> to <running>.

9: Similarly, you need to discuss what happens if you don't use a
lock.  Specifically, if user U1 modifies the candidate config in a way
that user U2 is not allowed to, and since U1 MUST NOT be able to
commit those changes then not using a lock could leave a system in a
state where neither U1 nor U2 can commit their changes to running.

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