RE: Correction to Last Call posting

Thanks. What do the document editors think about
the proposed text changes? Other WG members?

Chris Apple
Program Manager - Directory Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email protected]> 
(V) 610-425-2860


   >-----Original Message-----
   >From: Kurt D. Zeilenga [mailto:[email protected]]
   >Sent: Friday, July 06, 2001 3:49 PM
   >To: Christopher Apple
   >Cc: Christopher Apple; [email protected]; 
   >[email protected]
   >Subject: RE: Correction to Last Call posting
   >
   >
   >I've restricted my comments to just those issues in which
   >you explicitly requested further comment.  In regards to
   >my other comments, I believe the WG has adequately
   >addressed my concerns (not necessarily to my liking) and
   >hence I support (with previously stated reservations)
   >the progression of this document after these remaining
   >issues are addressed (not necessarily to my liking).
   >
   >Kurt
   >
   >At 02:20 PM 7/5/2001, Christopher Apple wrote:
   >>   >-----Original Message-----
   >>   >From: Kurt D. Zeilenga [mailto:[email protected]]
   >>   >Sent: Wednesday, June 27, 2001 7:41 PM
   >>   >To: Christopher Apple; [email protected]
   >>   >Cc: [email protected]
   >>   >Subject: Re: Correction to Last Call posting
   >>   >
   >>   >
   >>   >This message mostly reiterates previously raised issues.
   >>   >
   >>   >Section 3:
   >>   >  Interoperability among directories using LDUP 
   >replication may be
   >>   >  limited for implementations that add semantics beyond 
   >>   >those specified 
   >>   >  by the LDAP core documents (RFC 2251-2256, 2829, 2830).
   >>   >
   >>   >I note that Interoperability among directories using LDUP 
   >>   >replication
   >>   >may also be limited for implementations which 
   >implement different
   >>   >subsets of the semantics defined in the LDAP "core" 
   >specification.
   >>   >For example, one implementation may support subtyping 
   >another not.
   >>   >Another may require ;binary for some standard track attribute
   >>   >while another disallows ;binary for same.  As an alternative to
   >>   >adding a clarification to the statement (as I would prefer),
   >>   >removing the statement (as it doesn't place a requirement upon
   >>   >LDUP) would be acceptable.
   >>
   >>Please propose full replacement text for the statement you
   >>are commenting on. I can't determine exactly what you are
   >>proposing to add as clarifying text based on what you wrote.
   >
   >        As LDAP "core" specification includes numerous features
   >        which are not mandatory-to-implement (e.g. RECOMMENDED
   >        or OPTIONAL) as well supports elective extensions,
   >       interoperability between independent implementations of
   >        LDAP and the LDUP replication extension may be limited.
   >        Use of applicability statements to improve interoperability
   >        in particular application spaces is RECOMMENDED.
   >
   >My point is not that this LDAP Replication issue is not limited
   >just by "semantics beyond" the core specification, but to
   >non-mandatory semantics within the core specification and
   >"semantics beyond".  And, I believe both can be addressed
   >through use of applicability statements (which narrows the
   >applicable specifications).
   >
   >>   >M5.  LDAP replication MUST NOT require all copies of 
   >the replicated
   >>   >information to be complete copies of the replicated object. 
   >>   > The model
   >>   >MUST support Partial Replicas.
   >>   >
   >>   >I assume this applies to copies, not to the original.
   >>   >That is, I assume that LDAP replication MAY require
   >>   >some master (if not all masters) to hold a complete
   >>   >instance of the object.  Some clarification here may
   >>   >be appropriate.
   >>
   >>Please propose clarifying text explicitly so the WG can
   >>evaluate it. I can't tell quite what to suggest as clarifying
   >>text based on your comment.
   >
   >LDAP replication MUST NOT require all copies of the replicated
   >information to be complete copies of the replicated object
   >but MAY require that a complete copy to be held by at least
   >one replica.  The model MUST support Partial Replicas.
   >
   >
   >>This issue is unresolved.
   >>
   >>   >
   >>   >Security Considerations:
   >>   >  "As noted in Section 3, security may be impacted..."
   >>   >
   >>   >Section 3 makes no statement about security.  It makes a
   >>   >statement about interoperability.
   >>
   >>Current Text:
   >>
   >>This document includes security requirements (listed in section 4.8
   >>above) for the replication model and protocol. As noted in 
   >Section 3,
   >>security may be impacted when replicating among servers 
   >that implement
   >>non-standard extensions to basic LDAP semantics.  Access 
   >control is one
   >>common case which affects security; work to address this 
   >issue is going
   >>on in LDAPEXT as documented in RFC 2820 [RFC2820].
   >>
   >>Proposed Text to clarify the section based on Kurt's comment:
   >>
   >>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. Since LDAPv3 access control work is being
   >>treated as a set of standards-based extensions, security-related
   >>and even general LDUP interoperability will be significantly
   >>impacted by the degree of consistency with which LDUP
   >>implementations support the LDAPv3 access control requirements
   >>documented in RFC 2820 [RFC2820].
   >>
   >>This issue is unresolved until we hear from at least the
   >>document editors about whether or not this proposed text
   >>fits or not. Also need some reaction from Kurt about whether
   >>this clarifies the text based on his perspective. If not,
   >>I think it would be reasonable for us to expect to see
   >>an explicit proposal for the text to be contained in the
   >>section.
   >
   >The suggested text addresses my concerns.
   >

BEGIN:VCARD
VERSION:2.1
N:Apple;Chris
FN:Chris Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer=
ica
EMAIL;PREF;INTERNET:[email protected]
REV:20010621T205341Z
END:VCARD