[Nea] Submitted draft-ietf-nea-requirements-05.txt for publication

["Stephen Hanna" <shanna at juniper.net>]

Since the NEA WG has reached consensus to request
publication of draft-ietf-nea-requirements-05.txt
as an Informational RFC, I have sent it off to
our Area Director, Tim Polk. I expect that he will
soon start an IETF Last Call on the document.

Consistent with the Document Shepherding process
described in RFC 4858, I will be the Document Shepherd
for this document. That means that I'm responsible
for writing a Document Shepherd Write-Up (copied
below) and for facilitating the document's progress
throughout the review process. I'll keep you posted
on this progress or you can observe it yourself using
the ID Tracker <https://datatracker.ietf.org/idtracker>.

Thanks,

Steve

----------

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

Steve Hanna <shanna at juniper.net> is the Document Shepherd.
Yes, I have personally reviewed the document and believe
that it is ready for the IESG.

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

Yes, the document has had thorough review by a good number of
WG members and several non-WG members. I do not have any concerns
about the breadth of reviews.

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

No specific concerns or IPR disclosures.

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

WG consensus is strong for this document. At least ten WG members
have reviewed this requirements document and indicated that they
support advancing this version.

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

No.

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

Yes.

(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 are properly split and don't include any
problematic normative references.

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

As explained in the document's IANA Considerations section,
there are no IANA actions needed for this specification.

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

No part of the document is written in a formal language.

(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

         This document defines the problem statement, scope and
         protocol requirements between the components of the NEA
         (Network Endpoint Assessment) reference model.  NEA provides
         owners of networks (e.g. an enterprise offering remote access)
         a mechanism to evaluate the posture of a system.  This may
         take place during the request for network access and/or
         subsequently at any time while connected to the network.
         The learned posture information can then be applied to a
         variety of compliance oriented decisions.  The posture
         information is frequently useful for detecting systems
         that are lacking or have out of date security protective  
         mechanisms such as: anti-virus and host-based firewall
         software.

      Working Group Summary

         There is consensus in the WG to publish this document.

      Document Quality

         At least one group of authors is putting together a set of
         protocols aimed to meet the requirements in this document.

      Personnel

         Steve Hanna shepherded this document. Tim Polk was the
         Responsible Area Director.


_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea