RE: Charter items

["Allen, Keith" <kallen@tri.sbc.com>]

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?

RJ Atkinson wrote:
> 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.

My concern is that the protocol work alone won't be enough to allow support
tools to begin to emerge.  For example, just having the SNMP protocol
specification without SMI wasn't really enough to begin developing good
support tools.  I think you at least have to know that OIDs are going to be
used to identify the data upon which the protocol is going to operate, even
if you don't know what the OIDs are or what they represent.

If company A decides they are going to use OIDs in their XML schema, and
company B decides they are going to use URLs, and company C decides they are
going to use something else, can one toolkit support all of these
approaches?

The examples in the slides presented at the BOF used XML tags with an
attributed called "Name" to identify the data upon which the protocol
operated.  Is that convention going to be codified into a standard?  I am
particularly concerned about naming rules, as I think this issue will
consume roughly half of the time of the group.  Still, I think it is
necessary to nail this down before tools can emerge.  With just a protocol,
I think you'll have to do a lot of custom coding.  Is this the experience we
want, or do we also want some experience with tools?

Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com
 

-----Original Message-----
From: RJ Atkinson [mailto:rja@extremenetworks.com] 
Sent: Friday, March 28, 2003 9: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/>

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