RE: Re: [MIB-DOCTORS] OPS Area BOFs in Prague
"Natale, Bob" <[email protected]> Wed, 20 Dec 2006 14:23:26 -0500
| Newsgroups | gmane.ietf.ops,gmane.ietf.ops-nm |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected]]=20 Sent: Wednesday, December 20, 2006 2:10 PM To: David B Harrington Cc: [email protected]; [email protected]; 'MIB Doctors'; 'DNS Directorate'; 'IESG'; [email protected]; [email protected] Subject: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague David B Harrington wrote: > Hi, >=20 > Please respond only to the OPS-area mailing list. >=20 > I would like to raise three potential areas of discussion. These may > be suitable for BOFs or mini-BOFs. >=20 > 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.=20 I think such a documentation project could be a lot of work. If there were enough participation, it would be very useful. >=20 > 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.=20 >=20 > 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. >=20 > 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. >=20 > 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.=20 >=20 > 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. >=20 > 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. >=20 > Obviously, this would benefit from the discussions of #1 and #2. >=20 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=20 Andy _______________________________________________ OPS-AREA mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ OPS-AREA mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ops-area