[OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague
"Natale, Bob" <RNATALE@mitre.org> Wed, 20 December 2006 19:23 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx72R-0002OU-0I; Wed, 20 Dec 2006 14:23:39 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx72Q-0002OD-EK; Wed, 20 Dec 2006 14:23:38 -0500
Received: from smtpproxy2.mitre.org ([192.80.55.71] helo=smtp-mclean.mitre.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gx72L-0000oI-UD; Wed, 20 Dec 2006 14:23:38 -0500
Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id kBKJNVhs013628; Wed, 20 Dec 2006 14:23:31 -0500
Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 59D4E1BD82; Wed, 20 Dec 2006 14:23:31 -0500 (EST)
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kBKJNUkR013610; Wed, 20 Dec 2006 14:23:31 -0500
Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 14:23:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 20 Dec 2006 14:23:26 -0500
Message-ID: <4915F014FDD99049A9C3A8C1B832004F017732AB@IMCSRV2.MITRE.ORG>
In-Reply-To: <45898A91.70305@andybierman.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague
Thread-Index: Acckav4kHdal9oCGSUqvFbDMNASGOAAALfew
From: "Natale, Bob" <RNATALE@mitre.org>
To: ops-nm@ietf.org, ops-area@ietf.org, nmrg@ibr.cs.tu-bs.de, IESG <iesg@ietf.org>
X-OriginalArrivalTime: 20 Dec 2006 19:23:30.0673 (UTC) FILETIME=[55225610:01C7246C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: aaa-doctors@ietf.org, MIB Doctors <mib-doctors@ietf.org>, DNS Directorate <dns-dir@ops.ietf.org>
Subject: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague
X-BeenThere: ops-nm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OPS Area NM e-mail list <ops-nm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ops-nm>, <mailto:ops-nm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ops-nm>
List-Post: <mailto:ops-nm@ietf.org>
List-Help: <mailto:ops-nm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ops-nm>, <mailto:ops-nm-request@ietf.org?subject=subscribe>
Errors-To: ops-nm-bounces@ietf.org
Hi, I strongly agree with Andy's position (from below): "IMO, to advance to Draft Standard, a protocol should meet strict manageability requirements, which would obviously need to be documented in an RFC." Cheers, BobN -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Wednesday, December 20, 2006 2:10 PM To: David B Harrington Cc: ops-nm@ietf.org; aaa-doctors@ietf.org; 'MIB Doctors'; 'DNS Directorate'; 'IESG'; nmrg@ibr.cs.tu-bs.de; ops-area@ietf.org Subject: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague David B Harrington wrote: > Hi, > > Please respond only to the OPS-area mailing list. > > I would like to raise three potential areas of discussion. These may > be suitable for BOFs or mini-BOFs. > > 1) An OpsNM BOF, designed to lead to a WG similar to the OpSec WG, to > have **operators** document how they actually manage networks today, > and to document what features they utilize in equipment today to > accomplish such management. I think such a documentation project could be a lot of work. If there were enough participation, it would be very useful. > > For example, DavidK mentioned during the last OPSarea open-office > meetings that there are three major approaches to managing service > provider networks (Motorola, ??, ??). I don't think this is documented > anyplace in IETF documents. I don't know if these approaches are > documented elsewhere. > > I don't know what they are, since my background is not SP-oriented, > which is true of many IETF NM people. As we move toward a more > SP-centric Internet, it would be helpful to get these approaches > documented in the IETF. > > 2) The IETF has limited resources to accomplish its work, and it would > be good to not waste resources trying to solve problems we think might > exist, when we could be working on the problems we know exist. > > In the OpSec WG, few enterprise equipment vendors participated. It > might be time to have a discussion of whether the IETF should simply > move to be more SP-centric, especially the IETF management protocols. > If enterprise equipment vendors do not believe it is important for > them to contribute to IETF protocol designs, then enterprise equipment > vendors (and their customers) may need to move toward an SP-centric > approach to utilize emerging/future IETF protocols. > > How do we want to focus our Operations and Management resources? Is > the IETF OPS area still relevant for operating and managing the > Internet? Should we adopt the management standards from other SDOs, or > let the other IETF areas design their own focus-appropriate management > solutions? IMO this tends to work itself out in the end. The people involved in a WG will influence its outcome, and the people not involved in a WG will not influence its outcome. Labels like Enterprise and SP are not that helpful here. Some companies have both kinds of products. > > 3) A manageability considerations BOF. There is already work being > done on manageability considerations guidelines (how to consider > manageability requirements, not a required section in all documents). > There was a lot of discussion about this in the last OPS Area open > meeting as well. This would benefit from achieving consensus from > operators and standards writers, and would probably be a good choice > for an EDU tutorial once consensus is reached. > > Obviously, this would benefit from the discussions of #1 and #2. > More documentation work. It would be useful to both RFC readers and writers, so I couldn't argue against it. I want every WG that creates a protocol to think about how operators and developers are going to securely and efficiently manage the protocol, including configuration. It should not be left as a proprietary component forever. IMO, to advance to Draft Standard, a protocol should meet strict manageability requirements, which would obviously need to be documented in an RFC. > dbh Andy _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ OPS-NM mailing list OPS-NM@ietf.org https://www1.ietf.org/mailman/listinfo/ops-nm
- [OPS-NM] OPS Area BOFs in Prague Romascanu, Dan (Dan)
- [OPS-NM] RE: [MIB-DOCTORS] OPS Area BOFs in Prague David B Harrington
- [OPS-NM] Re: [MIB-DOCTORS] OPS Area BOFs in Prague Andy Bierman
- [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Are… Natale, Bob
- RE: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS… Romascanu, Dan (Dan)
- Re: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS… Brian E Carpenter
- Re: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS… Andy Bierman
- [OPS-NM] OPS Area BOFs in Prague Romascanu, Dan (Dan)