Skip to main content

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

(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

(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

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