RE: Charter items

[Ron Bonica <Ronald.P.Bonica@wcom.com>]

Ran,

We agree regarding security. We disagree regarding SMI and management
information. I think that we disagree because there are several problems
that need to be solved. The Ens draft solves a few problems, but not the
ones that cause me the most pain.

If we were to standardize a few small chunks of configuration and state
information, we could convince ourselves that the worst problems can be
solved within the context of XMLCONF. I'm not saying that this working group
should translate every MIB ever developed by the IETF. Maybe we should limit
the effort to codifying the configuration and state data that currently
resides in the MIB-II ifTable. It should also document best practices for
defining XML configuration and state data.

                                                      Ron



> -----Original Message-----
> From: RJ Atkinson [mailto:rja@extremenetworks.com]
> Sent: Friday, March 28, 2003 10:56 AM
> To: Ron Bonica
> Cc: xmlconf@ops.ietf.org
> Subject: Re: Charter items
>
>
>
> On Friday, Mar 28, 2003, at 10:35 America/Montreal, Ron Bonica wrote:
> > It seems that
> > three more work items are before us. These are:
> >
> > 1) adopt or create a structure of management information (as did RFC
> > 1155)
> > 2) codify some very basic management information (as did RFC 1213)
> > 3) define a security model and invite security experts to crawl all
> > over it
> >
> > Comments?
>
> I think that (1) and (2) are premature at this time.  Lets sort out the
> protocol mechanism for moving blocks of config gorp around first, see if
> that turns out to be usable by operators, then take on more work once
> we've
> got some actual experience with that.
>
> As to (3), my previous note was trying to suggest that we at least try
> to get someone from the Security Directorate assigned to provide
> (informal
> for now) early guidance on security matters.  I'd guess that if mrw or
> someone were to ask smb or rhousley, they'd be happy to try to identify
> someone to help (informally for now; formally iff a WG were formed in
> future).
>
> IETF WGs often have real problems with "mission creep" and consequent
> lack
> of focus.  Lets please not repeat that common error here.  Instead,
> lets work
> on one thing at a time, in a reasonable sequence, rather than trying to
> design
> the panacea protocol all at once.
>
> If we could just replace screen-scraping (Tcl/Expect) with the Enns'
> draft
> approach, that would be a big leap forward for a lot of
> end-users/operators.
> After that is sorted out, then moving on to additional stuff (which
> stuff
> being TBD until then) might be eminently sensible.
>
> [And I'd still prefer to publish the Enns' I-D right away as
> Experimental RFC,
> so there is a stable spec for folks to experiment with, proceeding with
> any
> standardisation work only after that is out as Experimental RFC.  This
> is how
> the older (usually more successful) IETF worked.  And that approach
> seems
> to have been a lot more successful than the current "standardise before
> we have adequate operational experience" approach has been.  And
> publishing
> the Enns' I-D as Experimental does not even require us to wait for a WG
> to be formally created, so it can really be done right now, rather than
> after a few months.]
>
> IMHO,
>
> Ran
> rja@extremenetworks.com
>
>
>


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