Dear  all, I have reviewed this document as part of the security directorate's ongoing effort to for early review of WG drafts.  These comments were written primarily for the benefit of the security area directors.  Document editors and working group chairs should treat these comments just like any other comments.   Section 1: Please expand ToR upon first occurrence.   Section 2, page 3/4: Could you please clarify the difference between "node" and "end station"? Are they synonyms?     Section 5.1.1:   Shouldn't it be possible to avoid ND load by proper setting of the ReachableTime variable? -- This wouldn't require any protocol changes.     Section 5.1.1:   Snooping ARP packets probably means increased load (a disadvantage you didn't mention).     Section 5.1.1:   When address resolution is needed to deliver a packet, some routers just drop the packet when they engage in ARP (see http://tools.ietf.org/html/rfc6274#section-4.2.3 ). The same is true for IPv6 ND.     Section 8:   While this document does not introduce new issues itself, it should at least mention how the same ARP/ND issues may be intentionally triggered by an attacker. For example, you may reference RFC 6583     * Nits   Section 4, page 4: > There are no address >    resolution issue in this design.   Replace "issue" with "issues"     Section 5.1.1, page 5:   "Ipv6" -> "IPv6"     Section 5.1.2:   Please expand UNA (possibly in the terminology section) -- you probably mean "Unsolicited..", but this should be explicit.     Thank you, Tina   From: secdir [mailto:secdir-bounces at ietf.org] On Behalf Of Matthew Lepinski Sent: Friday, February 14, 2014 2:52 AM To: secdir at ietf.org; iesg at ietf.org; draft-housley-pkix-oids.all at tools.ietf.org Subject: [secdir] SECDIR review of draft-housley-pkix-oids   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 working group chairs should treat these comments just like any other last call comments.   This document returns control of the PKIX object identifier arc to IANA. That is, it establishes a new IANA registry for OIDs in the PKIX arc and populates that registry with the existing OID assignments. Finally, the document establishes expert review as the criteria for future additions to the registry and includes guidance that for review.   After reviewing the document, I agree with the author that this document introduces no new security concerns.    I found no issues in the document and I believe it is ready for publication.   -------------------------------   Nits   The author should consider including an expansion of the acronym SMI, which is used frequently in the document. (I believe in this context SMI = Structure of Management Information)   In Section 3: s/ be related to X.509 certificate/be related to X.509 certificates/   In Section 3.1:  s/ to points to this document/to point to this document/