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