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

From: [email-masked]
Date: Tue, 05 Mar 2002 06:23:14 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF.

	Title		: LDAPv3 Replication Requirements
	Author(s)	: E. Stokes, R. Weiser, R. Moats, R. Huber
	Filename	: draft-ietf-ldup-replica-req-11.txt
	Pages		: 30
	Date		: 04-Mar-02
	
This document discusses the fundamental requirements for replication of 
data accessible via the Lightweight Directory Access Protocol (version 
3) [RFC2251].  It is intended to be a gathering place for general 
replication requirements needed to provide interoperability between 
informational directories.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-11.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ldup-replica-req-11.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-ldup-replica-req-11.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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 05 Mar 2002 20:29:00 -0800

In reviewing this latest revision to see if the changes
reflect WG input, I find that the following new text in
the the Security Consideration section makes no sense.

  Security- related and general LDAP interoperability will
  be significantly impacted by the degree of consistency
  with which LDAP implementations support the access
  control requirements [RFC2820]. 

RFC 2820 does not provide a technical specification or
otherwise make requirements upon LDAP implementations.
It places requirements upon LDAPext engineering work.
That is, RFC 2820 has itself zero impact on LDAP
interoperability.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Wed, 6 Mar 2002 09:41:03 -0500

I have read RFC 2820 5 times this morning and cannot find a statement
in it that supports your claim.

Consider the document's abstract:

Abstract

   This document describes the fundamental requirements of an access
   control list (ACL) model for the Lightweight Directory Application
   Protocol (LDAP) directory service.  It is intended to be a gathering
   place for access control requirements needed to provide authorized
   access to and interoperability between directories.

Given that summary of RFC 2820, I don't follow your claim that
the text from the security considerations section makes no sense.

Chris Apple

