Document Writeup for draft-ietf-i2nsf-framework-07
> (1) What type of RFC is being requested?
> Why is this the proper type of RFC?
> Is this type of RFC indicated in the title page header?
This document is requested for publication as an Informational RFC.
This is appropriate for a framework that does not define any protocol
elements.
This is clearly indicated on the title page.
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up.
>
> Technical Summary:
This document describes the framework for the Interface to Network
Security Functions (I2NSF), and defines a reference model (including
major functional components) for I2NSF. Network security functions
(NSFs) are packet-processing engines that inspect and optionally
modify packets traversing networks, either directly or in the context
of sessions to which the packet is associated.
> Working Group Summary:
There was nothing exceptional in the WG processing for this document.
There was careful debate resulting in a number of changes and careful
synchronisation with other WG documents.
> Document Quality:
This framework is not directly implementable, but it underpins the work
of the working group. At least one vendor is building a system based on
the work of the working group and following this framework as an
architecture. There has also been experimentation at IETF hackathons
that is consistent with this framework.
> Personnel:
Yoav Nir <ynir.ietf@gmail.com> is the Document Shepherd.
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> is the Responsible AD.
> (3) Briefly describe the review of this document that was performed
> by the Document Shepherd. If this version of the document is not
> ready for publication, please explain why the document is being
> forwarded to the IESG.
This revision and the previous revision were reviewed by the document
shepherd. All comments arising from the reviews have been addressed.
The document is ready for publication.
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
No. The WG is small, but there were a good number of sound reviews.
> (5) Do portions of the document need review from a particular or from
> broader perspective.
Not required, but a wider security view might be wise.
> (6) Describe any specific concerns or issues that the Document
> Shepherd has with this document that the Responsible Area Director
> and/or the IESG should be aware of?
There is a continuous debate on the value and purpose of publishing
framework documents. This document is specifically noted as a
deliverable in the WG charter. The WG debated the value of publication
and decided that it would be helpful to have this document published.
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed. If not, explain why?
The authors have been explicitly reminded of their responsibilities
under BCP 78 and 79. By placing their names as authors of the document
they have acknowledged those BCPs and agreed to comply with the terms of
the IETF's IP policies.
> (8) Has an IPR disclosure been filed that references this document?
No IPR has been disclosed against this document.
> (9) How solid is the WG consensus behind this document?
Good.
There has been review and supporting positions across the WG.
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?
None known.
> (11) Identify any ID nits the Document Shepherd has found in this
> document.
idnits complains about unnecessary RFC 2119 boilerplate. That can
safely be removed by the RFC Editor.
There is also an extraneous space spotted by idnits
> (12) Describe how the document meets any required formal review
> criteria.
Nothing requiring formal review.
> (13) Have all references within this document been identified as
> either normative or informative?
They most surely have.
> (14) Are there normative references to documents that are not ready
> for advancement or are otherwise in an unclear state?
All normative references are to published RFCs.
> (15) Are there downward normative references?
No downrefs.
> (16) Will publication of this document change the status of any
> existing RFCs?
No.
> (17) Describe the Document Shepherd's review of the IANA
> considerations section.
A null IANA section is correctly included.
> (18) List any new IANA registries that require Expert Review for
> future allocations.
None.
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language.
No such section, no such review.