[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review: IESG Agenda and Package for January 22, 2004 Telechat
- To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
- Subject: Re: Review: IESG Agenda and Package for January 22, 2004 Telechat
- From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
- Date: Thu, 22 Jan 2004 13:55:38 +0100
- Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Mreview (E-mail)" <mreview@ops.ietf.org>, ops-area@ops.ietf.org
- In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B1550362BE2C@nl0006exch001u.nl.lucent.com>
- Mail-followup-to: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Mreview (E-mail)" <mreview@ops.ietf.org>, ops-area@ops.ietf.org
- References: <7D5D48D2CAA3D84C813F5B154F43B1550362BE2C@nl0006exch001u.nl.lucent.com>
- Reply-to: j.schoenwaelder@iu-bremen.de
- User-agent: Mutt/1.5.5.1+cvs20040105i
On Wed, Jan 21, 2004 at 03:11:34PM +0100, Wijnen, Bert (Bert) wrote:
> > To what extent is this document
> > (http://www.ietf.cnri.reston.va.us/internet-drafts/draft-jones
> > -opsec-03.txt - on the IESG agenda tomorrow) known and was it
> > reviewed in the Operations and Management Area?
>
> Well, it went through a 4-week IETF Last Call, so everyone in IETF
> should/could have seen it.
>
> It has been reviewed on OPS-Directorate list, and we are evaluating
> feedback we received through that path.
>
> And of course, my posting of the IESG agenda to the MIB Doctors list
> enocurages the OPS NM folk to review documents from a NM perspective.
The recent discussion made me read the document yesterday evening and
I basically like it (even though one can of course argue that some
items do belong into other places or that other items are missing).
I think Dan is quite right in what he wrote. But even in its current
form, I think the document is very valuable.
With my SNMP background, I was of course puzzled about the requirement
to be able to reset counters. I would personally like to have one or
two sentences added that such a reset means the display of counters
in e.g. a CLI interface but not necessarily the reset of the real
physical counters. (In other words, I expect that the CLI takes a
snapshot of a counter C at time t and then later displays C(now)-C(t)
on the CLI or whatever interface (this is basically what a management
application running on top of SNMP would do).)
Below are the other comments I wrote down last night - most of them
(except the one referring to page 38) are purely editorial and may
have already been observed by others.
Page 15: RS2323 -> RS232
Page 16: I am not really sure that RS 232 interfaces do not need additional
software. In fact, without a modem/terminal program, using RS 232
interfaces is kind of hard (of course depends on your OS).
Page 26: The following sentence does not read well: "This requirement makes
it possible restrict access to management services using routing."
Page 29: "support to to rate-limit" -> "support to rate-limit"
Page 36: Reset of counter requirement should probably explain how this
relates to SNMP. I hope the idea is that the displayed counter
is reset, not the real counter underneath it.
Page 38: The warning concerning syslog are interesting and the current
best solution concerns me (since it just says that there is no
deployable secure syslog solution at the moment, more than two
years after publication of RFC 3195). This should probably make
the IESG think about the question whether RFC 3195 is going to
be the right solution...
Page 41: "... the address a reliable for ..." ->
"... the address reliable for ..."
Page 51: "... will may leave the operator ..." ->
"... may leave the operator ..."
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany