Shepherd writeup

(1) This document is intended to be an Informational document.  This level is appropriate as it is just recording with IANA a set of operations that have been reflected in other documents.


Technical Summary:

This document transfers the ownership of the SMIME Object Identifier arc, originally donated by RSA Data Secureity, from the now defunct S/MIME working group to IANA.

Working Group Summary:

This would logically have been part of the S/MIME WG, however it went defunct a number of years ago before transfering the arc to IANA was considered to be an important thing to accomplish.  There has been no controversy on this document.

Document Quality:

The document consists of instructions for IANA to perform.  The document has been reviewed to ensure that the instructions make sense and match the existing assignments of object identifiers from previous documents.  

        Document Shepard - Jim Schaad
        Area Director - Sean Turner

(3) Review has not been totally completed yet.  Review consists of checking against all of the documents in which things were defined and making sure that the correct numbers have been used.  It is not expected that there will be any issues from that.

(4) I consider the review done on the document to be adequate.  I will have personally checked all of OIDs assigned and the opportunity for the S/MIME mailing list to do the same has been offered.  No errors in the document have been noted by the mailing list.

(5) The document consists of just IANA considerations.  No external review is needed.

(6) It is not clear that an ASN.1 module can be re-constructed from the registered data that matches the module that was historically maintained by Russ.  It is also not clear that this is something that needs to be done either.  Part of this may lie in a difference in understanding of the ASN.1 specifications between myself and Russ and part of it may lie in a difference of what is desirable.  I plan to do some follow up with IANA during the next IETF meeting to see about the possibility of generating modules based on the registries in an automated fashion which might lead to some interesting questions.

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

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

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

(10) Nobody has expressed any discontent with the document, therefore no problems are expected.

(11) The document currently has a couple of nits to be fixed:
* Missing reference for RFC3161
* Missing reference for RFC5272

NITs does note that there are number of obsoleted documents that are referenced in the document.  It is an interesting discussion if the original documents that assigned the points should be referenced or the most current ones.

(12) The document has no requirements for formal review.

(13) No - two references are missing.

(14) All references to works in progress are informational references.  All normative references are finalized and published.

(15) No downward references exist.  It is n informational document.

(16) This is a first time document and does not affect any currently published RFCs.

(17) The body of the document does not have any assignemnts per se.  There has been a check against the other documents referenced where the assignments were originally done that they match the IANA considerations text.  Some of the assignments made are to obsolete points that never had finalized documents and as such are assigned for the first time in the IANA sections of this document.  There are all marked as reserved anand obsolete.

(18) This document creates 14 new IANA registries that require Expert Review.  (the purpose of the document is solely to create these registries).  Historically the person that was the effected expert reviewer is the author and he should be included on the list.  Additional people added as experts should be knowledgeable in S/MIME and the words that are associated with that groups output as new registrations should be related to work from that group.

(19) No formal language exists in the document.  A discussion was held about including an ASN.1 module that matched the assignments requested and it was decided that it would have no long term usefulness so it is not included.