Re: Introducing a Directory Service rejected as BCP

Harald.T.Alvestrand@uninett.no Tue, 13 February 1996 09:02 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09224; 13 Feb 96 4:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09220; 13 Feb 96 4:02 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03530; 13 Feb 96 4:02 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09213; 13 Feb 96 4:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09209; 13 Feb 96 4:02 EST
Received: from domen.uninett.no by CNRI.Reston.VA.US id aa03523; 13 Feb 96 4:02 EST
Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <15041-0@domen.uninett.no>; Tue, 13 Feb 1996 10:02:24 +0100
X-Mailer: exmh version 1.6.5 12/11/95
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald.T.Alvestrand@uninett.no
To: Russ Wright <Wright@lbl.gov>
cc: "Erik Huizer (SURFnet ExpertiseCentrum bv)" <Erik.Huizer@sec.nl>, ietf-ids@umich.edu, iesg@CNRI.Reston.VA.US
Subject: Re: Introducing a Directory Service rejected as BCP
In-reply-to: Your message of "Mon, 12 Feb 1996 08:52:56 PST." <v02140b05ad451c9faeb4@[131.243.64.16]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 13 Feb 1996 10:02:21 +0100
X-Orig-Sender: Harald.T.Alvestrand@uninett.no
Message-ID: <9602130402.aa03523@CNRI.Reston.VA.US>

(this message is for clarifying elements of IETF procedure, not directly
relevant to the matter at hand)

> Russ Wright:
> 
> Well, I wasn't going to say anything until I saw that the 2 whois++
> documents are going to proposed standard.  Where is the implementation
> experience for any of the indexing stuff?  What is required for the
> indexing document to go to full standard?  How widely deployed does it have
> to be?  It would be nice to have a consistent set of rules that we all play
> by.
Running code is not required for Proposed Standard; check RFC 1602.

BCP was intended for those items where the standards process isn't really
appropriate, for instance in recommendations ("an appeal to the Internet 
community
to return unused address prefixes") or procedures (RFC 1602) where it would
not be possible to have multiple standards operative at the same time, so
that the normal obsoletion process described in 1602 (old standard remains
Standard until the new one reaches Standard maturity) is not appropriate.

Paul Mockapetris' view was that our slogan "Rough Consensus and Running Code"
in this context at least meant that we thought it was reasonably possible to
practice the recommendation or procedure given in the document.

(Parenthesis: The next fight over a BCP will be over the CIDRD "address 
ownership" document, where exactly this question - whether it is reasonable to 
ask people to follow its recommendation - is at the heart of the debate)

> 
> IDS' was created because we all realized that one directory service was not
> going to be the clear winner.  How do we "Integrate Directory Services" if
> the IESG puts one (X.500) in a lower class than the other (whois++)?
> 
Actually, X.500 is not under the control of the IETF, so we can't make
it a Proposed Standard.
We can make profiles on it (1274, Cosine & Internet Schema) or other stuff 
referencing it (LDAP, MADMAN Directory MIB) and make that a proposed standard.
This is a formal issue, and has no forcing power in what we recommend.
(NOTE: I did NOT say that it doesn't help shape people's opinions!)

                Harald A