Subject: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"

From: [email-masked]
Date: Mon, 26 Jun 2000 00:08:47 -0700

RFCs 2829 and 2830 were recently published, nominally meeting the IESG's 
requirement for rescinding the "IESG Note" gracing the first pages of RFCs 
2251..2256. Patrick has indicated that we can address the "Note" by publishing 
an RFC that "updates" 2251..2256.

Additionally, we've spoken at various times of a "core" set of LDAPv3 RFCs, 
nominally represented by 2251..2256 (plus the two I-Ds that have become 2829 
and 2830) but this has never been formally defined.

The attached I-D is a draft for an "applicability statement" (see RFC 2026 
section 3.2) both rescinding the Note and defining the set of RFCs 
constituting LDAPv3.

We're suggesting that LDAPEXT work to refine this I-D and submit it for 
Standards Track. This will clarify what constitutes LDAPv3 as presently 
specified and help mitigate any issues that might have arisen due to the "IESG 
Note".

May we please add this item to the Pittsburgh LDAPEXT agenda?

thanks,

Jeff Hodges & RL "Bob" Morgan

---

From: [email-masked]
Date: Thu, 29 Jun 2000 12:53:23 -0700

[email-masked] said:
> if the effort required to produce 2251-2256 is set at 10, I'd say the
> effort to issue followups to them is a 5, and we're hoping the effort
> required to get this applicability statement out the door and
> officially remove the IESG warning is a 1. 

Yep.

> doing revised versions of the base docs is A Good Thing To Do, but
> even deciding whether to recycle them at Proposed or move to Draft is
> likely to be contentious.  

Yep.

There's quite a few substantial mods to the docs in the queue in terms of how 
the different facets of LDAP are addressed in which RFCs, plus there are 
various "bug fixes" and enhancements in the pipeline for the protocol itself 
that'd arguably call for bumping the version number (v3.x or v4 or whatever).

So we feel that, as Bob is essentially saying, it makes sense to tie-up the 
outstanding loose ends of explicitly defining LDAPv3 as we presently know it 
and rescind the IESG Note.

We can be moving ahead in parallel with deciding whether we take LDAPv3 (as 
defined by the AS) to Draft (and what that means in terms of what needs to be 
fixed and/or enhanced (or not)), or whether we want/need to begin sketching 
out LDAPv3bis (as Kurt put it) as the follow-on to LDAPv3, or we want/need to 
do something in between or a combination of the two.

But let's get these present two loose ends crisply resolved.

thanks,

JeffH