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