RE: Straw-man charter

[George Jones <gmj@pobox.com>]

On Fri, 4 Jun 2004, Budd, Fred wrote:

> Comments inline.  Tried to avoid duplicating ideas sent by others that I agree with.
>
> -Fred Budd
>
> 	-----Original Message-----
>
>
> 	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.
> 	FB> ...managed network elements providing L2/L3 transport functionality.
> 	Scope

"...providing transit services at OSI layers 2 and 3." ?

>
> 	  The working group will produce requirements appropriate for:
> 	FB> ...appropriate for the following operational environments:
> 	    * Network Service Providers (NSP) Networks
> 	    * Internet Service Provider (ISP) Networks
> 	    * Enterprise Networks
>
>
> 	FB> The idea of combining NSP/ISP and just having one category
> 	for transit service providers is starting to grow on me.
> 	Might also explicitly state that ASP, CSP, and SOHO
> 	environments are out of scope.  I'd almost through in wireless
> 	as well, but haven't given it sufficient thought yet.

Think fast.   Goals now state "l2/l3 transit".

On 3ed thought, I think you're right.   I've knocked it down to just
"ISP" and "Enterprise".   If someone has a compelling argument for
reinstating NSP, and differentiating it from "big ISP", speak up.

> 	Internet-Drafts (to be written):
>
> 	    * OPSEC Roadmap (info)
>
> 	FB> Framework, architecture, or roadmap have all been used
> 	previously, with slightly different connotations.  Framework
> 	seems to track best with the text in the methods section and
> 	the operational focus. The only roadmap doc I can think of off
> 	the top of my head is for IPsec, and that was written to show
> 	how the dozen or so individual IPsec docs tied together as
> 	well as provide guidance to keep future docs consistent.
> 	Don't see why that material couldn't be placed in a framework
> 	titled document.

As the only expressed opinion on the topic, you win for now.  Framework.


> 	FB> I think that from a security perspective the identifying
> 	    * characteristics a filter uses and the treatment applied
> 	    * to traffic by the filter, such as rate limiting, are
> 	    * coupled enough to warrant being in the same document.
> 	    * But from a non-security operational viewpoint the
> 	    * different treatment actions are generally kept
> 	    * distinct/separated.

Since this is a security document, I think combining is OK.

>
> 	    * OPSEC NSP Operational Security Requirements Profile(info)
> 	    * OPSEC ISP Operational Security Requirements Profile (info)
>
> 	FB> The intent is to classify the profile by the network
> operator's role, and then have individual sections in each document
> that lay out the applicable requirements for each device role within
> the context of various operational scenarios, correct?

Basically, yes.

>
> 	    * OPSEC Enterprise Operational Security Requirements Profile (info)
> 	    * OPSEC Working Group Discussion Archive and Food for Thought. Features discussed but not deemed to be BCP. (info)
>
> 	FB> This is where futures stuff that was removed from the draft would be placed?

Yes.

Thanks,
---George Jones