Skip to main content

Last Call Review of draft-housley-ltans-oids-00
review-housley-ltans-oids-00-secdir-lc-kivinen-2013-07-12-00

Request Review of draft-housley-ltans-oids
Requested revision No specific revision (document currently at 01)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-07-31
Requested 2013-07-05
Authors Russ Housley
I-D last updated 2013-07-12
Completed reviews Genart Telechat review of -01 by Wassim Haddad
Secdir Last Call review of -00 by Tero Kivinen (diff)
Assignment Reviewer Tero Kivinen
State Completed
Request Last Call review on draft-housley-ltans-oids by Security Area Directorate Assigned
Reviewed revision 00 (document currently at 01)
Result Has nits
Completed 2013-07-12
review-housley-ltans-oids-00-secdir-lc-kivinen-2013-07-12-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document fills up the LTANS ASN.1 OID arc in the IANA registry.
It adds some values and points them to published RFCs, and also
reserves some values where there was never RFC published for those
protocols.

For some reason some of values include two OIDs, one for the 1997  and
another 1988 ASN.1 syntax. I do not know enough of LTANS to understand
why this distinction needs to be made in the OIDs themselves, I only
assumed this affected the compilers and textual descriptions of the
ASN.1 stuff, but perhaps OIDs here are used to indicate some ASN.1
text module or something.

The security considerations section is very short:

   This document populates an IANA registry, and it raise no new
   security considerations.  The protocols that specify these values
   include the security considerations associated with their usage.

While this is true, it might be helpful to add references to the
actual protocols it is refering here. The list of relevant RFCs can be
found in the IANA considerations section, but adding pointers here
might be helpful. I have not checked out whether the security
considerations sections in those documents contain anything useful.

One odd thing is that all registries are marked as "Expert Review or
IESG Approval", but which one of those is used? Is this supposed to
mean that if IESG appoints a designed expert for these, then he does
checks the updates, but if not, then IESG approval is needed? Or is it
mean to say that even when there is designated expert, the IESG and
ignore him and do the approval themselves (in which case I Would ask
what is the point of having the designated expert)?

Usually there is only one way of doing the IANA updates.
-- 
kivinen at iki.fi