Re: Submission of draft-ietf-opsec-filtering-caps-06 to IESG

[Ron Bonica <rbonica@juniper.net>]

Thanks much. I will take a look at the draft over the next week.

                       Ron


patrick cain wrote:
> Hi,
> 
> Attached is the document shepherd write up for draft-ietf-opsec-06.
> The OPSEC WG is forwarding this document as a candidate BCP.
> 
> Pat Cain
> OPSEC co-chair
> ----
> 
> Document Shepherd Write-Up
> 
> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?
> 		
> 		Pat Cain, OPSEC, co-chair is the document shepherd, and
> believes 
> 		that this draft has received adequate review and is ready
> for 
> 		forwarding to the IESG for review ad publication.
> 
> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?
> 
> 		The document has had adequate review from the WG, other 
> 		IETF areas, and non-IETF operator forums.
> 
> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?
> 
> 		No.
> 
> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.
> 
> 		Since this document is not a protocol, there was significant
> 		discussion in the WG on the intended status of this
> document. 
> 		The WG believes that this is really a BCP and wishes to 
> 		forward this document as a candidate BCP.
> 
> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?
> 		
> 		A large number of WG members lively reviewed versions 
> 		of this draft.
> 
> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)
> 
> 		Not that the shepherd is aware of.
> 
> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?
> 
> 		The document successfully completed v.2.04.03 of the idnit
> tool.
> 
> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].
> 
> 		The references in the document are all non-normative as far 
> 		as we can tell. As such they are not differentiated.
> 
> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?
> 
> 		Yes (This was the change from -05 to -06.)
> 
> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?
> 	
> 		Yes, we have no such sections.
> 
> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up?  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
> 
>        Technical Summary
> 		Operational Security Current Practices in Internet 
> 		Service Provider Environments [RFC4778] lists operator
> practices
> 		related to securing networks.  The OPSEC working group
> developed a
>  		series of documents identifying device capabilities to
> support 
> 		those practices. This document lists filtering 
> 		and rate limiting capabilities needed to support those
> practices.
> 		Capabilities are limited to filtering and rate limiting
> packets 
> 		as they enter or leave the device.  Route filters and
> service 
> 		specific filters (e.g.  SNMP, telnet) are covered in other
> documents.
> 
>    		Note that Capabilities are defined without reference to
> specific 
> 		technologies.  This is done to leave room for deployment of
> new 
> 		technologies that implement the capability.  Each capability
> 
> 		cites the practices it supports.  Current implementations
> that 
> 		support the capability are cited.  Special considerations
> are 
> 		discussed as appropriate listing operational and resource
> constraints,
> 		limitations of current implementations, trade-offs, etc.
> 
> 
>         Working Group Summary
>           	The WG consulted with many operators and vendors to come to 
> 		consensus with the capability documents.
> 
>        Document Quality
> 		The document defines capabilities, many already included 
> 		within network devices.
> 
>        Personnel
>           Who is the Document Shepherd for this document?  Who is the
>           Responsible Area Director?
> 
> 		DS == Pat Cain
> 		rAD == Ron Bonica
> 
> (end)
>