RE: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague

"Romascanu, Dan \(Dan\)" <dromasca@avaya.com> Thu, 21 December 2006 12:02 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxMdP-0007ZT-8C; Thu, 21 Dec 2006 07:02:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxMdM-0007WT-RA; Thu, 21 Dec 2006 07:02:48 -0500
Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxMdK-0001ly-Hs; Thu, 21 Dec 2006 07:02:48 -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 kBLC2dwZ025059; 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"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague
Date: Thu, 21 Dec 2006 14:02:38 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0BF6EF3E@is0004avexu1.global.avaya.com>
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)" <dromasca@avaya.com>
To: "Natale, Bob" <RNATALE@mitre.org>, ops-nm@ietf.org, ops-area@ietf.org, nmrg@ibr.cs.tu-bs.de, IESG <iesg@ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Cc: aaa-doctors@ietf.org, MIB Doctors <mib-doctors@ietf.org>, DNS Directorate <dns-dir@ops.ietf.org>
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

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
> 

_______________________________________________
OPS-NM mailing list
OPS-NM@ietf.org
https://www1.ietf.org/mailman/listinfo/ops-nm