RFC 1327 Mappings in X.500

Steve Kille <S.Kille@isode.com> Fri, 11 March 1994 09:38 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00866; 11 Mar 94 4:38 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00862; 11 Mar 94 4:38 EST
Received: from [129.179.91.44] by CNRI.Reston.VA.US id aa02303; 11 Mar 94 4:38 EST
Received: from mercury91.udev.cdc.com by sequoia.udev.cdc.com; Fri, 11 Mar 94 03:24:07 +0600
Received: by mercury.udev.cdc.com; Fri, 11 Mar 94 03:22:54 -0600
X-From: S.Kille@isode.com Fri Mar 11 03:22 CST 1994
Received: from zeus.cdc.com by mercury.udev.cdc.com; Fri, 11 Mar 94 03:22:53 -0600
Received: from glengoyne.isode.com by zeus.cdc.com; Fri, 11 Mar 94 03:22:50 -0600
To: mhs-ds@mercury.udev.cdc.com
Subject: RFC 1327 Mappings in X.500
Phone: +44-81-332-9091
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1755.763377840.1@glengoyne.isode.com>
Date: Fri, 11 Mar 1994 09:24:02 +0000
Message-ID: <1756.763377842@glengoyne.isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille@isode.com>

I started work on editing this yesterday, and working through the
implications of various changes.   

Currently, the mapping is placed in the routing trees.   There is a
note to explain why storing the mapping separately is not chosen.   I
think that we should reverse this decision for the following reasons:


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

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

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

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


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


Steve