Changes between Initial Version and Version 1 of WriteupNeaAsokan

25/09/12 20:55:26 (10 years ago)



  • WriteupNeaAsokan

    v1 v1  
     1The actual document shepherd writeup for draft-ietf-nea-asokan:
     3(1) What type of RFC is being requested (BCP, Proposed Standard,
     4Internet Standard, Informational, Experimental, or Historic)? Why is
     5this the proper type of RFC? Is this type of RFC indicated in the title
     6page header?
     8Informational is requested and indicated in the title page header.
     10(2) The IESG approval announcement includes a Document
     11Announcement Write-Up. Please provide such a Document
     12Announcement Write-Up. Recent examples can be found in the
     13"Action" announcements for approved documents. The approval
     14announcement contains the following sections:
     16  Technical Summary:
     17The Network Endpoint Assessment protocols are subject to a
     18subtle forwarding attack that has become known as the NEA
     19Asokan Attack. This document describes the attack and
     20countermeasures that may be mounted.
     22  Working Group Summary:
     24The WG formed a design team in July 2010 with the goal of
     25recommending a general-purpose counter-measure that would
     26work for both of the PT protocols under specification in the WG.
     27The design team analysis and recommendation is the subject
     28of this document. The recommendation of the design team was
     29presented to the WG at the IETF meeting in November 2010
     30where it received solid support. The result was confirmed on the
     31mailing list in January 2011, and the recommended counter-
     32measure subsequently incorporated into the two PT protocols
     33specified in the NEA WG. The two PT protocols, PT-TLS and PT-
     34EAP, are separately specified in two standards-track documents,
     35and reference this document as an Informative reference.
     37  Document Quality:
     38This document does not specify a protocol. Rather, it describes
     39counter-measures that PT-TLS and PT-EAP can use to mitigate
     40against the NEA Asokan attack. The PT-TLS and PT-EAP
     41specifications describe how these counter-measures should be used
     42in these particular protocols. As described above,  this
     43document is the result of active participation from several WG
     44members and received substantive review from the WG.
     46  Personnel:
     47Susan Thomson is the Document Shepherd. Stephen Farrell is
     48the Responsible Area Director.
     50(3) Briefly describe the review of this document that was performed by
     51the Document Shepherd. If this version of the document is not ready
     52for publication, please explain why the document is being forwarded to
     53the IESG.
     55I have reviewed the document and do not have issues with it.
     57(4) Does the document Shepherd have any concerns about the depth
     58or breadth of the reviews that have been performed?
     62(5) Do portions of the document need review from a particular or from
     63broader perspective, e.g., security, operational complexity, AAA, DNS,
     64DHCP, XML, or internationalization? If so, describe the review that took
     67No broader review is known to be needed.
     69(6) Describe any specific concerns or issues that the Document
     70Shepherd has with this document that the Responsible Area Director
     71and/or the IESG should be aware of? For example, perhaps he or she
     72is uncomfortable with certain parts of the document, or has concerns
     73whether there really is a need for it. In any event, if the WG has
     74discussed those issues and has indicated that it still wishes to advance
     75the document, detail those concerns here.
     77No concerns. The attack and the need for a counter-measure was
     78thoroughly vetted within the NEA WG.
     80(7) Has each author confirmed that any and all appropriate IPR
     81disclosures required for full conformance with the provisions of BCP 78
     82and BCP 79 have already been filed. If not, explain why?
     86(8) Has an IPR disclosure been filed that references this document? If
     87so, summarize any WG discussion and conclusion regarding the IPR
     92(9) How solid is the WG consensus behind this document? Does it
     93represent the strong concurrence of a few individuals, with others
     94being silent, or does the WG as a whole understand and agree with it?
     96There is strong consensus from the WG. The attack itself was reviewed
     97within the WG at multiple IETF meetings, and the recommendation for
     98a counter-measure made by the design team received strong
     99consensus and has been incorporated into the relevant PT
     102(10) Has anyone threatened an appeal or otherwise indicated extreme
     103discontent? If so, please summarise the areas of conflict in separate email
     104messages to the Responsible Area Director. (It should be in a separate
     105email because this questionnaire is publicly available.)
     109(11) Identify any ID nits the Document Shepherd has found in this
     110document. (See and the Internet-
     111Drafts Checklist). Boilerplate checks are not enough; this check needs
     112to be thorough.
     114None. Idnits tool flags no issues.
     116(12) Describe how the document meets any required formal review
     117criteria, such as the MIB Doctor, media type, and URI type reviews.
     119Not Applicable.
     121(13) Have all references within this document been identified as either
     122normative or informative?
     124Yes. All references are informative.
     126(14) Are there normative references to documents that are not ready
     127for advancement or are otherwise in an unclear state? If such
     128normative references exist, what is the plan for their completion?
     130No. There are no normative references.
     132(15) Are there downward normative references (see RFC 3967)? If so,
     133list these downward references to support the Area Director in the Last
     134Call procedure.
     138(16) Will publication of this document change the status of any
     139existing RFCs? Are those RFCs listed on the title page header, listed in
     140the abstract, and discussed in the introduction? If the RFCs are not
     141listed in the Abstract and Introduction, explain why, and point to the
     142part of the document where the relationship of this document to the
     143other RFCs is discussed. If this information is not in the document,
     144explain why the WG considers it unnecessary.
     148(17) Describe the Document Shepherd's review of the IANA
     149considerations section, especially with regard to its consistency with
     150the body of the document. Confirm that all protocol extensions that
     151the document makes are associated with the appropriate reservations
     152in IANA registries. Confirm that any referenced IANA registries have
     153been clearly identified. Confirm that newly created IANA registries
     154include a detailed specification of the initial contents for the registry,
     155that allocations procedures for future registrations are defined, and a
     156reasonable name for the new registry has been suggested (see RFC
     159Not applicable. The document specifies no actions for IANA.
     161(18) List any new IANA registries that require Expert Review for future
     162allocations. Provide any public guidance that the IESG would find
     163useful in selecting the IANA Experts for these new registries.
     165Not applicable. The document specifies no actions for IANA.
     167(19) Describe reviews and automated checks performed by the
     168Document Shepherd to validate sections of the document written
     169in a formal language, such as XML code, BNF rules, MIB
     170definitions, etc.
     172Not applicable. None of the document is written in a formal