On Mon, Mar 30, 2015 at 02:43:40PM -0400, Sean Turner wrote: > I’m with Victor and don’t see the issue. We’ve got standards track > RFCs with OIDs from NIST, Certicom, RSA, and “infosec” and those are > just the ones I can come up with off the top of head. I agree. We also have experience with the effects of changing such protocol constants at publication time: - The Kerberos V GSS-API mechanism (RFCs 1964 and 4121). Many implementations still embed old OIDs. I wasn't around then but the transition to the new OIDs must have broken acceptor implementations. - IPsec NAT traversal (which had a constant that changed with each version of the I-D). and probably others. As a matter of taste it might be better to use IETF OID space, but that would effectively require having procedures for *early* IANA assignment of IETF OID arcs to upcoming Internet-Drafts. As it is I don't think we have procedures for that, therefore it should be no surprise that we see non-IETF OID arc assignment in Internet-Drafts and RFCs. I see this as a pre-requisite. Anyone wanting us to use IANA-assigned OID arcs exclusively.. should submit, and see through to publication, an Internet-Draft providing for such early assignment. Nico --