> (1) What type of RFC is being requested
Standards Track
> Why is this the proper type of RFC?
This document describes the problem being solved by the work of
the I2NSF working group and will be a normative reference from
all of the protocol work.
> Is this type of RFC indicated in the title page header?
Yes.
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up.
>
>
> Technical Summary:
The demand for hosted (or cloud-based) security services is growing.
To meet the demand, more and more service providers are providing
hosted security solutions to deliver cost-effective managed security
services to enterprise customers. The Network Security Functions
(NSFs) are provided and consumed in a large variety of environments.
Users of NSFs may consume network security services hosted by one or
more providers, which may be their own enterprise, service providers,
or a combination of both. This indicates a potential benefit in a
common interface and architecture to access NSFs.
This document describes the problem statement for Interface to
Network Security Functions (I2NSF) as well as some companion use
cases.
> Working Group Summary:
This is the first document coming from the I2NSF WG. It is the
result of merging material from four separate documents and then
agreeing terminology within the WG. Later stages of work on the
document have been largely editorial and so the level of interest
has not been high. However, I am confident that there is solid
support in the WG.
There is no controversy.
The WG had a milestone that read:
| WG decides whether to progress adopted drafts for publication as
| RFCs (use cases, framework, information model, and examination of
| existing secure communication mechanisms)
Discussion led to agreement to drop some documents, but also to pursue
use cases by folding them into this problem statement document as
valuable context.
> Document Quality:
This problem statement is not, of itself, implementable. The WG has
participation from a number of implementers/vendors of NSFs who say
they want to work on solutions with a view to providing standardised
interfaces. The operators who are participating have not committed
to deploy such an interface, but are watching to see how it ends up
because they recognise the potential benefit.
This document attracted several careful reviews during WG last call.
> Personnel:
Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd.
Kathleen Moriarty (kathleen.moriarty.ietf@gmail.com) is the Responsible
Area Director.
> (3) Briefly describe the review of this document that was performed
> by the Document Shepherd.
I reviewed this document during WG last call.
None of my issues was substantive, and all have been addressed.
I believe this revision is ready for publication.
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
The review has been a little thin, but not alarmingly so. There were
three careful reviews during WG last call, and the authors have taken
care with the document.
> (5) Do portions of the document need review from a particular or
> from broader perspective.
If there are additional reviews from the SecDir and OpsDir before
publication, this might be beneficial.
> (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?
Note that the document has 6 front page authors. This is a result of
the substantial draw on no fewer than 4 other documents. Another 11
people are listed as Contributors in Section 9, so it cannot be claimed
that the front page is Cavalier.
Sections 8 and 10 should be merged.
See the Working Group Summary for a note on why publication of this
document is being pursued.
> (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?
All of the authors and contributors have been made explicitly aware of
their responsibilities under BCP78&79 and have been reminded that as
named authors/contributors they are signing their compliance.
All of the front-page authors have explicitly confirmed that they
have disclosed all relevant IPR of which they are aware.
> (8) Has an IPR disclosure been filed that references this document?
No IPR has been disclosed against this document or any of its
predecessors.
> (9) 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?
The WG agrees and there is no dissent. To some extent the content of
this document represents the motivation for the formation of the WG and
the consensus can be measured at that point as well as at WG last call.
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?
None.
> (11) Identify any ID nits the Document Shepherd has found in this
> document.
idnits is throwing a bogus warning about an unused reference (that is
actually used).
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
N/A
> (13) Have all references within this document been identified as
> either normative or informative?
Yes. All references are (correctly) Informative.
> (14) Are there normative references to documents that are not ready
> for advancement or are otherwise in an unclear state?
N/A
> (15) Are there downward normative references?
No.
> (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.
The document correctly contains a null IANA section.
> (18) List any new IANA registries that require Expert Review for
> future allocations.
N/A
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
N/A