[secdir] [Sam Hartman] Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP

Sam Hartman <hartmans-ietf@mit.edu> Wed, 03 June 2009 19:57 UTC

Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201D628C1C7 for <secdir@core3.amsl.com>; Wed, 3 Jun 2009 12:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.432
X-Spam-Level:
X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdtuny7jLRvV for <secdir@core3.amsl.com>; Wed, 3 Jun 2009 12:57:57 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 92BD03A6FCD for <secdir@ietf.org>; Wed, 3 Jun 2009 12:57:57 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n53JvxaW026959 for <secdir@ietf.org>; Wed, 3 Jun 2009 15:57:59 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n53Jvwa0026956 for <secdir@PCH.mit.edu>; Wed, 3 Jun 2009 15:57:58 -0400
Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n53Jvnu3007446 for <secdir@mit.edu>; Wed, 3 Jun 2009 15:57:49 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 5CA4910CF817 for <secdir@mit.edu>; Wed, 3 Jun 2009 15:50:52 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu with ESMTP id cjEy0bAKK0efj8oc (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for <secdir@mit.edu>; Wed, 03 Jun 2009 15:50:52 -0400 (EDT)
Received-SPF: softfail (mit.edu: domain of transitioning hartmans@mit.edu does not designate 69.25.196.178 as permitted sender) receiver=mit.edu; client_ip=69.25.196.178; envelope-from=hartmans@mit.edu;
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ADCEE4141; Wed, 3 Jun 2009 15:50:49 -0400 (EDT)
To: secdir@mit.edu
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Wed, 03 Jun 2009 15:50:49 -0400
Message-ID: <tsltz2x3xly.fsf@mit.edu>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Subject: [secdir] [Sam Hartman] Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 19:57:59 -0000

I was assigned this as a secdir review.  I didn't really feel like
calling what I came up with a secdir review.

--- Begin Message ---
I was assigned this document as a secdir review.
I'm not sure I have any comments in that capacity.

However, I do have significant comments on the last call of this document.

I appreciate the work that has gone into this document.  People have
worked hard to find examples, cases and even pithy
sayings/architectural principles from many areas of the IETF.  The
document tries to be broad and to look at a lot of options.  I think
that it would be reasonable to publish this document as the current
thinking of the ops WG or ops area.  It may even be reasonable to use
something like this as guidelines for network/routing/sub-network
layer protocols to think about management and operations.
However this document is not suitable for publication as a BCP because:

* It does not reflect practices across significant areas of the IETF
* It does not provide clear, actionable guidelines
* It is not sufficiently clear to be understood outside the O&M area.

My background.  I have never formally been involved in the O&M area.
However, I have studied SNMP as a participant and AD for the ISMS Wg.
I have studied syslog as a user, operator, and as the AD who sponsored
many of syslog's base documents.  I have studied netconf as an AD who
reviewed the spec.  I've worked as a small enterprise operator.  I'm a
chair of a WG (LISP) that needs to consider operations and management
issues.  I believe that I should be able to read and understand this
document; I believe that I'm well within its target audience.

I got as far as the bottom of page 18 before giving up.

Here are details on my concerns based on what part of the document
I've read.  I'm happy to invest significant time to get other
reviewers to evaluate whether I have valid concerns; if I get others
to read the document and consider whether I have a point, then I've
done what I set out to do.

1) It does not reflect practices across significant areas of the IETF

This is a concern that the document does not have broad enough
consensus to be a BCP.  I believe that significant areas of the IETF
do not view management interoperability as a goal--much less a guiding
principle of management.  I've been involved in discussions in the
Kerberos working group where we explicitly discussed this and came to
the conclusion that management interoperability was not something
anyone in the room was going to work on.  We did work on an
information model which covers aspects where people believed some degree of management interoperability would be desirable.  It does not cover monitoring, faults, or the like--only provisioning of the database.


Similarly, I'm quite certain that most web server vendors, ATOM
implementors, etc do not want management interoperability.  I
understand that ISP operators very much do want management
interoperability.  I think that we have a significant conflict here
and I think that we cannot approve such a BCP without addressing that
conflict.  One possible resolution would be to find an subsection of
the IETF that actually agrees with these guidelines and scoping the
BCP.

Similarly, it has been my experience that the desire to standardize
information model semantics is not universal across the IETF.

My recommendation for determining if I have a valid concern here is to
get one or two WG chairs from each area to read this document and
comment explicitly on whether the approach to management and
managability outlined in this document is consistent with practice in
their area and WG.

Far too much of the text was specific to management of network
elements such as routers, switches and the like.  The apps and
security area use LDAP for a lot of things that I think would count as
management in this spec.  I don't know how to separate control plane
and data plane issues on my web server.  Enough of the text seemed
specific to network management instead of service/application
management that I would find applying this document in such a context
more frustrating than helpful.  This specific sub-concern could be
entirely addressed by properly scoping the applicability of the
document.


 2) It does not provide clear, actionable guidelines

I was looking at this document and trying to figure out what it would
mean for my WG if this document was approved.  As best I can tell it
would simply add justifications for discusses that would be hard to
debate fairly.  Do I have to write up an information model for my
protocol?  If the ops AD says I do, what grounds do we use to
determine whether that's reasonable?  The answer may be "yes and you
don't get to disagree," but I can't tell from the document.  If it's
going to be a BCP, that needs to be clear to me as a WG chair.

For what it's worth, I don't think we have the necessary consensus to
require people to write up information models and would not be part of
such a consensus at this time.  If this is a list of things I might
want to consider then why is it a BCP?

If we want to come up with a set of things that need to be documented
when appropriate, then I could support that.  I think we need to
clearly distinguish the normative process requirements from the set of
things to consider in such a case.  The set of things someone might
interpret as normative in this spec is far too broad.

  I do agree that
some of the concerns I am raising in this section could be leveled
against BCPs we've approved in the past--even BCPs that I sponsored in
at least one case.  I don't think that diminishes the concerns: we try
and learn from our mistakes.

3) It is not sufficiently clear to be understood outside the O&M area.

This document does an excellent job of clearing up a few o&m concepts:
the difference between information model, data model, modeling
language and protocol.

The document indicates that several distinctions are important, such
as the distinction between operations and management, the distinction
between configuration and other forms of management, etc.  The
configuration vs non-configuration management distinction seems very
important because I believe there is a growing belief that the set of
management protocols you use depends on what you are managing.  I hope
no one plans to use syslog to configure their routers--perhaps the
only worse choice would be IPFIX.

Unfortunately, while I agree that these distinctions are important, I
don't think the document succeeds in making them.  I have reread
section 2 and the first part of section 3 a couple of times.  I still
don't understand the difference between operations and management;
section two talks about management a lot and section 3 talks about
my operations model.  I don't understand what an operations model is,
even after reading the text a couple of times.

I found section 3 very frustrating.  I'd be reading along thinking I
was talking about management for one purpose, thinking about how that
interacted with protocols for that purpose, and then suddenly
something gets thrown in that completely fails to fit.  For example,
I'd be thinking about how to manage configuration state and then
suddenly I'm being told to define the semantics of my counters
consistently.  Both of those are fine things to discuss, but not in
such a way that a reader gets them mixed together.  The mental context
swap is too jarring and I found completely lost me.

In conclusion, I'm sorry that I could not be more constructive.  I
really a lot has gone into this document.  I realize that the goals
are important.  However I don't think we're particularly close to done
at least if the target is a BCP.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

--- End Message ---
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir