[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-farrel-rtg-manageability-requirements-00.txt
Wednesday, November 10, 2004, 11:37:03 AM, Andy Bierman wrote:
> At 08:17 AM 11/7/2004, Wijnen, Bert (Bert) wrote:
>>[not sure if authors/and alex are on ops-area list, so I cc: them]
>>It is an interesting read.
> This is more than interesting -- it is fundamental to the
> success of network management standardization in the IETF.
I have to admit that while I see the potential value in this, I'm less
enthusiastic about it. My main concern is how this will affect the role of the
IETF and the level of frustration with it (which is already considerably high)
in the routing industry. The problem is not with MIBs or configurable params,
which we already do today, but with less tangible things like affect on network
operations. The IETF doesn't operate the networks, so quite often the answer
is--implement, deploy, get the bruises, come back and see what needs to be
changed or tossed away. Of course, there are exceptions where the answer is
obvious, but I don't think it's the rule..
> All documents should have a Management Considerations section.
> IMO, it does not have to be as complete as this document
> suggests. Specifically, this section (or another) should
> document which parameters MUST/SHOULD/MAY be configurable,
> but a complete MIB (or other interface) definition should
> not be required. This can be developed in a separate document
> and a separate work effort.
>>I also know that various people think that we have too many "mandatory"
>>sections already. So how does that jive? Has the RTG community reacted
>>already? In principle I think it would be good to have sections on
>>"Considerations for managebility".
>>I then wonder, why would this just apply to the docs from the RTG area?
>>W.r.t. sect 2.2, I am not sure I understand the differene between
>>the first 2 bullets.
>>W.r.t. sect 3.x, you may want to reference RFC3444.
>>> -----Original Message-----
>>> From: Romascanu, Dan (Dan) [mailto:firstname.lastname@example.org]
>>> Sent: Tuesday, October 12, 2004 20:12
>>> To: Ops-Area (E-mail)
>>> Subject: FW: I-D
>>> believe that this Internet-Draft is worth being read and
>>> commented by the OPS area.
>>> -----Original Message-----
>>> From: email@example.com
>>> [mailto:firstname.lastname@example.org]On Behalf Of
>>> Sent: 12 October, 2004 10:05 PM
>>> To: email@example.com
>>> Subject: I-D ACTION:draft-farrel-rtg-manageability-requirements-00.txt
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories.
>>> Title : Requirements for Manageability
>>> Sections in Routing
>>> Area Drafts
>>> Author(s) : A. Farrel, et al.
>>> Filename :
>>> Pages : 6
>>> Date : 2004-10-12
>>> It has often been the case that manageability considerations have
>>> been retrofitted to protocols. This is sub-optimal.
>>> Similarly, new protocols or protocol extensions are frequently
>>> designed without due consideration of manageability requirements.
>>> This document specifies the requirement for all new Routing Area
>>> Internet-Drafts to include an "Manageability
>>> Considerations" section,
>>> and gives guidance on what that section should contain.
>>> A URL for this Internet-Draft is:
>>> To remove yourself from the I-D Announcement list, send a message to
>>> firstname.lastname@example.org with the word unsubscribe in
>>> the body of the message.
>>> You can also visit
>>to change your subscription settings.
>>Internet-Drafts are also available by anonymous FTP. Login with the username
>>"anonymous" and a password of your e-mail address. After logging in,
>>type "cd internet-drafts" and then
>> "get draft-farrel-rtg-manageability-requirements-00.txt".
>>A list of Internet-Drafts directories can be found in
>>Internet-Drafts can also be obtained by e-mail.
>>Send a message to:
>>In the body type:
>>NOTE: The mail server at ietf.org can return the document in
>> MIME-encoded form by using the "mpack" utility. To use this
>> feature, insert the command "ENCODING mime" before the "FILE"
>> command. To decode the response(s), you will need "munpack" or
>> a MIME-compliant mail reader. Different MIME-compliant mail readers
>> exhibit different behavior, especially when dealing with
>> "multipart" MIME messages (i.e. documents which have been split
>> up into multiple messages), so check your local documentation on
>> how to manipulate these messages.
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the