[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kurt D. Zeilenga
Sent: Tuesday, March 05, 2002 11:29 PM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ldup-replica-req-11.txt

RFC 2820 does not provide a technical specification or otherwise make
requirements upon LDAP implementations. It places requirements upon
LDAPext engineering work. That is, RFC 2820 has itself zero impact on
LDAP interoperability.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 06 Mar 2002 07:36:42 -0800

>in it that supports your claim.

Much like the LDUP Requirements I-D, RFC 2820 is NOT a protocol
technical specification.  It outlines design requirements
which engineers of a technical specification should consider.

The statement "LDAP implementations support the access
control requirements [RFC2820]" makes no sense as
RFC 2820 makes no requirements upon LDAP implementations.

Now, the statement could be rewritten:
  Security- related and general LDAP interoperability will
  be significantly impacted by the degree of consistency
  with which LDAP implementations support a future Standard
  Track technical specification meeting Access Control
  Requirements for LDAP [RFC2820]. 

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Wed, 6 Mar 2002 10:59:44 -0500

The proposed re-write of the text in question doesn't add any value to
the document in my opinion. Since the LDUP requirements document and
RFC 2820 are both informational and are both requirements documents, I
see no harm in one referring to the other in the Security Considerations
section as currently written.

The clarification that you are seeking to include is already well
understood and I believe redundant with existing IETF process.
As a co-chair, I don't feel inclined to add the language revision you
propose to this document at this time. You are of course free to post
such a comment in response to the IETF Last Call for the LDUP
requirements
document.

As an example of how this language revision could be perceived as
redundant
with existing IETF process, keep this in mind:

One potential output of the LDUP Access Control Design Team could be
such
a standards-track technical specification, albeit likely constrained to
the
minimal subset of those requirements needed to address access control
relative
to LDAP replication.

Chris Apple

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, March 06, 2002 10:37 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ldup-replica-req-11.txt

Much like the LDUP Requirements I-D, RFC 2820 is NOT a protocol
technical specification.  It outlines design requirements which
engineers of a technical specification should consider.

Kurt

>Given that summary of RFC 2820, I don't follow your claim that the text

>from the security considerations section makes no sense.
>
>Chris Apple
>
>In reviewing this latest revision to see if the changes reflect WG 
>input, I find that the following new text in the the Security 
>Consideration section makes no sense.
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 06 Mar 2002 08:48:00 -0800

>understood and I believe redundant with existing IETF process.

I disagree.  Some will read that statement as imply that there
is already an LDAP ACM technical specifications which LDAP
implementations can support.  As this is a security consideration,
I believe it needs to be clear that it is referring to a future
technical specification which meets the requirements stated
in RFC 2820.

>propose to this document at this time.  

Well, I'm inclined to disagree with you.  The editor has made a
substantive changes to the I-D.  Regardless of what they were in
response to, this WG must be given an opportunity to review those
changes.  If the WG does not agree with the changes, the document
must be changed to reflect the WG consensus.

Given that the WG has yet been given an opportunity to review
these changes, I think it is premature for you to declare
consensus in regards to these changes.

I certainly have not had time to review all the changes made,
the document revision was only recently announced.  I recommend
you give the working group two weeks to review the recent changes
and comment.

>a standards-track technical specification,

I do not believe the LDUP Access Control Design Team is presently
chartered to undertake engineering of any technical specification.
If I am mistaken, please advise.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Wed, 6 Mar 2002 12:27:30 -0500

>Sent: Wednesday, March 06, 2002 11:48 AM

>>see no harm in one referring to the other in the Security 
>>Considerations section as currently written.
>>

>I disagree.  Some will read that statement as imply that there is
already an LDAP ACM technical specifications which LDAP implementations
can support.  As this is a security consideration, I believe it needs to
be clear that it is referring to a future technical specification which
meets the requirements stated in RFC 2820.

substantive changes to the I-D.  Regardless of what they were in
response to, this WG must be given an opportunity to review those
changes.  If the WG does not agree with the changes, the document must
be changed to reflect the WG consensus.

>Given that the WG has yet been given an opportunity to review these
changes, I think it is premature for you to declare consensus in regards
to these changes.

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.

WG members could establish a consensus otherwise - and that would indeed
require discussion about the topic on the list.

I'm watching...

>I certainly have not had time to review all the changes made, the
document revision was only recently announced.  I recommend you give the
working group two weeks to review the recent changes and comment.

I consider WG review of changes made to the document to have started
today. 2 weeks sounds like a reasonable interval to me.

>>such a standards-track technical specification,

>I do not believe the LDUP Access Control Design Team is presently
chartered to undertake engineering of any technical specification. If I
am mistaken, please advise.

>Kurt

Per my earlier postings on this topic and pending the meeting the Design
Team will have this week, the "charter"
for the Design Team will be presented during the LDUP WG meeting as a
proposal. For now and until the WG establishes
consensus on the LDUP Access Control Design Team "charter" proposal, the
Design Team's "charter" is to devise a
terse mission statement, draft work program, and present both to the WG.
One *possible* outcome from the
Design Team's presentation to the WG could be that the WG establishes
consensus that certain technical specifications
related to Access Control be written by the Design Team members and
presented to the WG for consideration. Please note
my use of the word "potential" in the original posting. The statement in
my original posting on this topic is consistent
with my prior postings on the topic of LDUP Access Control Design Team
"charter."

Chris.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 06 Mar 2002 10:14:17 -0800

Well, the problem I have is that you seem to have formed
one design team to address multiple issues, some which
are not yet relevant to the WG.  I think it would be
better to charter one team to address "to devise a
terse mission statement, draft work program, and present
both to the WG" and, if accepted by WG consensus
AND approved by the IESG, form a second design team to
address subsequent issues.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 06 Mar 2002 10:35:55 -0800

>appears to me to be redundant with IETF process rather than referring to

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

---

From: "Chris Apple" <[email-masked]>
Date: Wed, 6 Mar 2002 16:36:47 -0500

In my postings, I've made it progressively more clear that the Design
Team
is chartered in the short term to do what you propose for an initial
design
team below. I have also made it clear that whether or not this same
Design Team
goes on to do additional work will be left to Working Group consensus. I
suppose it
is possible that the Design Team's membership will change drastically
and therefore
effectively become a "second design team." But I don't think it would be
prudent of
me to pre-judge working group consensus on this matter by explicitly
stating that
a second design team will be formed.

I have based my strategy for addressing access control for LDUP on my
own interpretation
of how to use design teams as a means of addressing controversial or
contentious issues.
I am assuming that your text below represents your interpretation of the
same.

We obviously differ in opinion about how explicit we need to be about
what happens
after the Design Team completes their initial work - which may *or* may
not turn out
to be their final input to the WG.

As the co-chair, I'm making a choice about being explicit about the
initial
deliverable to the WG. Whether that same Design Team goes on to do more
work as an
entity, dissolves, changes membership, etc. is a matter that, as
co-chair, I would
like to have the WG consider once we have a concrete proposal that we
can discuss.

The above is consistent with my prior postings on this topic.

Chris Apple

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, March 06, 2002 1:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: design teams (RE: I-D
ACTION:draft-ietf-ldup-replica-req-11.txt)

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Wed, 6 Mar 2002 17:33:08 -0500

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

-----Original Message-----
Sent: Wednesday, March 06, 2002 1:36 PM

At 09:27 AM 2002-03-06, Chris Apple wrote:
>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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 06 Mar 2002 15:58:12 -0800

>document attempting to constrain that path only to have it:

This is actually what is being done by placing a reference to
RFC 2820.  The statement presumed that there eventually would
be a technical specification meeting RFC 2820 requirements which
LDAP implementations could support just as previous revisions
had presumed LDAPext would have produced an standard track
LDAP ACM.

A statement stating that a standard LDAP access control
model is needed, without stating any requirements upon
that standard LDAP access control model, would be less
premature.

Something like:
  This document includes security requirements (listed in
  section 4.8 above) for the replication model and protocol. As
  noted in Section 3, interoperability may be impacted when
  replicating among servers that implement non-standard
  extensions to basic LDAP semantics. Security- related and
  general LDAP interoperability will be significantly impacted
  by the degree of consistency with which implementations
  a future standard LDAP access control model.

This statement should not be limited our path.  That is, the
statement is valid whether or not we take on this "future
standard LDAP access control model" or not.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 11 Mar 2002 09:11:40 -0800

As noted in previous discussions, the access control model
is only one of the security models which impacts the
replication.  To address this, I suggest the security
consideration section be replaced with:

  This document includes security requirements (listed in
  section 4.8 above) for the replication model and protocol. As
  noted in Section 3, interoperability may be impacted when
  replicating among servers that implement non-standard
  extensions to basic LDAP semantics. Security- related and
  general LDAP interoperability will be significantly impacted
  by the degree of consistency with which implementations
  existing and future standards detailing LDAP security
  models, such as a future standard access control model.

Other future standard security models could be listed as
well, but one example is sufficient.

Kurt