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