Subject: RE: WG Last Call Status of Requirements Document

From: "John Strassner" <[email-masked]>
Date: Fri, 8 Jun 2001 10:43:48 -0700

My comments inline, look for <js>..</js>

regards,
John

-----Original Message-----
From: Christopher Apple [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 4:52 PM
To: 'Kurt D. Zeilenga'; Christopher Apple
Cc: [email-masked]'; John Strassner (E-mail)
Subject: RE: WG Last Call Status of Requirements Document

Comments below...

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

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 6:17 PM
To: Christopher Apple
Cc: [email-masked]'; John Strassner (E-mail)
Subject: Re: WG Last Call Status of Requirements Document

At 07:34 AM 6/4/2001, Christopher Apple wrote:
>G9.  LDAP replication SHOULD support replication of directoryOperation
>     and distributedOperation attribute types defined in standards track
>     LDAP extensions. Future standards track specifications MUST include
a
>     "Replication Considerations" section which indicates how and whether
>     the new feature operates in a replicated environment.
>
>Kurt wanted to remove the last sentence.

To reiterate: it is my opinion that this sentence does not
state a requirement upon the LDUP architecture, model, protocol,
or other aspect of LDUP WG charter work items.  It is a requirement
upon designers of other extensions to detail replication
considerations.  As such, I believe it is beyond the scope of
this document.  It would be more appropriately be defined in
a document detailing how to design LDAP extensions (such as
Bruce's I-D).

CHRIS> I've had similar thoughts lately. However, I need to hear
CHRIS> some hum of concurrence on the list before we could declare
CHRIS> that this is what we actually will do with this document.

<js>
I agree. But right now, we have the authors supporting this
statement and you (Kurt) disagreeing. We therefore need to hear
from additional members of the WG before we recommend more
severe action; see below for additional thoughts.
</js>

I note as well that "requirement" I-Ds such are only guidelines
meant to focus the work effort.  While the LDUP WG is somewhat
bound by its charter to work through a requirements process,
others developing LDAP extensions can simply ignore this document.

While I agree that it is appropriate for designers of
extensions to note a wide variety of considerations, there
is no need to mandate that all future standard track
specifications contain such sections.

CHRIS> I couldn't disagree more with that statement. The only place
CHRIS> where I'm more flexible as a consumer of RFCs and I-Ds on
CHRIS> these sorts of matters is about the strength of these types
CHRIS> of requirements. Some of them can be justified as a MUST,
CHRIS> others as a SHOULD. Perhaps even weaker labels are feasible,
CHRIS> but I can't think of an example for using them in this context.

CHRIS> It is actually quite common in the IETF to mandate that
CHRIS> certain types of document sections be present. See
CHRIS> RFC 2223 (ftp://ftp.rfc-editor.org/in-notes/rfc2223.txt)
CHRIS> as an example. Note that different sections of an RFC
CHRIS> are mandatory while others are not. My assertion is that
CHRIS> a replication considerations section SHOULD be included
CHRIS> in all future LDAP extension/control RFCs. Otherwise,
CHRIS> you end up with inconsistently thought out documents used by
CHRIS> different implementers and you are set up for interoperability
CHRIS> problems in droves.

<js> I completely agree with Chris. </js>

I note that to address LDAP replication considerations in an
LDAP extension document requires that there be some technical
specification of LDAP replication.  This is very little to
consider (other than to say "This document does not consider
LDAP replication issues as there is no standard track
specification of LDAP replication").  This requirement attempts
to put the cart before the horse.

CHRIS> Putting the cart before the horse happens all the time
CHRIS> in the IETF. Over time, usually, the horse finds its way
CHRIS> to where it should be. :)

<js>
I assume that you're worried about LDAP extension documents that
complete before LDUP completes, or at least before the LDUP req
document completes. I see no reason why people couldn't go back
later and, as part of the process to upgrade these Proposed
Standards to Draft Standards, add in a replication section.

As you have pointed out, and as we have agreed, the only policing
mechanism that is practical is by like-minded people (starting
with the co-chairs of LDAPEXT and LDUP) reading documents and
saying "wait a minute, you forgot the replication section". So
given that, I see nothing wrong with having the horse find the cart.
</js>

>The Co-Chairs believe that
>this requirement should be relaxed from a MUST to a SHOULD. While we
>both firmly support the spirit of the requirement, it will be very
>difficult to actually enforce. Furthermore, while we can enforce
>this in the LDUP WG, there are many non-LDUP-related controls/extensions
>that are being developed. We don't think that it is permissible or even
>possible for LDUP as a WG to act as a "policing force" for all
>Internet-related work.  However, as discussed on the list, there
>are good reasons for making this requirement a SHOULD rather
>than omitting it.

The only reason I can see for such a requirement is so that
someone can say to an author "You didn't fulfill this requirement".
I would much rather this person say "You need to address replication
issues such as ...".

CHRIS> I don't think that word choice in communicating this particular
CHRIS> type of message is relevant to the fundamental issue of
CHRIS> requiring such a section or not. Referring someone to a spec
CHRIS> on how these types of documents must be written, by stating,
CHRIS> "You didn't fulfill [the referenced document] requirement"
CHRIS> shouldn't have a significantly different impact on the document
CHRIS> itself than that author being told in a mailing list posting
CHRIS> that they need to address replication issues. Especially if
CHRIS> that author is conscientious enough to follow up on considering
CHRIS> all comments objectively. However, because of the importance
CHRIS> of considering replication issues when writing LDAP extensions
CHRIS> given that LDUP will be implemented by several major LDAP
implementers,
CHRIS> I believe that the needs of the extended LDAP implementation and
CHRIS> user communities will be better served in the long run if authors
CHRIS> of extension I-Ds are told in *both* ways. One is explanatory and
CHRIS> the other is a requirement documented somewhere. This is completely
CHRIS> independent of the issue related to whether or not this requirement
CHRIS> belongs in the document its currently in.

<js>
I fail to see anything wrong with the text being used so that someone can
tell a prospective author "you didn't fulfill this requirement"? Everyone
agrees that it should be supported. The only way to really encourage
people to implement support for replication is to have them view it as a
requirement. Otherwise, support will be spotty at best, and guess what
suffers? Interoperability, the thing that we're all here to support.
</js>

>So, our proposed new text is:
>
>G9.  LDAP replication SHOULD support replication of directoryOperation
>     and distributedOperation attribute types defined in standards track
>     LDAP extensions. Future standards track specifications SHOULD
include
>     a "Replication Considerations" section which indicates how and
>whether
>     the new feature operates in a replicated environment.

Please note my objections to inclusion of this requirement
as either a MUST or a SHOULD.  I suggest that this sentence
not use an RFC 2119 imperative.  That is, I believe it should
be worded as a suggestion to developers of future standard
track specifications.

CHRIS> OK. I understand. John and I need to hear what others think
CHRIS> about this. So far, we've only heard from you and I. That's
CHRIS> insufficient to judge consensus that this requirement be removed
CHRIS> from this document.

<js>
Kurt, you're going to have to do a lot more to convince me. I don't see
how we have the faintest hope of interoperability if this isn't in as a
SHOULD. So please tell me how we can achieve widespread interoperability
without having this statement in.

That being said, I'll note that your are so far the only dissenter, with
the authors obviously wanting either a MUST or a SHOULD.
</js>

>Second, there is the S1 requirement. Kurt suggested some wording changes,
>but Chris and I would like to suggest some more that will help further
>clarify what the current requirement wording implies. First, the
>requirement and Kurt's suggested change:
>
>| > S1. During initiation of a replication session, authentication and
>| > verification of authorization of both the replica and the source
>| > directory MUST be allowed before any data is transferred.
>| I would suggest a cleaner wording:
>| S1. The protocol MUST support mutual authentication and verification
>|     of authorization of the protocol's peers before allowing
>|     replication data transfer.
>
>The problem is that there are several concepts that are jumbled together
>into a single requirement. We propose, as a starting point for
discussion,
>the following three requirements to take the place of the above:
>
>        S1a. The protocol MUST support mutual authentication of the
source
>             and the replica directories during initialization of a
>           replication session.
>
>        S1b. The protocol MUST support mutual verification of
authorization
>             of the source to send and the replica to receive replicated
>           data during initialization of a replication session.
>
>        S1c. The protocol MUST also support the initialization of
anonymous
>             replication sessions.
>
>Note that we explicitly discuss anonymous replication. We feel that this
>issue has been brushed under the table, and want to tease it out into the
>open. We are not explicitly recommending the support of this feature;
>rather, we want to gauge whether or not consensus has been achieved for
>including or excluding support of this in implementations.
>
>We also feel, based on list discussions, that one additional issue
>hasn't been fleshed out fully. This is the issue of whether a data
>set MAY be relevant to determining if these entities are authorized to
>actually follow through with the process of replicating the data. We note
>that the data set for which replication is being initiated MAY or MAY NOT
>itself be relevant to the actual process of authentication of the
entities
>involved. We would recommend that some additional discussion regarding
>this point be undertaken on the list and that proposals be made for any
>additional requirements related to that discussion be posted to the list.
>
>The third requirement to continue discussion on is S2. It, along with
>Kurt's suggested change, is repeated here below for your convenience:
>
>| | > S2. The transport for LDAP synchronization MUST permit assurance of
>| | > the integrity and privacy of all data transferred.
>| S2. The replication protocol MUST support transfer of data with
>| integrity and confidentiality protection.
>| (I note this broadens the requirement)
>
>First, we note that definitions for confidentiality and integrity are not
>present in the draft. They should probably be added. But for the sake of
>our purposes, consider the following definitions:

I suggest use of RFC 2828 definitions in this I-D.  In particular,
I note that the term "data privacy" should be avoided (see RFC2828).

CHRIS> Please note that the requirements language proposed
CHRIS> to spark discussion doesn't make use of the term
CHRIS> "data privacy." RFC 2828 is intended as guidance
CHRIS> for writing I-D and RFC content (referred to
CHRIS> as ISDs in RFC 2828) and the author's thereof and not
CHRIS> mailing list discussions. So even if the proposed reworded
CHRIS> requirements were actually included in the next revision of
CHRIS> the requirements document, we would be in compliance with
CHRIS> RFC 2828 from the perspective of avoiding the use of the
CHRIS> term "data privacy."
CHRIS>
CHRIS> We weren't suggesting that these definitions be included
CHRIS> in the requirements document - only that they be considered for
CHRIS> discussion purposes.

>        Confidentiality: the assurance of data privacy; no one may
>                             read the data except for the specific entity
>                             (or entities) intended.
>
>        Integrity: the assurance of non-alteration of data; the data
>                     (either in transit or storage) has not been
>                     undetectably altered.

CHRIS> If we wanted to be more consistent even in mailing list
CHRIS> discussions with RFC 2828, these would become:

data confidentiality
      (I) "The property that information is not made available or
      disclosed to unauthorized individuals, entities, or processes
      [i.e., to any unauthorized system entity]." [I7498 Part 2]. (See:
      data confidentiality service.)

data integrity
      (I) The property that data has not been changed, destroyed, or
      lost in an unauthorized or accidental manner. (See: data integrity
      service.)

      (O) "The property that information has not been modified or
      destroyed in an unauthorized manner." [I7498 Part 2]

      (C) Deals with constancy of and confidence in data values, not
      with the information that the values represent (see: correctness
      integrity) or the trustworthiness of the source of the values
      (see: source integrity).

CHRIS> Even given those definitions as pulled from RFC 2828, I can't
CHRIS> see how the requirements language proposed for discussion
CHRIS> purposes below could be interpreted as inconsistent with RFC 2828.

>Given these definitions, we'd like to start with Kurt's changes
>and move forward. The above definitions render the use
>of the word "protection" unnecessary. In fact, using that word
>in a requirements document seems to push too close into protocol
>design, based on reading many relevant texts on security
>technology and concepts. A system cannot legitimately provide
>assurance that data has remained private and/or was unaltered
>during transmission if appropriate cryptographic techniques
>are not employed to provide such protection. Thus we feel
>that the use of the word "protection" in this requirement
>pushes the document too close to the specification of the
>replication protocol itself. It would certainly be appropriate
>to include prose in the replication protocol document specifying
>a framework within which such protective measures should be
>implemented, but the requirements language proposed in this
>e-mail should be sufficient to result in such a framework
>actually being specified - which we believe is one thing
>that the requirements document is supposed to help the WG
>accomplish.
>
>The original requirement indicates (using language that is less
>than ideal) that we must be able to check on whether integrity and
>privacy were maintained during data transfer, whereas Kurt's says that
>the protocol itself MUST support data transfer with integrity and
>privacy and implies that implementations SHOULD NOT support data
>transfer without integrity and privacy features enabled. Whether or
>not anyone actually agrees about whether this implication exists is
>not in issue - that two people such as the co-chairs could independently
>come up with this as one of a few different interpretations of this
>requirement is. This indicates that the requirement is not explicit
>enough to avoid potential related interoperability problems.
>
>We would like to see some discussion of how it is envisioned that
>replication sessions operate in trusted environments. In particular,
>we are concerned with how integrity and/or confidentiality requirements
>may be levied against operational replication processes, taking into
>account the overhead those requirements imply. Some *service*
implementers
>making use of LDAP replication are likely to want a replication
>protocol that enables them to decide whether or not integrity and
>confidentiality are really requirements for their particular operational
>scenario. Thus we are compelled to make the following proposal to
>decompose the original requirement as follows:
>
>        S2a. The replication protocol MUST support transfer of data with
>           integrity and confidentiality.
>
>        S2b. The replication protocol MUST support the ability during
>             initialization of a replication session for an authenticated
>             source and replica to mutually decide to turn off data
>             integrity and confidentiality within the context of and for
>           the duration of that particular replication session.
>
>We are not stating that this particular wording should be used in the
>next revision of the requirements document. We are proposing it as
>a way of encouraging open discussion of an issue which is neither
>adequately, nor explicitly addressed in the requirements document.
>
>regards,
>John and Chris
>
>Chris Apple
>Program Manager - Directory Services
>United Messaging Inc.
><http://www.unitedmessaging.com>
><mailto:[email-masked]>
>(V) 610-425-2860
>

---

From: [email-masked] (Mark C Smith)
Date: Tue, 12 Jun 2001 09:59:45 -0400

> >Kurt wanted to remove the last sentence.

I would prefer to keep it, but change the "MUST" to a "SHOULD."

I think the sentence needs some improvement though.  Does the
requirement refer to ALL future standards track RFCs for LDAP?  Or just
the ones that define extensions?

-Mark