In this case, the document was published with OIDs from a non-IETF OID arc long ago. I see no reason to disrupt those implementations, and in fact, having two OIDs with exactly the same semantics is confusing.
If new OIDs are needed, we ought to assign them from an IETF arc managed by IANA. Russ On Mar 28, 2015, at 1:14 AM, Massimiliano Pala wrote: > Hi Rich, > > I do not think there is any precedence about using private OIDs for I-Ds - > the use of Google's OIDs is ok at Google, not for a standard. The first > reason is because Google's controls its own sub-tree and can change the sub > tree at any time - not appropriate for an RFC. The second reason is that, > since the document is defining extensions for certificates and OCSP messages > (both under PKIX), the natural place is actually under PKIX. > > I also want to point out that OIDs are not just opaque identifiers - if that > was the case, we would not use a hierarchical structure. The sub-tree where > the OID is is actually important. > > This said, I have two questions for you: > Why this would not be the appropriate base OID ? > Which base OID are you referring to when you say "under IETF" ? > Cheers, > Max > > > On 3/27/15 10:58 PM, Salz, Rich wrote: >> OID’s are just distributed opaque identifiers. Doesn’t bother me, but if >> the WG wants to change OID’s and break deployed software, go for it >> >> It will might be hard to get a PKIX arc. A Trans arc under IETF seems more >> feasible. >> >> -- >> Senior Architect, Akamai Technologies >> IM: [email protected] Twitter: RichSalz >> >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
