Subject: FW: I-D ACTION:draft-ietf-ldapbis-iana-01.txt

From: "Skovgaard, Erik" <[email-masked]>
Date: Fri, 20 Apr 2001 09:10:39 -0700

Kurt,

I like this document.  Good initiative!

Suggest adding some verbiage to REQUIRE the use of IANA registered OIDs in
LDAP-related RFCs.  I have seen way too many private and non-coordinated
OIDs in the past.  I think this practice should be discouraged since OIDs
that are "owned" by a private organization is not guaranteed to be unique
and the definition could be changed without proper review.

Non-coordinated OIDs do not even deserve a comment ;-)

Cheers,                       ....Erik.

Erik Skovgaard
Siemens Meta-Directory Solutions
Phone: +1 604-204-0750
Fax:   +1 604-204-0760

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 13, 2001 04:16
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ldapbis-iana-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the LDAP (v3) Revision Working Group of the
IETF.

	Title		: IANA Considerations for LDAP
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-ldapbis-iana-01.txt
	Pages		: 17
	Date		: 12-Apr-01
	
This document provides procedures for registering extensible elements
of LDAP.  The document also provides guidelines to IANA describing
conditions under which new values can be assigned.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-iana-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapbis-iana-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapbis-iana-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Fri, 20 Apr 2001 09:12:18 -0700

---

From: "Ryan Moats" <[email-masked]>
Date: Fri, 20 Apr 2001 11:59:51 -0500

>Suggest adding some verbiage to REQUIRE the use of IANA registered OIDs >in
LDAP-related RFCs.  I have seen way too many private and non-
>coordinated OIDs in the past.  I think this practice should be
>discouraged since OIDs that are "owned" by a private organization is
>not guaranteed to be unique and the definition could be changed without
> proper review.
>

I assume you mean standard track RFCs.  other track RFCs should allow
private OID spaces.

Ryan

---

From: Bruce Greenblatt <[email-masked]>
Date: Fri, 20 Apr 2001 10:18:32 -0700

>and the definition could be changed without proper review.

I strongly disagree.  OIDs allocated under the private enterprise branch 
can only serve to expedite the standardization process.  Once the OID is 
defined and used by the public in an RFC what possibly could be gained by 
changing the OID to another value.  There are many OIDs that have been 
allocated under the private enterprise branch in the past that are now 
widely used.  Keep the language in the draft intact.  It is good the way 
that it is.

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: "Alexis Bor" <[email-masked]>
Date: Fri, 20 Apr 2001 14:01:59 -0400

I tend to agree with Bruce.  It would be chaos if we had to go back to
change OIDs after something is already deployed.  Suddenly we will have a
lot of broken server implementations.  We will lose interoperability between
versions from the same vendor, as well as the many applications that depend
on it.

I suspect that there are many implementations that store the OIDs in the
data store.  Can you imagine the chaos of systems that have over 1,000,000
entries and numerous replicated servers when you try to transition the
directory to the new OIDs?

I wonder how many directory server products out there support changing OIDs?
We need to work to get these different implementations to work more closely
together and not try to tear apart the whole industry.  We have had such
great momentum with directory over the past few years, lets not lose it now.

* Alexis Bor
* Directory Works, Inc.
* Home of ActiveLDAP - www.directoryworks.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bruce Greenblatt
Sent: Friday, April 20, 2001 1:19 PM
To: [email-masked]'
Subject: Re: FW: I-D ACTION:draft-ietf-ldapbis-iana-01.txt

Bruce

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 20 Apr 2001 12:56:48 -0700

>I assume you mean standard track RFCs.  other track RFCs should allow

And private extensions can become Standard Track... so we need
to allow private OID spaces in Standard Track documents.  I think
this issue is better resolved not through registration procedures
but through expert/community review (and guidelines for extensions).
One needs to balance the desire to use a previously assigned OID
or a new IETF-assigned OID for a particular item upon IETF
publication (on any track).

I think operational experience has shown that the use of private
OIDs in Standard Track documents has not lead to interoperability
problems.   However, I think there is operational experience that
changing OIDs after initial specification has been implemented to
any significant degree does cause interoperability problems.

Kurt