Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBLG1J1Q002143 for ; Thu, 21 Dec 2006 17:01:25 +0100 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id kBLG1HVm012857 for ; Thu, 21 Dec 2006 11:01:18 -0500 Received: (qmail 2994 invoked by uid 78); 21 Dec 2006 16:01:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 21 Dec 2006 16:01:16 -0000 Message-ID: <458AB03E.9010907@andybierman.com> Date: Thu, 21 Dec 2006 08:03:10 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Brian E Carpenter References: <458A8C0C.3020805@zurich.ibm.com> In-Reply-To: <458A8C0C.3020805@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: ops-nm@ietf.org, aaa-doctors@ietf.org, MIB Doctors , DNS Directorate , "Romascanu, Dan \(Dan\)" , IESG , nmrg@ibr.cs.tu-bs.de, ops-area@ietf.org Subject: [nmrg] Re: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 16:01:30 -0000 Brian E Carpenter wrote: > I think Dan has it right, as far as a practical first step is concerned. > It's far from clear that we have IETF consensus for anything stronger > than guidance, but guidance is certainly needed. > Agreed -- it is just my opinion that Draft Standard should actually stand for something objectively useful. But that is a different thread which has certainly been discussed at length already. > Brian Andy Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBLDSq98018639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Dec 2006 14:29:06 +0100 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBLDSkcx084586 for ; Thu, 21 Dec 2006 13:28:46 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBLDSkkb2736294 for ; Thu, 21 Dec 2006 14:28:46 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBLDSjHc000499 for ; Thu, 21 Dec 2006 14:28:45 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBLDSiCA000469; Thu, 21 Dec 2006 14:28:45 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA116486; Thu, 21 Dec 2006 14:28:43 +0100 Message-ID: <458A8C0C.3020805@zurich.ibm.com> Date: Thu, 21 Dec 2006 14:28:44 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: ops-nm@ietf.org, aaa-doctors@ietf.org, MIB Doctors , DNS Directorate , "Natale, Bob" , IESG , nmrg@ibr.cs.tu-bs.de, ops-area@ietf.org Subject: [nmrg] Re: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 13:29:08 -0000 I think Dan has it right, as far as a practical first step is concerned. It's far from clear that we have IETF consensus for anything stronger than guidance, but guidance is certainly needed. Brian Romascanu, Dan (Dan) wrote: > I am not in the position to disagree :-) > > We need however to start from something. This 'something' is in my > opinion a document to guide IETF authors in writing manageability and > operational requirements in their protocol documents. Today in the > absence of such a reference I encounter huge problems in my role of Area > Director when I come and say 'we cannot approve this new protocol > because it says nothing about how it will be managed or what impact it > will have in the operation of the network'. The typical answers are 'who > says it needs to say something about management and operations?' or > 'what is the reference for what we need to include about manageability > and operations'? > > Dan > > > > > > >>-----Original Message----- >>From: Natale, Bob [mailto:RNATALE@mitre.org] >>Sent: Wednesday, December 20, 2006 9:23 PM >>To: ops-nm@ietf.org; ops-area@ietf.org; nmrg@ibr.cs.tu-bs.de; IESG >>Cc: aaa-doctors@ietf.org; MIB Doctors; DNS Directorate >>Subject: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area >>BOFs in Prague >> >> >>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 >> > > > Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBLC2gbG010430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 21 Dec 2006 13:02:48 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBLC2d1G007752 for ; Thu, 21 Dec 2006 07:02:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Dec 2006 14:02:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague Thread-Index: Acckav4kHdal9oCGSUqvFbDMNASGOAAALfewACLaaKA= From: "Romascanu, Dan \(Dan\)" To: "Natale, Bob" , , , , "IESG" X-Scanner: InterScan AntiVirus for Sendmail X-IBRFilter-SpamReport: 1 (*) BAYES_60 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id kBLC2gbG010430 Cc: aaa-doctors@ietf.org, MIB Doctors , DNS Directorate Subject: [nmrg] RE: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 12:02:50 -0000 I am not in the position to disagree :-) We need however to start from something. This 'something' is in my opinion a document to guide IETF authors in writing manageability and operational requirements in their protocol documents. Today in the absence of such a reference I encounter huge problems in my role of Area Director when I come and say 'we cannot approve this new protocol because it says nothing about how it will be managed or what impact it will have in the operation of the network'. The typical answers are 'who says it needs to say something about management and operations?' or 'what is the reference for what we need to include about manageability and operations'? Dan > -----Original Message----- > From: Natale, Bob [mailto:RNATALE@mitre.org] > Sent: Wednesday, December 20, 2006 9:23 PM > To: ops-nm@ietf.org; ops-area@ietf.org; nmrg@ibr.cs.tu-bs.de; IESG > Cc: aaa-doctors@ietf.org; MIB Doctors; DNS Directorate > Subject: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area > BOFs in Prague > > > 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 > Received: from smtp-mclean.mitre.org (smtpproxy2.mitre.org [192.80.55.71]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBKJNVIe020778 for ; Wed, 20 Dec 2006 20:23:37 +0100 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 kBKJNVH5013622 for ; 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 1D2021BD7A for ; 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" 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" To: , , , "IESG" X-OriginalArrivalTime: 20 Dec 2006 19:23:30.0673 (UTC) FILETIME=[55225610:01C7246C] X-IBRFilter-SpamReport: 1 (*) BAYES_60 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id kBKJNVIe020778 X-Mailman-Approved-At: Thu, 21 Dec 2006 15:58:34 +0100 Cc: aaa-doctors@ietf.org, MIB Doctors , DNS Directorate Subject: [nmrg] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 19:23:42 -0000 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 Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBKJANrT019648 for ; Wed, 20 Dec 2006 20:10:29 +0100 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id kBKJAI5g004651 for ; Wed, 20 Dec 2006 14:10:22 -0500 Received: (qmail 13830 invoked by uid 78); 20 Dec 2006 19:10:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 20 Dec 2006 19:10:18 -0000 Message-ID: <45898A91.70305@andybierman.com> Date: Wed, 20 Dec 2006 11:10:09 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: David B Harrington References: <191a01c723bf$dd9b80f0$0600a8c0@china.huawei.com> In-Reply-To: <191a01c723bf$dd9b80f0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Thu, 21 Dec 2006 15:58:12 +0100 Cc: ops-nm@ietf.org, aaa-doctors@ietf.org, 'MIB Doctors' , 'DNS Directorate' , "'Romascanu, Dan \(Dan\)'" , 'IESG' , nmrg@ibr.cs.tu-bs.de, ops-area@ietf.org Subject: [nmrg] Re: [MIB-DOCTORS] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 19:10:33 -0000 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 Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [206.18.177.53]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJMq73p006689 for ; Tue, 19 Dec 2006 23:52:12 +0100 Received: from harrington73653 (135-152.186-72.tampabay.res.rr.com?[72.186.152.135]) by comcast.net (alnrmhc13) with SMTP id <20061219225200b1300q8t3qe>; Tue, 19 Dec 2006 22:52:01 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , , , "'MIB Doctors'" , , "'DNS Directorate'" Date: Tue, 19 Dec 2006 17:48:54 -0500 Message-ID: <191a01c723bf$dd9b80f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcccV6ii14zulLX7R3CFlQvi3jCmlAHZmmUA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-IBRFilter-SpamReport: 3.614 (***) BAYES_80,DNS_FROM_RFC_POST X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de, 'IESG' Subject: [nmrg] RE: [MIB-DOCTORS] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 22:52:18 -0000 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. 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? 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. dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, December 19, 2006 2:54 AM > To: ops-area@ietf.org; ops-nm@ietf.org; MIB Doctors; > aaa-doctors@ietf.org; DNS Directorate > Cc: nmrg@ibr.cs.tu-bs.de; IESG > Subject: [MIB-DOCTORS] OPS Area BOFs in Prague > > > This is a reminder that we intent to schedule for the Prague IETF a > number of BOFs or mini-BOFs in the OPS area meeting slots with the > intention to bring to attention new ideas in the operations and > management area and discuss which of those are worth becoming subject > for future standardization, research or prototyping work. > Although there > are still three months to go until the Prague IETF it is not too early > to send proposals, both in order to help planning the > sessions, as well > as in order to better prepare the sessions by holding preliminary > discussions. Any of the lists in the area would do, but > ops-area@ietf.org would probably be the best. > > David and Dan > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors > Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJFaMqm032104 for ; Tue, 19 Dec 2006 16:36:27 +0100 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id CD49D565F7 for ; Tue, 19 Dec 2006 16:36:22 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30971-05 for ; Tue, 19 Dec 2006 16:36:20 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 5AD705ACC0 for ; Tue, 19 Dec 2006 16:36:17 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id CBE1090124C; Tue, 19 Dec 2006 16:36:17 +0100 (CET) Resent-From: j.schoenwaelder@iu-bremen.de Resent-Date: Tue, 19 Dec 2006 16:36:17 +0100 Resent-Message-ID: <20061219153617.GA17119@boskop.local> Resent-To: nmrg@ibr.cs.tu-bs.de Received: from merkur.iu-bremen.de ([unix socket]) by merkur (Cyrus v2.2.12) with LMTPA; Tue, 19 Dec 2006 08:54:10 +0100 X-Sieve: CMU Sieve 2.2 Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by merkur.iu-bremen.de (Postfix) with ESMTP id 4206079E96E2D for ; Tue, 19 Dec 2006 08:54:10 +0100 (CET) Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 336E35609B for ; Tue, 19 Dec 2006 08:54:10 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20761-10 for ; Tue, 19 Dec 2006 08:54:07 +0100 (CET) Received: from megatron.ietf.org (www1.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id D0F7756081 for ; Tue, 19 Dec 2006 08:54:04 +0100 (CET) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZnX-0005dB-FW; Tue, 19 Dec 2006 02:54:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZnV-0005cJ-NM; Tue, 19 Dec 2006 02:54:01 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwZnO-0006jc-Gr; Tue, 19 Dec 2006 02:54:01 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ7rq0W032607; Tue, 19 Dec 2006 02:53:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300815erh2.post.avaya.com ([198.152.6.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Dec 2006 21:32:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by 300815erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJWa1g000326 for ; Mon, 18 Dec 2006 14:32:36 -0500 Received: from co300216-co-ierwest.avaya.com (h198-152-13-104.avaya.com [198.152.13.104]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJRLYO001667 for ; Mon, 18 Dec 2006 14:32:30 -0500 Received: from lists.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by co300216-co-ierwest.avaya.com with ESMTP; 18 Dec 2006 14:31:38 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCk-00055A-Iu; Mon, 18 Dec 2006 14:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCj-00054X-Hm; Mon, 18 Dec 2006 14:31:17 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwOCh-0001Sr-2S; Mon, 18 Dec 2006 14:31:17 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJVBEC009649; Mon, 18 Dec 2006 14:31:14 -0500 content-class: urn:content-classes:message Date: Tue, 19 Dec 2006 09:53:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area BOFs in Prague Thread-Index: AcccV6ii14zulLX7R3CFlQvi3jCmlA== From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors" , , "DNS Directorate" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Errors-To: mib-doctors-bounces@ietf.org X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Status: No, score=-2.264 tagged_above=-30 required=5 tests=[AWL=0.048, BAYES_00=-2.312] X-Spam-Score: -2.264 X-Spam-Level: X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id kBJFaMqm032104 Cc: nmrg@ibr.cs.tu-bs.de, IESG Subject: [nmrg] [MIB-DOCTORS] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 15:36:32 -0000 This is a reminder that we intent to schedule for the Prague IETF a number of BOFs or mini-BOFs in the OPS area meeting slots with the intention to bring to attention new ideas in the operations and management area and discuss which of those are worth becoming subject for future standardization, research or prototyping work. Although there are still three months to go until the Prague IETF it is not too early to send proposals, both in order to help planning the sessions, as well as in order to better prepare the sessions by holding preliminary discussions. Any of the lists in the area would do, but ops-area@ietf.org would probably be the best. David and Dan _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/mib-doctors Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJ7rsAG016433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 19 Dec 2006 08:54:00 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ7rqKT024301 for ; Tue, 19 Dec 2006 02:53:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300815erh2.post.avaya.com ([198.152.6.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Dec 2006 21:32:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by 300815erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJWa1g000326 for ; Mon, 18 Dec 2006 14:32:36 -0500 Received: from co300216-co-ierwest.avaya.com (h198-152-13-104.avaya.com [198.152.13.104]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJRLYO001667 for ; Mon, 18 Dec 2006 14:32:30 -0500 Received: from lists.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by co300216-co-ierwest.avaya.com with ESMTP; 18 Dec 2006 14:31:38 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCk-00055A-Iu; Mon, 18 Dec 2006 14:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCj-00054X-Hm; Mon, 18 Dec 2006 14:31:17 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwOCh-0001Sr-2S; Mon, 18 Dec 2006 14:31:17 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJVBEC009649; Mon, 18 Dec 2006 14:31:14 -0500 content-class: urn:content-classes:message Date: Tue, 19 Dec 2006 09:53:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area BOFs in Prague Thread-Index: AcccV6ii14zulLX7R3CFlQvi3jCmlA== From: "Romascanu, Dan \(Dan\)" To: , , "MIB Doctors" , , "DNS Directorate" X-Scanner: InterScan AntiVirus for Sendmail X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id kBJ7rsAG016433 Cc: nmrg@ibr.cs.tu-bs.de, IESG Subject: [nmrg] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 07:54:02 -0000 This is a reminder that we intent to schedule for the Prague IETF a number of BOFs or mini-BOFs in the OPS area meeting slots with the intention to bring to attention new ideas in the operations and management area and discuss which of those are worth becoming subject for future standardization, research or prototyping work. Although there are still three months to go until the Prague IETF it is not too early to send proposals, both in order to help planning the sessions, as well as in order to better prepare the sessions by holding preliminary discussions. Any of the lists in the area would do, but ops-area@ietf.org would probably be the best. David and Dan Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBIJVDor018134 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 18 Dec 2006 20:31:19 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJVBnc009652 for ; Mon, 18 Dec 2006 14:31:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Dec 2006 21:31:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: reminder about OPS Area BOFs in Prague Thread-Index: AcccV6ii14zulLX7R3CFlQvi3jCmlA== From: "Romascanu, Dan \(Dan\)" To: , , "MIB Doctors" , , "DNS Directorate" X-Scanner: InterScan AntiVirus for Sendmail X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id kBIJVDor018134 Cc: nmrg@ibr.cs.tu-bs.de, IESG Subject: [nmrg] reminder about OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2006 19:31:21 -0000 David, This is a reminder that we intent to schedule for the Prague IETF a number of BOFs or mini-BOFs in the OPS area meeting slots with the intention to bring to attention new ideas in the operations and management area and discuss which of those are worth becoming subject for future standardization, research or prototyping work. Although there are still three months to go until the Prague IETF it is not too early to send proposals, both in order to help planning the sessions, as well as in order to better prepare the sessions by holding preliminary discussions. Any of the lists in the area would do, but ops-area@ietf.org would probably be the best. David and Dan