secondary WEPs

Urs Eppenberger <Eppenberger@switch.ch> Fri, 19 March 1993 13:29 UTC

X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 19 Mar 1993 04:14:32 +0000
Date: Fri, 19 Mar 1993 04:14:32 +0000
X400-Originator: cargille@cs.wisc.edu
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/; mhs-relay..933:19.02.93.10.14.32]
Priority: Non-Urgent
DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Fri, 19 Mar 1993 04:14:31 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Urs Eppenberger <Eppenberger@switch.ch>
Message-ID: <1218*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>
To: ietf-osi-x400ops <ietf-osi-x400ops@cs.wisc.edu>
Subject: secondary WEPs

The routing document allows a few optional things which I suggest to
define explicitely for the GO-MHS community in Alf's document:

1 I suggest to disallow secondary WEPs since they create more management
  problems than what they solve.

2 WEPs with password need to document their passwords in the corresponding
  RELAY document. The mechanism with Password: secret is not allowed.

3 The field LocalDomain: should be mandatory for the GO-MHS community

4 The presence of an Echo-server following the documented requirements
  is highly desirable.

This is with the hat on of the MHS Coordination Service to make my life
easier. ;-)

Kind regards,

Urs.

secondary WEPs Urs Eppenberger