[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