RE: Straw-man charter

["Budd, Fred" <Fred.Budd@wiltel.com>]

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
	
	  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.

	  Once these are done, it may be appropriate to broaden the scope (and
	  recharter) to address the operational security requirements of of:
	
	    * Wireless devices
	    * SOHO devices
	    * Security devices (firewalls, IDS, Authentication Servers)
	    * Hosts
	    * Unmanaged devices
	FB> Unmanaged devices are already out of scope per the goal.  Wireless and SOHO may be implicitly out of scope if the operational environment exclusions are put in.
	
	Goals and Milestones:
	FB> Meetings typically aren't listed in the goals and milestones.  Will the interim meetings and WG meetings qualify as an achievement/deliverable?  Gaining more involvement from operators doesn't seem to fit with the guidance.  The prior text about having meetings at NANOG and RIPE would seem to be sufficient.  There are WGs that have listed meetings in their goals though and it doesn't really matter to me.

	FB> As for defining some of the BCP deliverables before developing the framework...I think it's fine in the initial charter as long as it's kept clear that the defined BCPs may not encompass everything in the framework.  This assumes that we can reach a general consensus of BCP topics that will definitely be addressed.  Given the opsec draft work that seems doable.  I do agree that the schedule is a bit ambitious, particularly if we do get a decently diverse level of operator involvement.

	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
	Oct 04          Submit In-Band, OoB and Interface Reqs Drafts
	Oct 04          Interim meeting @ NANOG
	FB> Interim meetings require AD approval.  Those within 30 days of an IETF meeting aren't supposed to be approved.  Neither are meetings that replace IETF event meetings.

	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
	Aug 05          Working Group Meeting/Wrap up
	FB> I'd move all of the IESG submission dates out to 2005.  I'll forward on a modified timetable for discussion early next week if someone else doesn't beat me to it.
	

	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.

	    * 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)
	    * OPSEC Rate Limiting Requirements (BCP)
	    * OPSEC Filtering Requirements (BCP)

	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. 
	

	    * 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)

	FB> Minor nit. Requirements Requirements?

	    * 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?

	    * 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?