On Mon, Mar 30, 2015 at 11:18 AM, Salz, Rich <[email protected]> wrote:
>> I am sorry but I disagree. This should have been fixed long time ago - no
>> Google private OIDs should have been put in a WG document in the first
>> place.
>
> Are you also bothered by the OID's in CMS S/MIME and other pkcs-derived RFC's?
... and the other N RFCs:
wkumari-macbookpro1:rfc-mirror wkumari$ grep '1.3.6.1.4' * | awk
'{print $1}' | sed 's/:.*//' | sort | uniq | wc -l
99
Sure, some of those include lists of assigned numbers, but we also
have things like:
RFC2079 - Definition of an X.500 Attribute Type and an Object Class to
Hold Uniform Resource Identifiers (URIs) (umichAttributeType.57)
RFC2601 - ILMI-Based Server Discovery for ATMARP (ATM Forum Service
Registry - atmfSrvcRegATMARP)
RFC4511 - Lightweight Directory Access Protocol (LDAP): The Protocol
(using 1.3.6.1.4.1.1466.1.2.3 - The description for 1.3.6.1.1466 says:
"This is an OID assignment to the person Mark Wahl. Many of the LDAPv3
OIDs are assigned below this point.")
We have a history of doing this. World hasn't ended yet...
W
>
> At any rate, Russ has already responded on the issue of existing OID's:
> leave as-is to avoid confusion and disrupting implementations.
>
> /r$
>
> _______________________________________________
> Trans mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/trans
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
