Reply to RFC 1327 Mappings in X.500

["Kevin E. Jordan" <[e-mail]>]

Steve,

I haven't seen the details of your proposal, but I have the impression that
you are proposing a radical change here, and I do not see the need for it.
Our RFC1327 gateway implementation, with support for RFC1494 and 1495, uses
the tree-based approach quite successfully.

> 1) There are severe difficulties with maintaining consistency between
> 1327 mappings held in multiple routing trees.  This has been exposed
> in review.

What severe difficulties?  If this has been exposed in review, then that
review  was not made public.  Our operational experience has not shown any
severe difficulties.  Maintaining consistency between mappings across multiple
trees presents a problem only if administrators copy global information
into their private trees and then are careless about keeping it up to date.
They will have very little incentive to do this if the directory infrastructure
is reliable and/or they can replicate mapping information from the Open Tree
using the normal slave update process.

Also, unless your new proposal outlaws or otherwise prevents the configuration
of private mapping tables, I don't see how it can eliminate inconsistencies.

> 2) A gateway needs good access to all of the mappings.   The new
> approach makes replication much easier.

The validity of this is not obvious to me.  The proposed new approach might
reduce the number of subtrees that need to be replicated, but this doesn't 
necessarily make replication easier.  Something to consider is that it would
increase the volume of data and amount of time needed for each replication
operation, and this increases the probability of replication failure due to
network hits or other errors.

Also, a table-based approach centralizes administration of the data.  This
would be a step backward.

> 
> 3) The "ommitted component" stuff fits very very badly into the open
> routing tree

We have been solving this relatively minor technical problem.

> 4) Having a separate area gives a much easier and more manageable
> migration/relationship with the table approach

Doesn't this lead to centralized administration?  Is centralized administration
really necessary?  This appears to be an attempt to legislate good
administrative practices and good taste at the expense of flexibility and
distributed management.

> I believe that this is a strong case, and will change the I-D in this
> manner.    What do others think?

It would be helpful to see the details of the proposal.  I have the impression
that you are proposing a new table-based or table-like solution.  If this is
true, then you have not convinced me that a strong case has been made or that
this would be a step forward.  Our implementation uses the current tree-based
design.  It has been deployed at many customer sites, some of them quite large.
Our operational experience with the current tree-based design has been very
successful.  The current design is sound, and I do not see a reason to change
it.