Changes between Initial Version and Version 1 of WriteupKrbCamelia

25/09/12 21:04:15 (10 years ago)



  • WriteupKrbCamelia

    v1 v1  
     1The actual document shepherd writeup for draft-ietf-krb-wg-camellia-cts:
     3(1) What type of RFC is being requested (BCP, Proposed Standard,
     4Internet Standard, Informational, Experimental, or Historic)?  Why
     5is this the proper type of RFC?  Is this type of RFC indicated in the
     6title page header?
     8We are requesting publication as an Informational RFC.
     10The authors have requested publication on the standards track;
     11however, there is no consensus within the working group to do so at
     12this time. There is a possibility that a consensus may emerge in the
     13future to adopt one or both of the enctypes defined in this document
     14as mandatory to implement for Kerberos; if that happens, we will
     15likely request that the document be reclassified as a Proposed
     16Standard.  However, no such consensus exists at this time.
     18(2) The IESG approval announcement includes a Document Announcement
     19Write-Up. Please provide such a Document Announcement Write-Up. Recent
     20examples can be found in the "Action" announcements for approved
     21documents. The approval announcement contains the following sections:
     23  Technical Summary
     25This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961.  The new types use the Camellia block cipher in CBC-mode with ciphertext stealing and the CMAC algorithm for integrity protection.
     27  Working Group Summary
     29This document represents the consensus of the Kerberos Working Group.
     31  Document Quality
     33At least one major Kerberos implementor plans to include support for
     34the encryption and checksum types described in this document.
     36  Personnel
     38The Document Shepherd for this document is Jeffrey Hutzelman.
     39The responsible Area Director is Stephen Farrell.
     41(3) Briefly describe the review of this document that was performed by
     42the Document Shepherd.  If this version of the document is not ready
     43for publication, please explain why the document is being forwarded to
     44the IESG.
     46I have reviewed this document, and any issues raised have been
     47resolved to my satisfaction.  I believe the document is now ready
     48for IETF-wide review and publication as an RFC.
     50(4) Does the document Shepherd have any concerns about the depth or
     51breadth of the reviews that have been performed?
     53This document is the result of an effort which involved
     54both individuals with extensive experience with the Kerberos
     55cryptographic framework and those who have been involved in
     56specifying support for Camellia in other IETF protocols.
     57It has been extensively reviewed and discussed within the
     58working group, and all technical issues raised have been
     59resolved.  I have no concerns about the level of review
     60this document has received.
     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
     65took place.
     67I don't believe any particular external review is needed for this
     70(6) Describe any specific concerns or issues that the Document Shepherd
     71has with this document that the Responsible Area Director and/or the
     72IESG should be aware of? For example, perhaps he or she is uncomfortable
     73with certain parts of the document, or has concerns whether there really
     74is a need for it. In any event, if the WG has discussed those issues and
     75has indicated that it still wishes to advance the document, detail those
     76concerns here.
     78I have no particular concerns with this document.
     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.
     84All authors have confirmed that any required IPR disclosures have
     85been filed.
     87(8) Has an IPR disclosure been filed that references this document?
     88If so, summarize any WG discussion and conclusion regarding the IPR
     91I have no particular concerns about this document.  NTT
     92and Mitsubishi Electric have filed a joint IPR statement
     93#1304, related to use of Camellia in Kerberos.  Similar
     94disclosures had been filed previously related to IPsec,
     95TLS, S/MIME, and OpenPGP.  This issue has been discussed
     96briefly within the working group, and there were no
     97objections to proceeding with this work once the IPR
     98disclosure was filed.
     100(9) How solid is the WG consensus behind this document? Does it
     101represent the strong concurrence of a few individuals, with others
     102being silent, or does the WG as a whole understand and agree with it?
     104There is consensus within the working group to publish this document.
     106(10) Has anyone threatened an appeal or otherwise indicated extreme
     107discontent? If so, please summarise the areas of conflict in separate
     108email messages to the Responsible Area Director. (It should be in a
     109separate email because this questionnaire is publicly available.)
     111There have been no expressions of discontent.
     113(11) Identify any ID nits the Document Shepherd has found in this
     114document. (See and the Internet-Drafts
     115Checklist). Boilerplate checks are not enough; this check needs to be
     118This document has been run through the idnits tool, and was reviewed
     119manually for compliance with requirements not checked by the automatic
     122(12) Describe how the document meets any required formal review
     123criteria, such as the MIB Doctor, media type, and URI type reviews.
     125No formal review criteria apply to this document.
     127(13) Have all references within this document been identified as
     128either normative or informative?
     130References have been split appropriately.
     132(14) Are there normative references to documents that are not ready for
     133advancement or are otherwise in an unclear state? If such normative
     134references exist, what is the plan for their completion?
     136There are no normative references to other documents that are not
     137ready for advancement.
     139(15) Are there downward normative references references (see RFC 3967)?
     140If so, list these downward references to support the Area Director in the
     141Last Call procedure.
     143This document contains a normative reference to RFC3713,
     144and informational document which describes the Camellia
     145cipher.  We don't see a problem with this, even if the
     146document is published on the standards track, as this is
     147consistent with current practice within the IETF relating
     148to descriptions of cryptographic algorithms.
     150This document also contains normative references to two
     151NIST special publications.  While these are not IETF
     152documents, we feel they are suitably stable to be used as
     153normative references by a protocol specification.
     155(16) Will publication of this document change the status of any
     156existing RFCs? Are those RFCs listed on the title page header, listed
     157in the abstract, and discussed in the introduction? If the RFCs are not
     158listed in the Abstract and Introduction, explain why, and point to the
     159part of the document where the relationship of this document to the
     160other RFCs is discussed. If this information is not in the document,
     161explain why the WG considers it unnecessary.
     163This document does not change the status of any existing RFCs.
     164As noted in the abstract and introduction, this document does specify
     165new encryption and checksum types to be used within the framework
     166defined by RFC3961.  However, it does not make any changes to the
     167framework itself, and so does not update RFC3961.
     169(17) Describe the Document Shepherd's review of the IANA considerations
     170section, especially with regard to its consistency with the body of the
     171document. Confirm that all protocol extensions that the document makes
     172are associated with the appropriate reservations in IANA registries.
     173Confirm that any referenced IANA registries have been clearly
     174identified. Confirm that newly created IANA registries include a
     175detailed specification of the initial contents for the registry, that
     176allocations procedures for future registrations are defined, and a
     177reasonable name for the new registry has been suggested (see RFC 5226).
     179This document defines new Kerberos encryption and checksum
     180types, which require assignment of numbers in IANA-managed
     181namespaces.  The IANA considerations section correctly
     182identifies the required registrations.
     184(18) List any new IANA registries that require Expert Review for future
     185allocations. Provide any public guidance that the IESG would find
     186useful in selecting the IANA Experts for these new registries.
     188This document creates no registries requiring Expert Review.
     190(19) Describe reviews and automated checks performed by the Document
     191Shepherd to validate sections of the document written in a formal
     192language, such as XML code, BNF rules, MIB definitions, etc.
     194No part of this document is written in a formal language
     195requiring such verification.