Re: Use of private OIDs in WG (standard-track) documents

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]