Re: Use of private OIDs in WG (standard-track) documents
Massimiliano Pala <director@openca.org> Sat, 28 March 2015 16:05 UTC
Return-Path: <director@openca.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212AC1A8965 for <ietf@ietfa.amsl.com>; Sat, 28 Mar 2015 09:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lucjGXYA5aZ7 for <ietf@ietfa.amsl.com>; Sat, 28 Mar 2015 09:05:09 -0700 (PDT)
Received: from server.hackmasters.net (cl-757.qas-01.us.sixxs.net [IPv6:2001:4830:1600:2f4::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F881A8963 for <ietf@ietf.org>; Sat, 28 Mar 2015 09:05:08 -0700 (PDT)
Received: from nyc.openca.org (unknown [192.168.101.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by server.hackmasters.net (Postfix) with ESMTPS id 8173B41D6D for <ietf@ietf.org>; Sat, 28 Mar 2015 17:05:05 +0100 (CET)
Received: from localhost (unknown [127.0.0.1]) by nyc.openca.org (Postfix) with ESMTP id 14245154C7A2 for <ietf@ietf.org>; Sat, 28 Mar 2015 16:05:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at openca.org
Received: from nyc.openca.org ([127.0.0.1]) by localhost (blackmamba.openca.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05K3-Q_uGrf7 for <ietf@ietf.org>; Sat, 28 Mar 2015 12:05:02 -0400 (EDT)
Received: from iMassi.local (unknown [172.56.6.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by nyc.openca.org (Postfix) with ESMTPSA id 5160B154C234 for <ietf@ietf.org>; Sat, 28 Mar 2015 12:05:01 -0400 (EDT)
Message-ID: <5516D125.4080406@openca.org>
Date: Sat, 28 Mar 2015 11:04:53 -0500
From: Massimiliano Pala <director@openca.org>
Organization: OpenCA Labs
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Use of private OIDs in WG (standard-track) documents
References: <55163324.6030504@openca.org> <CAMm+Lwirfg8Z+TAwCU76Evqzv-6kfUB2UczaW6fn3BYyvNP1Og@mail.gmail.com> <5516B0DC.4060401@openca.org> <5516B822.2020100@cs.tcd.ie>
In-Reply-To: <5516B822.2020100@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="------------070200080009040205030409"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/jwgtd3ZBuJwwKjTeA7Z7t5voGFk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Mar 2015 16:05:13 -0000
Hi Stephen, all, it seems that lately we do not agree on many positions :-( However, my concern is about a procedure and I do think asking for a "standardized" approach to how OIDs should be presented in RFCs is not a bad idea. Why this discussion would be counter productive ? Anyhow, I did not ask to start a discussion (this could be useful, IMHO), all I asked is "what is the official position of IETF." - if there is none, then we might talk about starting this discussion. When I saw the WG document, I was surprised to see the use of OID raw values directly in the document - there was no mention about the fact that the selected OID values were under a private subtree (Google), something that I have never seen before in a WG document in the past 15yrs. I want to point out that, in this specific case, there was no mention of the OIDs in the IANA section. My guess is that the authors felt that there was no need to ask IANA to assign an OID since the used value is already in control under its own private sub-tree. Since this document is in its -06 version, I guess this was approved by the WG chair(s). /*If this is a perfectly viable option*/, that it should be made clear. /*If this is not the desired approach*/, also that should be made clear. I do not understand why _/*asking for an official position about this would*/__/* */__/*be an issue*/_ - it is perfectly ok to say "IETF does not care about what OIDs are inside RFCs". I have a preferred approach, but here I am just asking if we can get an official position about the topic. Are we not allowed to ask for clarifications anymore ? Therefore,*I do reiterate my request for an official position about this issue*. This is in the interest of having a clear understanding of what the desired procedure (or what is the current best-practice) is and what principle should be followed within the IETF community. Coming to my specific concern, I see potential issues in allowing values from different (especially private) sub-trees that are not related to each other for OIDs that clearly belong together (e.g., extensions for PKIX protocols and data structures - OCSP messages and X509 Certificates - should, logically, be under the PKIX OID) might create confusion and it would be quite difficult to have a clear understanding of OIDs used in a particular area - very common engineering principle. This is why, and this is my personal opinion, a coherent approach is, IMHO, paramount. Thanks, Max On 3/28/15 9:18 AM, Stephen Farrell wrote: > Max, > > On 28/03/15 13:47, Massimiliano Pala wrote: >> I think that allowing this as a common practice is a bit dangerous. > What danger do you perceive here? I'm not seeing it. Nor do I see any > need at all for an "official" IETF-wide position, and in fact, such a > position is quite likely to be counterproductive IMO. > > And as Phill said, re-numbering, if it breaks code, isn't a good > plan. Asking if it would break code, etc. on the trans list, is a > totally reasonable question btw and that discussion is already > happening there. > > S. > > PS: This isn't about a MIB, but a PKI thing.
- Use of private OIDs in WG (standard-track) docume… Massimiliano Pala
- Re: Use of private OIDs in WG (standard-track) do… Phillip Hallam-Baker
- Re: Use of private OIDs in WG (standard-track) do… Massimiliano Pala
- Re: Use of private OIDs in WG (standard-track) do… Thomas D. Nadeau
- Re: Use of private OIDs in WG (standard-track) do… Stephen Farrell
- Re: Use of private OIDs in WG (standard-track) do… Phillip Hallam-Baker
- Re: Use of private OIDs in WG (standard-track) do… Leif Johansson
- Re: Use of private OIDs in WG (standard-track) do… Massimiliano Pala
- Re: Use of private OIDs in WG (standard-track) do… Viktor Dukhovni
- Re: Use of private OIDs in WG (standard-track) do… Phillip Hallam-Baker
- ***UNCHECKED*** Re: Use of private OIDs in WG (st… Stephen Farrell
- Fwd: Re: Use of private OIDs in WG (standard-trac… Stephen Farrell
- Re: Use of private OIDs in WG (standard-track) do… Sean Turner
- Re: Use of private OIDs in WG (standard-track) do… Nico Williams
- Re: Use of private OIDs in WG (standard-track) do… Melinda Shore
- Re: Use of private OIDs in WG (standard-track) do… Stephen Farrell
- Re: Use of private OIDs in WG (standard-track) do… Nico Williams
- Re: Use of private OIDs in WG (standard-track) do… Phillip Hallam-Baker
- Re: [Trans] Use of private OIDs in WG (standard-t… Rob Stradling
- Re: Use of private OIDs in WG (standard-track) do… Viktor Dukhovni
- Re: Use of private OIDs in WG (standard-track) do… Martin Rex