RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt

Your clarification describes the way that the IETF typically uses
requirements documents - as input/design considerations for creating
Standards Track specifications. To me, that's what makes it redundant.
This is typically the way that the IETF uses requirements documents, so
I personally see no point in expressing that explicitly in a
requirements
document.

Your clarification also presumes that further work on LDAP Access
Control
will place in the IETF. Based on how contentious the topic of Access
Control for LDAP and LDUP have been to date, I am not convinced that the
additional technical specifications you mention will actually be
developed
within the IETF even if their notions are conceived here. This is
precisely
why I keep leaving the LDUP Access control Design Team's "charter" a
little
open-ended. I want to leave room for such work to take place if they can
come up with a viable approach (e.g., an approach that the WG members
achieve consensus on as being viable for the Design Team to execute).
I will most certainly dissolve that design team if and when it becomes
obvious that this is not possible.

I do not agree with your statement about what the requirement implies.
The requirement as worded implies that it is the consistency with which
different implementations support the requirements documented in RFC
2820
that impacts the level of interoperability that you can expect between
LDAP systems from both a security and a general perspective.

If two implementations do claim to support those requirements, it will
be the degree of consistency in supporting them that makes or breaks
interoperability from a security perspective. That implication doesn't
require clarification in my opinion.

Whether work towards any additional required technical specifications on
which
those claims are based takes place in the IETF, an industry consortia
group, or by private interoperability agreements/testing between
LDAP/LDUP implementers, remains to be seen. And even though I'd prefer
that
it be handled within the IETF, I don't know how that's going to go down
so
to speak.  That is a topic that the LDUP Access Control Design
Team will have to consider during construction of its proposal to the
WG. There
was some discussion at the last WG meeting related to how feasible it
was
going to be to have a generalized LDAP ACM standard period. Largely
because
of that discussion, I don't want to presume what the design team will
produce.
They could very well produce alternate work programs for the WG to
consider - one
of which could be "do nothing in the IETF."

As co-chair, I don't want to *prematurely* put language in a
requirements
document attempting to constrain that path only to have it:

A) Not subsequently happen in the IETF.

AND/OR

B) Have to change the document should the work take place outside of the
IETF,
when such a change could be avoided by simply not making the
clarification
that you propose.

And while I don't see it to be of added value to the document, I would
personally
support your clarification if it indeed corresponds to the LDUP Access
Control Design
Team proposal/recommendation on which the WG achieves consensus (in the
interest of
moving the document forward).

I believe you and I have had our say on this matter. Its time for others
to chime in...

Chris Apple

[email protected]

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Kurt D. Zeilenga
Sent: Wednesday, March 06, 2002 1:36 PM
To: [email protected]
Cc: [email protected]
Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt



At 09:27 AM 2002-03-06, Chris Apple wrote:
>That wasn't a declaration of consensus - that was a process call on my 
>part. I don't think its appropriate to add language to a requirements 
>document that is redundant with IETF process. I do believe its OK to 
>add language that *refers* to IETF Process but personally find the 
>value in doing so to be marginal. Your language proposal
>appears to me to be redundant with IETF process rather than referring
to
>it.

I don't see how my clarification is redundant to IETF process.

My suggestion is intended to clarify the meaning of the statement.

As it written, it implies that RFC 2820 is a technical specification
which LDAP implementations can support and if they do so the security
consideration is addressed. However, as RFC 2820 places no requirements
on LDAP implementations and hence whether implementations support it or
not has no impact on the underlying security consideration.

With my clarification, statement would implies that the security
consideration is addressed by LDAP implementations supporting a future
LDAP ACM technical specification.

Kurt

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Chris Apple ([email protected])
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:214 New Street, Apt 4-N=0D=0APhiladelphia, PA 19106=0D=0AUnited States of Am=
erica
EMAIL;PREF;INTERNET:[email protected]
REV:20011217T233830Z
END:VCARD