Re: Straw-man charter

[Ross Callon <rcallon@juniper.net>]

Comments in-line with text version of draft charter:

At 09:24 AM 6/2/2004 -0400, George Jones wrote:
> ...Operational Security (opsec) Charter
>
> Last Modified: 2004-06-04
> Chair(s):
>
>   ??? ???? <???@???.com>
>
> Operations and Management Area Director(s):
>
>   Bert Wijnen <bwijnen@lucent.com>
>   David Kessens <david.kessens@nokia.com>
>
> Operations and Management Area Advisor:
>
>   David Kessens <david.kessens@nokia.com>
>
> Security Area Director(s):
>
>   Russell Housley <housley@vigilsec.com>
>   Steven Bellovin <smb@research.att.com>
>
> Security Area Advisor:
>
>   Steven Bellovin <smb@research.att.com>
>
> Mailing Lists:
>
>   General Discussion: opsec@ops.ietf.org
>   To Subscribe: opsec-request@ops.ietf.org
>   In Body: subscribe
>   Archive: http://ops.ietf.org/lists/opsec/
>   Description of Working Group:
>
> Goals
>
>   The goal of the Operational Security Working Group is to codify
>   knowledge about feature sets that are required to securely deploy and
>   operate managed network elements.
>
> Scope
>
>   The working group will produce requirements appropriate for:
>
>     * Network Service Providers (NSP) Networks
>     * Internet Service Provider (ISP) Networks
>     * Enterprise Networks

Is it clear what a "Network Service Provider" is? From the context, I am
figuring that it whomever offers a network service other than Internet and
Enterprise networks. This seems to include Layer 3 VPN services. Does
it also include Layer 2 VPN services? Does it include ATM services?

>   Once these are done, it may be appropriate to broaden the scope (and
>   recharter) to address the operational security requirements of of:

This sentence doesn't quite read the way that charters typically read, and
might be interpreted as saying that these *will* be added, rather than *might*
be added. How about:

The following areas are excluded from the charter at this time. They
may be considered for inclusion in an updated charter at a later time:

>     * Wireless devices
>     * SOHO devices
>     * Security devices (firewalls, IDS, Authentication Servers)
>     * Hosts
>     * Unmanaged devices



> Methods
>
>   A road-map document will be produced describing the scope, format,
>   intended use and sequence of future documents. A series of small BCP
>   documents will be produced covering various areas of security
>   management functionality...

Very minor nit: I would leave out the word "small", on the basis that the size
is implied by the number of documents that we are to produce. While the
intend to avoid a single huge document will be implicit in the fact that we
are proposing to produce multiple documents, nonetheless each document
will be whatever it is.

> Profiles documents will be produced, citing
>   the BCPs, which list the requirements relevant to different operating
>   environments. Profiles might list different requirements for devices
>   in different roles: core, edge, peering, aggregation, access, etc.
>
>   http://www.ietf.org/internet-drafts/draft-jones-opsec-06.txt will be 
> used as a jumping off point.
>
>   Much of the operational security knowledge that needs to be codified
>   resides with operators. Operators have shown a tendency to be too busy
>   with day-to-day operations to be as involved in standards bodies as
>   one would hope. They have shown a greater tendency to be involved in
>   operators forums such as NANOG and RIPE. In order to access their
>   knowledge and reach the working group goal, interim meetings may be
>   held at such operator forums.

How about abbreviating this to:

  Much of the operational security knowledge that needs to be codified
  resides with operators. In order to access their knowledge and reach
  the working group goal, interim meetings may be held at operator forums
  such as NANOG and/or RIPE.

> Goals and Milestones:
>
>   Jun 04                Hold charter discussions on mailing list, 
> identify chair+authors, submit charter
> Jul 04          Schedule Working Group
> Aug 04          Working Group Meeting @ San Diego
> Sep 04          Submit Roadmap Draft

This is rather optimistic. I think that we will be doing well to have an 80%
complete draft by September, as a working group document. There might
still be some discussion regarding what should be in the roadmap. It will
take some work to get this 100% completed and through working group
last call. I would expect that two IETFs later would be more realistic (which
puts it out to March 2005).

> Oct 04          Submit In-Band, OoB and Interface Reqs Drafts
> Oct 04          Interim meeting @ NANOG
> Nov 04          Working Group Meeting @ Washington, Roadmap to IESG
> Dec 04          Submit Stack, Rate Limiting, Filtering Drafts...
> Jan 05          In-Band, OoB and Interface Reqs to IESG

I would push the other document milestones out a bit also.

I am not sure whether we explicitly need to mention the interim meeting
at Nanog in the charter, although it seems like a good idea to have such
a meeting.

> .
> Aug 05          Working Group Meeting/Wrap up

This depends upon what happens after we finish the first charter
items. It would seem that at that point we would want to decide
whether to wrap-up, or to extend the charter. I don't think that we
need to put this line item into the charter.

> Internet-Drafts (to be written):
>
>     * OPSEC Roadmap (info)

Should we call this "roadmap" or "framework"?

>     * OPSEC In-Band Management Requirements (BCP)
>     * OPSEC Out-Of-Band Management Requirements (BCP)
>     * OPSEC Configuration and Management Interface Requirements (BCP)
>     * OPSEC IP Stack Requirements (BCP)

Is there enough in IP stack to warrant its own document, or should this
be put into the "other" document?

>     * OPSEC Rate Limiting Requirements (BCP)
>     * OPSEC Filtering Requirements (BCP)

I would tend to put rate limiting and filtering in the same document (there are
of course a number of different things that you can do in response to a filter,
which rate limiting only being one of many).

>     * OPSEC Event Logging Requirements (BCP)
>     * OPSEC AAA Requirements (BCP)
>     * OPSEC Other (L2 reqs, performance, etc Requirements (BCP).)
>     * OPSEC Documentation Requirements Requirements (BCP)
>     * OPSEC Assurance Requirements Requirements (BCP)

I don't understand what this is...

>     * OPSEC NSP Operational Security Requirements Profile(info)
>     * OPSEC ISP Operational Security Requirements Profile (info)
>     * OPSEC Enterprise Operational Security Requirements Profile (info)

I am assuming that the timeframes for these would need to be after the
other documents are done, on the basis that you can't decide whether
you need to support a feature until you define what the feature is.

>     * OPSEC Working Group Discussion Archive and Food for Thought. 
> Features discussed but not deemed to be BCP. (info)
>
> Request For Comments: None. IETF Secretariat - Please send questions,
> comments, and/or suggestions to ietf-web@ietf.org.
>
> Return to working group directory.
>
> Return to IETF home page.