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:
1. Why this would not be the appropriate base OID ?
2. 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
