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

mrex@sap.com (Martin Rex) Wed, 01 April 2015 18:13 UTC

Return-Path: <mrex@sap.com>
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 AC42D1A8A1C for <ietf@ietfa.amsl.com>; Wed, 1 Apr 2015 11:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 ZAOAtvEr4Edh for <ietf@ietfa.amsl.com>; Wed, 1 Apr 2015 11:13:06 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5067D1A8A1A for <ietf@ietf.org>; Wed, 1 Apr 2015 11:13:06 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id B43502AC7C; Wed, 1 Apr 2015 20:13:03 +0200 (CEST)
X-purgate-ID: 152705::1427911984-00003099-FD3EF086/0/0
X-purgate-size: 2518
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 9AA6946BE5; Wed, 1 Apr 2015 20:13:03 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9463E1B259; Wed, 1 Apr 2015 20:13:03 +0200 (CEST)
Subject: Re: Use of private OIDs in WG (standard-track) documents
In-Reply-To: <CAMm+LwhBV6FU_qAxDckZwSyBGVGd0T=hFj==w_7e2Mi+xm5hQA@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 01 Apr 2015 20:13:03 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150401181303.9463E1B259@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ULNBECSn690g9d5l4c8HQzYyr5g>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 01 Apr 2015 18:13:08 -0000

Phillip Hallam-Baker wrote:
>
>Stephen Farrell wrote:
>>
>> On 30/03/15 20:29, Nico Williams wrote:
>>>  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,
>>
>> See RFC7120 and RFC7299 (as Russ pointed out on the trans list).
>> We have those procedures now.
>>
>> There is still, however, no real issue to be dealt with here.

I do not see the problem either.  It doesn't matter which arc the OIDs
come from.  The only two issues that matter

  (a) the OID must be unique, i.e. not be reused with a different
      meaning _in_the_same_context_.  Reuse of the OID for different
      purpses in other contexts does not matter.

  (b) the assignment ought to be permanent from the start.
      Having to "renumber" (i.e. migrate to a different codepoint
      in an installed base) is awful and must be avoided.
      So yes, a project-based early assignment process is required.


> 
> We might be making the situation worse however by insisting that IANA
> issue OIDs to organizations rather than for projects. This is one of
> the few instances where IANA is acting as a non-IETF registry on
> behalf of the (now defunct) ITU-T.
> 
> If we had a registry for projects, people could take an OID arc for
> their project. Use it in private space during development and then
> transfer control to the IETF or W3C or OASIS or wherever if the
> project turns into a standards track effort.
 
Huh?

Look here:

  http://www.alvestrand.no/objectid/1.3.6.1.html

While IANA does provide Enterprise/Organization based OID arcs under
private.enterprises (1.3.6.1.4.1), it also has registries for
other purposes under 1.3.6.1, and has been using it for two decades,
such as technology-related assignments under security (1.3.6.1.5).


The problem with organizational OID arcs, as originally conceived by ITU-T,
is that they had the model of an arc "lease" through their national member
body, rather than a permanent assignment -- and for premium fees (in the
ballpark of $4000/year per organization).  Unsurprisingly, this approach
was not terribly attractive.


Instead, folks got a registration under IANA's "private.enterprises" for free,
and started assigning OIDs below those arcs for stuff other than SNMP.
You avoid the ITU-T fee/lease, and pay in size/network bandwidth for
larger OIDs in (protocol) PDUs.


-Martin