RE: Where do we go from here?

[Andy Bierman <abierman@cisco.com>]

At 03:31 PM 8/9/2002 -0700, Randy Bush wrote:
>as no one else seems interested enough to play, i'll hit the ball

I don't think the XMLCONF BOF demonstrated clear consensus on any
particular issue:

  Transport: it's not clear that the group supported a single transport,
     let alone that SSH2 should be that transport
  Configuration: It's not clear that the group supported the proposal that
     a protocol dedicated to configuration management was a good idea.
     There were several comments (and 2 presentations) expressing a
     need for a comprehensive protocol that could be useful for many
     aspects of network element management.
  Starting from scratch: There were many objections to the suggestion
     that we ignore the data model currently represented in MIBs, and
     start over from scratch defining a data model in XML.  It was not
     clear that starting over with no standard data model (all proprietary)
     would be a good idea.
  Protocol operations:  It was pointed out be several people that XML is
     just a syntax, and does not solve any current problems by itself.
     Important problems such as multi-box transactions have been
     ignored by the IETF NM protocols, and these are the real problems
     preventing progress in the NM area.  Simply defining an 'SSH container'
     for proprietary configuration data, without defining a robust configuration
     protocol would not solve any real problems.

I believe XML can be useful as part of the solution.  It allows for a better
way of representing configuration data than unstructured CLI. This is
especially important for the advancement of automated procedures for
configuration management, which would benefit from the structure
and consistency of a real API, instead of screen-scraping an API
intended for humans.

I agree completely with Randy, that a comprehensive, well thought out
solution (a 10 year plan) is needed.  An ad-hoc, quick-and-dirty, incremental
approach to NM standards in the IETF has not worked, and will never work.
The old plan, based on SNMP, is not working.  It's time to update the plan.

Andy



>> Do we need multiple channels to each device ? Say a data channel and a
>> command channel
>
>please explain the difference between data and commands, maybe by
>example.  i.e. i suspect some folk think the entire model will be
>encoded in a single stream/file/whateveryoucallit.  and i fear that
>much confusion is thereby caused.  so it would be good to further
>expose this part of the discussion.
>
>> Do we need sequence numbers ?
>
>sequences of what?  i.e. numbers to uniquify what?
>
>> Do we need retires ?
>
>do you mean does the transport have to be reliable?  if it does, we
>have pretty standard ways of doing reliable transports.  and i
>think they use retries among 42 other transport trix.  i hope we
>don't have to reinvent this.
>
>> Security
>> All this needs to be done securely
>
>whatever that means.  that's kinda like "it has to be done well"
>
>> Is it good enough to have trusted domains between the server &
>> the client, or must each and every command be authorized by the
>> end user.
>
>i don't think we have yet clearly defined the identities in the
>authorization model.
>
>> Do we need to authenticate each and every packet
>> How do we authenticate the server and client
>
>> Do we care about certificates
>
>certificates are merely a tool to accomplish some goals which have
>not yet been clearly specified or agreed.  so this question is not
>answerable.
>
>and what are the privacy requirements?  i.e. must data be protected
>in transport?
>
>> There is work that needs to do be done in this area. Either the
>> IETF does it or other groups will.
>
>i hope i am not supposed to feel threatened by such statements.  i
>care that it is done well.
>
>randy
>
>
>--
>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/> 


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